Lesson 1 of 5
Frontend in Interviews
"Chance favours only the prepared mind." — Louis Pasteur, lecture at the University of Lille (1854)
Frontend interviews have a reputation for being unfocused — a mixture of algorithm puzzles that never come up in the job, trivia about CSS properties, and a build exercise that is really a typing test. Some of that reputation is earned. But underneath the variation there is a consistent structure, and the candidates who do well are not the ones who memorised more; they are the ones who understood what each round is actually measuring and answered that.
The structure is roughly six round types across a full loop — around four and a half hours of assessment — and they overlap far less than they appear to. A component build and a debugging round both involve writing code and are looking for almost entirely different things. Treating them the same is the single most common preparation mistake, because the behaviour that scores well in one is neutral or negative in the other.
The finding worth carrying into every round: in a 45-minute component exercise, more than half the time should not be spent typing. The distribution below allocates 25 minutes to code and 20 to clarifying, designing and reflecting, and the reason is not that typing is unimportant. It is that the signals interviewers are instructed to look for — judgement, communication, knowing what you did not do — are only observable in the other twenty.
This Part turns the whole volume outward. Every chapter has carried an Interview Corner; these five chapters are about the situation those answers live in.
Two candidates get the same component exercise. One writes a complete, working, well-structured implementation in 40 minutes and stops. The other has a slightly rougher implementation at 35 minutes, then spends ten minutes on states they had not handled and what they would do differently with more time. The second candidate usually scores higher. What is being measured that the first candidate did not show?
Six rounds, six different questions
Run to execute the tests…
The third test is the one that changes how you prepare. The build and debug rounds share zero assessed signals — decisiveness scores in one and is a failure mode in the other, and candidates who prepare "coding rounds" as a single category bring the wrong behaviour to whichever comes second.
A driving test is not a race. You can complete the route flawlessly and fail for not checking your mirrors, because the examiner is scoring observable habits rather than arrival. Interviews work the same way and the analogy is worth taking literally: the mirror checks have to be visible. An engineer who considered the accessibility implications silently and one who did not consider them at all produce identical transcripts.
Where the time should go
Run to execute the tests…
Calibrate against the rubric
Tick only the two behaviours that describe a complete, silent, working solution. It scores badly — not because the code was wrong, but because three of the four axes had nothing to score.
What I say to people preparing is that an interview is a demonstration, not a delivery. The artefact at the end matters much less than what was made visible while producing it, and that is not a criticism of the format — it is what the format is for. Nobody can assess judgement from a finished file, because a good decision and a lucky one look identical once made. So the habit worth practising is narrating the decision at the moment you make it: "I'll use a button here rather than a div, because I get focus, Enter, Space and form participation for free." That sentence costs four seconds and it is the difference between a reviewer inferring you know something and knowing it. The other thing I insist on is the last five minutes. Stopping with something unfinished and saying "I haven't handled the empty state or the error state, and if I had another twenty minutes those would come before styling" converts a gap into evidence of judgement, and candidates almost never do it because stopping early feels like giving up.
Frontend interviewing has been through three eras and is currently in the third. The first, through roughly 2012, was trivia — questions about browser quirks, CSS hacks and jQuery methods, which made sense when cross-browser knowledge genuinely was the differentiating skill. The second, from about 2013 to 2019, imported the general software-engineering loop wholesale: algorithm and data-structure questions on a whiteboard, largely because that was the process large companies already had and frontend was being folded into it. That era produced the widespread and reasonable complaint that the interview did not resemble the job. The third era, roughly since 2019, is the build-and-debug format that dominates now, and it exists because enough companies measured the correlation between whiteboard algorithm performance and frontend job performance and found it weak. It is worth knowing this history for one practical reason: the second era has not vanished, and some companies still run a full algorithms loop for frontend roles. Volume 4 of this Library is not optional preparation.
I sat in on debriefs for a frontend role where two candidates had produced nearly identical component code. The first had finished with eight minutes to spare and spent them polishing the styling. The second had stopped at 35 minutes with the component working but plainer, and used the remaining ten to walk through what was missing — no loading state, the keyboard interaction only handled Enter and not Space, the component was uncontrolled and should probably support both — and to explain which of those she would do first and why. In the debrief the first candidate was described as "solid, hard to tell how they'd handle ambiguity". The second was described as "clearly senior — knew exactly what she'd traded". Same code, and the difference in the written feedback was entirely about the last ten minutes. What struck me was that neither candidate had done anything strategic; the second simply had a habit of narrating her own gaps, and that habit read as seniority because it is one.
Record yourself doing a 45-minute component exercise, then watch it back with the sound on and ask what an interviewer could have concluded from the audio alone. Most people find long stretches of silence punctuated by "okay" and "hmm", and a decision every few minutes that was made entirely in their head. Now consider that the reviewer's notes are written from that audio, not from the file. This is not an argument for performing — nobody wants a running commentary — it is an argument for making the decisions audible, which is perhaps six or seven sentences across the whole session. The uncomfortable realisation for most people, myself included the first time, is not that they communicated badly. It is that they made a lot of good decisions and left no evidence of any of them.
Common Mistakes
Preparing "coding rounds" as one category. Build and debug rounds share zero assessed signals; decisiveness scores in one and fails in the other.
Typing immediately. More than half a 45-minute component exercise should not be spent coding.
Skipping the clarifying questions. Five questions, two minutes, and they change the design.
Not agreeing what is out of scope. The least-asked and most protective question — it stops you being marked down for an omission you chose.
Optimising for finishing. Finishing correlates weakly with a strong score; an unfinished solution with clear reasoning consistently beats a silent complete one.
Making decisions silently. A good decision and a lucky one look identical in the finished file.
Doing the accessibility work without announcing it. The code looks the same; the rubric does not.
Spending the last minutes polishing. Ten minutes naming your gaps reads as seniority; ten minutes on styling reads as nothing.
Treating the behavioural round as the easy one. Equal time, frequently equal weight, and where strong engineers fail loops.
Assuming algorithms are gone. The whiteboard era has not vanished from every company.
Interview Corner
Do a 45-minute component exercise against a timer, recording your screen and audio, then watch it back with your eyes closed and ask what an interviewer could conclude from the sound alone. Count how many decisions you made silently. Then do a second one with the explicit rule that every decision gets one sentence out loud, and compare. Separately, write out your own version of the nine-item component checklist and practise naming which items you are skipping and why — that sentence is worth more than the implementation of any one of them. Finally, run the rubric demo above against your own recording honestly, and look at which axis is emptiest; that is your preparation priority, and it is rarely the code.
Run to execute the tests…
Summary
- Six round types, about 4.5 hours, looking for 22 distinct signals with very little overlap.
- Build and debug rounds share zero assessed signals. Decisiveness scores in one and is the failure mode in the other.
- The behavioural round is equal time and often equal weight — where strong engineers fail loops.
- Finishing is weakly correlated with a strong score. An unfinished solution with clear reasoning beats a silent complete one.
- In 45 minutes, spend 25 typing and 20 not. The 20 is where most of the score is.
- Five clarifying questions, two minutes — including the one nobody asks: what is explicitly out of scope.
- Reserve the last five minutes to name your gaps. It converts an omission into evidence of judgement.
- Announce the accessibility pass. Choosing a
<button>deliberately and using one by habit produce identical code. - Nine things a reviewer looks for; two typically shown unprompted. Naming what you skip is most of the credit.
- A good decision and a lucky one look identical in a finished file — which is why decisions must be audible.
- An interview is a demonstration, not a delivery.
- The algorithms era has not ended everywhere. Volume 4 is not optional.
In the next chapter, Building a Component Live, we take the most common round and work through it minute by minute — including the nine-item checklist and what to say about the items you are not going to implement.
The debrief I described bothers me slightly, and I think it should bother anyone who has been on either side of it. Two people produced the same work and received meaningfully different assessments because one of them narrated. That is not obviously fair — it advantages a communication style, and communication style correlates with things that have nothing to do with engineering ability, including confidence, first language, and whether anyone ever told you this was how the format worked. I do not think the answer is to pretend it is not true; you are going to be interviewed under this format and you should know how it reads. But I would say two things alongside it. If you are the candidate, treat narration as a learnable skill rather than a personality trait, because it is one. And if you are ever the interviewer, remember that silence is not absence of thought, and that the most useful question in your toolkit is "what would you do with another twenty minutes?" — because it gives the quiet candidate the same opportunity the talkative one took for themselves.
Q&A · 0
Enrol to ask questions and join the discussion.
No questions yet — be the first to ask.