DEV Community: Akshar Takle

Interviewing for Frontend Engineering

Akshar Takle — Mon, 24 Feb 2020 14:24:14 +0000

Interviewing sucks! The process is time-consuming, drains a lot of our energy and most of the time in return it gives us mental stress. But, you gotta do what you gotta do!

In order to make this process less stressful and more enjoyable, I want to put out here a few points that have worked well for me.
Interview with a Purpose:

Even before you start applying for jobs, think:
What kind of work are you looking for in the next role?
What do you like working on the most?
What do you care about the most - for ex : salary, engineering culture, open-source projects, free food 🍕

Many times we just want the job. But its important in the long term to be intentional about what kind of job you want. Also, it will be easier to rule out the companies where you don't want to work.

The Resume:

The resume is your first selling point. Make it short, concise but impactful. As a rule of thumb you want to have a single page resume which includes the following sections:

Contact info
Work Experience
Achievements
Technical Skills
Education

Check out my resume for example here.

People having zero experience / new grads:

Everyone started somewhere with zero experience. They worked their way up. Do not get bogged down by the fact that you don't have any experience. Instead, show off your skills more aggressively. Build projects - any project. It doesn't matter which as long as you can take out some learning points. Write blogs about it. Tweet about it. Get into the limelight. If you are a new grad or someone with zero experience doing side projects will help you the best. Have knowledge about different things. It does not have to be very deep. Show that you are curious.

That being said, following are the things that you must know before going for any frontend interview:

Basic Javascript Concepts - event handling, bubbling, block vs functional scoping, promises and basic CSS. It's okay if you don't know the CSS frameworks like CSS grid or flex box. No one remembers that shit anyways. Everyone googles it.
A decent understanding of your choice of a frontend framework. For ex: React - know how to compose components, pass down props, which lifecycle method is suitable for a particular scenario, bonus - performance optimizations. Know the industry's best practices. (Check out repos on GitHub to know what they are). You have access to everything.

For experienced people:

Companies will have more expectations from you. You are not allowed to screw up the basic javascript, and CSS parts. You have to be good at writing code, composing components and best practices should follow by default. Front end dev and node are closely tied together. So be ready to answer conceptual node questions. Here are a few things that you should know:

Node workflow
Server-side rendering
Redux / Complex state management
GraphQL
Performance Optimizations
Native browser / DOM operations (like history, browser events, requestAnimationFrame, etc.)

The Interview Process :

Most of the companies will follow a standard process which consists of:

Initial Recruiter Call
Phone screen
More phone screen/code test/hacker rank test
On-site Interview

After at least a couple of tries at this, if you are still alive, Congrats! You are ready to crack your next interview.

Alright! Let's break down the interview process and see how to climb up each step.

Initial Recruiter Call :

This step is to gauge your overall interest and see if you can be fit for the position at a very high level. Get this round done quickly, without thinking about it much. How? Be ready to answer questions on these lines:

What are you up to currently?
What are you looking for in your next role?
Why are you switching (if switching)?
What are you currently working on? What projects have you worked on?
What interests you in our company?
What's your availability for next rounds

Prepare for these questions and you should be fine. For questions like why do you want to work for this company, you will have to do some research. Take out 5 mins before the interview, visit the company's website, understand what they do and what are their projects.
You don't want to spend too much time preparing for this round. So PRACTICE and make it smooth.

Phone Screen:

Here, you will probably speak with the hiring manager or some engineer from the hiring team. This round could have online coding exercise or just oral one to one questions and can go from 30 mins to 1 hr. Ask whats the structure of the interview beforehand so you can be prepared.

During the interview, ask questions, lots of them. Understand clearly what the problem is. After that, come up with a solution and walk through it. Again, ask questions. Ask if they think it is the right way. If not they will guide you in the right direction sometimes subtly or sometimes directly. Listen carefully for the clues. This is also a chance to know your could be co-workers. You can come to know if they are easy-going, serious, rude or whatever they might be.

In the exercise, if you are given some task that is frontend work, show your coding skills, follow best practices, get some optimizations, handle edge cases. If you are a new grad or someone with no experience, your side projects will help you a lot in this round. If its algorithm exercise, then hopefully you have already solved enough leetcode problems to make it through this round.

If you are a new grad or just starting, make sure you know how to tackle string, array manipulations, and recursion. Check out this github by Brian Holt for sorting and recursion algorithms. It's gold!

In the end, be ready with few questions for the interviewer. Many people find this awkward when they are asked if they have any questions. This is your chance to get an idea of how your interview went and it also shows that you are curious about the position, team, and company. Here are a few questions that you can ask at the end:

What are the next steps? How long does it take for the whole process? (the answer to this question might give you a hint whether you made it to the next round)
What is the company culture like?
How big is the team?
Which team I would be interviewing for?
What are some current ongoing projects?

Code Test / Hacker Rank :

Many companies will have this round where you will either do a take-home test or do live pair programming. The test can be either FE related exercise or algorithmic questions. Its always good to follow best practices everywhere, but here, if its an algorithm question, try to solve it first. Get the logic right. You can show off your coding skills in the phone interview. If its FE related task focus both on the best practices and solving the problem.

Well done! Most people won't get up to here. But, If you passed all the above steps, the company already likes you and there is a high chance that you'll be hired.

On site:

To prepare for onsite interviews, practice writing code without a computer because there will be whiteboard exercises. Maybe lots of them. Make yourself comfortable putting out your thoughts on a whiteboard or just a piece of paper. Practice doing sample algorithmic problems. Also, ask the interview structure a few days before the interview. Will it be HTML CSS type questions or just javascript problems or algorithms. If you know it beforehand, you will be less nervous.

When you are doing the exercise, think out loud. Keep the end goal in mind and don't focus too much on the details. It's ok if you miss closing a bracket. Tell them about your approach to solve the problem. Most importantly try and break down the bigger problem into smaller ones and kill it!

Congrats! Hopefully, by now, you have an offer from your dream company. Cheers!! Shoot me an email or connect with me on twitter for any questions or just say hi.

Helpful resources:

https://leetcode.com/
Design Patterns - https://www.educative.io/courses/grokking-the-system-design-interview
Sample resume - https://github.com/akshar07/Resume/blob/master/AksharTakle-%20Resume%20%20copy.pdf
CS Algos - https://btholt.github.io/four-semesters-of-cs/

How to Rock the Party with Apollo GraphQL Cache 🎉🎈

Akshar Takle — Mon, 23 Sep 2019 18:51:57 +0000

Hi, I’m apollo-cache-inmemory a.k.a. Apollo Cache. I am the default implementation of cache in your Apollo Client. So Let me explain why we are here!

I’m going to help you access and manipulate cache whenever you need. Did you perform a mutation? No worries! I can update the cache for you. Oh, by the way, that Redux guy is cool, but you may not need to store data with him anymore 🤷‍♂. Allow me…

Er... Thanks, Apollo Cache for the intro, but I think I’ll take it from here.

Okay, so when I first tried apollo cache it was way over my head. There are so many different use cases that I was bound to get lost. Add the __typename thing to all that confusion. So I decided to make apollo cache my friend. Here is how it went:
First, you gotta invite Apollo Cache to your party :

npm install apollo-cache-inmemory --save

Now Apollo Cache will start to rock the party out of the box. Just introduce it to Apollo Client(Apollo Client has a special liking towards cache) and boom!

const cache = new InMemoryCache();

const client = new ApolloClient({
  link: new HttpLink(),
  cache
});

But we want it to do a lot more things. So, make it understand your party rules so that it behaves the way you want. Something like code of conduct? We will provide the code of conduct in its constructor. By the way, this is totally optional. So here we go!

Code of Conduct:

addTypename: A boolean to specify whether to add __typename to the document. (Default is true). More on this later.

dataIdFromObject: Cache normalizes all the data before saving it in the store. This is a function that takes the data object and returns a unique id. More on its use later in the story.

fragmentMatcher: Apollo Cache by default uses heuristic fragment matcher. This is a weird thing that you need to tell apollo cache if you plan on using fragments on unions and interfaces.

cacheRedirects: Sometimes, we request data that apollo cache already has in its store but under a different resource key. With cacheRedirects, we tell apollo cache where to look for the already existing data.

Apollo Cache was instantly popular in the party. All the party guests (you can imagine them as components) were interacting with the cache. We were playing React and Act 🧐 in which the cache held all the events that we could act upon and also the scores of each team. And let me tell you, it did an awesome job. Apollo cache did three things to store and retrieve the data quickly —

split the data into individual objects
create a unique identifier for each object
store data in a flattened data structure

It used code of conduct points addTypename and dataIdFromObject to do this. Typically cache uses id and _id fields found in the data along with __typename to create a unique identifier. If the ids are not provided in the data it will key off of __typename. dataIdFromObject function tells the cache to use a specific field in your data as a unique identifier so that it can be referenced in any interaction (query) with Apollo cache later.

I know its confusing. So, let’s talk more on this:
But first, How does the cache remember everything? Simply put, Apollo cache remembers the way you interacted with it. Cache calls this as query path.

query {
    Events (category = 'happy') { 
        name
    }
}

For the above query, the cache will create the query path as follows: RootQuery -> Events(category = ‘happy’) -> name. It assumes that for one query path there must be exactly one resource that it points to. So next time when anyone asks cache the same query it answers it instantly. For instance, one of the guests asked apollo cache about the team's score and list of events from category “happy”.

query {
    Score(team = 'A') {
        points
    }
    Events (category = 'happy') { 
        name
    }
}

The cache already knew about the list of events as someone had already requested about it. So it answered instantly. Snappy!

The cache tries its best to remember things. But sometimes, the query path isn’t clear enough. For instance, These were the questions asked by two other guests:

Guest A: Hey, Apollo Cache. Can you give me the event that falls in the category “dancing”?
Guest B: Cache, can you provide me with the event in 2nd category? (here the category is referenced by the id)

Now it happened that id = 2 (or second category) was actually an event that fell into “dancing” category. How did the cache view these requests?

// 1st Request
query {
    Event (category = 'dancing') { 
        name
    }
}
// 2nd Request
query {
    Event (id = 2) { 
        name
    }
}

Here, the cache was unaware that both the request referred to the same result. In a normal scenario, the cache would fetch that data and save it twice in its store. At this point, the cache was able to figure out what was happening with those requests using dataIdFromObject rule.
How? With a little help from us. So, in dataIdFromObject we specify a unique identifier for any object that we need to query. Here, we need to be careful that we do not provide raw ids (SQL primary keys) as a unique identifier because id = 5 can represent both an event or a guest. We need to combine this with __typename . So an identifier like Event:5 only represents event data that has id = 5 and Guest:5 only represents guest data that has id = 5.

If the event name in the dancing category gets changed from “bachata” to “salsa”, both above queries will get updated answers. Easy and neat!

Apollo cache has many other tricks up its sleeve. Let's discuss them some other time!

Thanks to twitter user @DrunkBB8 fro original pictures.

Managing Local State with Apollo Client and React Hooks

Akshar Takle — Mon, 09 Sep 2019 19:38:01 +0000

https://medium.com/@takleakshar/managing-local-state-with-apollo-client-and-react-hooks-9ad357e6d649