Frontend Interviews

Frontend engineering has evolved a lot in the last 10 years. The crazy days of dealing with IE8 are behind us for good. While I could be happy about it, the framework fatigue hit me hard enough that I started thinking frontend engineering has evolved both in terms of responsibilities and complexity. My favorite dialog to the juniors:

I have lived long enough to see the raise and fall of numerous framework and libraries

The evolution in the frontend engineering space has brought countless advantages and choices based on preferences.

One of the non-desirable outcome of this rise is, the frontend engineering space is not seen as a unified frontend engineering. Rather I see roles like React Developer and D3.js expert. I know React and so I am a frontend engineer is the notion.

I know kung fu

Sorry for the meme. Couldn’t resist it. When I hire a frontend engineer I expect not the React proficiency. What I expect is your general understanding about the frontend space as a whole. Let me walk you through my typical interview process.

Most Recent Project

I always ask the candidate to talk in detail about the most recent project they had contributed to. This allows us to avoid those parts that the candidate might have forgotten. I am keen to understand, to what extent did they get involved in the project. Did they put the effort to understand the bussiness? This is very important as I strongly believe great candidates are not yes masters. They ask questions, try to find the best possible solutions and find ways to evolve with the work.

I ask here questions like why React, why GraphQL, why Tailwind CSS?

If the candidate says because I was told to use, they get 0 point for the question. Instead if they tried to justify the reasons, I am glad they thought about it before picking the tools.

Explain the Framework

From the project, if they had worked on any particular framework, I’d ask the candidate to explain the fundamental concepts of the framework they had used.

Say if it is React, I’d expect them to talk about unidirectional data flow, immutability, batch updates, virtual DOM, hooks, component lifecycle, memoization. At this point, depending on their explanation I could judge their proficiency with the framework.

Dislikes

I ask them to tell me what do they dislike about the framework. A good candidate with extensive experience would start with a comparison with other frameworks and talk about general pitfalls of the framework like bundle size or developer experience. An inexperienced candidate will say nothing here. Not big deal though.

Dive into JavaScript

I ask them to explain how JavaScript works. Vague and big. I expect them to cover UI thread (single thread nature), interpretation, event loop, web APIs, call stack and call frame. To understand whether it is bookish knowledge, I ask them questions related to timer functions ran before a large synchronous loops. Here they would be caught if they are bluffing.

Browsers

Very important area of the interview. If you are a frontend developer, I’d expect you to understand how browser works. I’d put a vague question in the front: “Explain how browsers work. Cover as much detail as possible”. I expect them to talk about how pages are downloaded, parsed and rendered, how DOM is created, how CSS is used to create the layout, how and why parsing is suspended. At this point, I want to understand the candidate’s knowledge about performance.

Performance

First thing about frontend performance is to measure it. I expect the candidate to know how to measure, using lighthouse, webvitals, console.time, performance object, using the network tab in dev tools to figure out the resource waterfall.

Here, another vague question I ask is, “there is a lag when I interact with the UI, scroll isn’t smooth, site feels heavy.. How would you find out where the issue is?”. This question vets out good candidate from the inexperienced candidate. I expect them to talk about profiling, memory leak detection, DOM count, events bound to the page, timer scripts and listeners runing at the back.

If you mention about layouting, panting, composite layers, you have conveyed you are not a noob and you have done your home work.

Tricky Advanced level S**t

Let’s talk about CSS. When does z-index not work? If the candidate can answer even 1 scenario, I am inclined to approve the candidate to the next level. Understanding z-index forces you to understand context stacking. Understanding Stacking allows you to write silky smooth interfaces. To check the mastery over CSS, I’d ask them what all properties would you not recommend animating? If you can answer this, you have done some serious s**t with CSS. If the candidate answers this, I put in front of them the next question. I want to animate width of an element using JS very frequently without Jank. If they mention requestAnimationFrame and why they will use it, I am fairly confident that the candidate has depth and definitely will pass them to the next level.

Personally I feel, if one could grasp the concepts and could explain them in their own words, they are 60% employable. I’d keep 10% to understand their logical capability and remaining 30 for behavioral aspects. I’d make sure the candidate learns from me the questions they couldn’t answer; that way it provides them the opporunity to develop themselves further.

Interviews are stressful. If I want to judge someone for their coding skills, I’d give a simple problem (1-2 hrs) and a deadline and ask them to solve in their leisure. If they turn back with a meaningful solution, I keep one round of non-coding purely discussion based interview which helps to understand their conceptual understanding of the frontend space. As per my experience, this, my friend, is less stressful.

P.S: Fundamentals are important. Please learn fundamentals.