The loop, on one sheet
Running a pipeline end to end (sourcing, screening, technical interviews, onboarding) teaches you which frontend developer interview questions predict anything and which ones just fill the hour. This note is the loop I actually run, with the reasoning attached. Hiring managers can take it as a starting point. Candidates prepping for an interview should read it too, because knowing what the interviewer is listening for doesn't break these questions. They work better on people who've thought about them.
Here is the whole thing: four stages after my ten-minute screen, a bit under three hours of the candidate's time, and an answer inside two weeks.
Two of those numbers do more work than the stages do. Under three hours is a budget rather than an average, and it holds because every stage has to justify its slot against it; when a loop needs a fifth round to reach a decision, the earlier four were asking the wrong things. Two weeks is a promise, and it's the one candidates tell me gets broken most often elsewhere. A company that can't answer inside two weeks is usually still interviewing other people and hoping someone better turns up, which is a thing candidates can feel through the silence.
The stages run in this order for one reason: each one costs more than the last, mine and theirs. Nothing expensive happens until something cheap has already justified it, which is also why any stage can end the process. Read the sheet top to bottom and that escalation is the whole design.
| Stage | Time | What it tests |
|---|---|---|
| Portfolio and resume screen | Time10 min, async | TestsDoes the work match the role; do the projects look shipped |
| Intro call | Time30 min | TestsCan they explain their own work; motivation and logistics |
| Technical interview | Time60 min | TestsCode reading, CSS, accessibility, debugging out loud |
| Pairing exercise | Time45 min | TestsOne small real bug; collaboration and tooling comfort |
| Team conversation | Time30 min | TestsMutual fit; my developers ask anything, and so does the candidate |
Stages and timings: my own loop, July 2026
The shape matters more than the stages. Each stage has one job, each stage can end the process, and nothing is padded to look thorough. Long loops don't produce better hires; they produce candidates who accepted the other offer while round five was being scheduled. If you're building the whole pipeline rather than just the interview, sourcing and rates included, I covered that side in the hiring guide.
The frontend developer interview questions worth asking
Every question below has to earn its slot the same way: it has to predict something about the first six months on the job. These four keep passing that test.
- "Walk me through something you built that's live right now." Ownership, tested directly. The follow-up, "what would you change today?", tests growth. A good answer names specific regrets: the state management they'd simplify, the images they'd lazy load, the part they'd delete outright. A weak answer defends everything. Nobody's two-year-old code deserves a full defense, and the developers who know that are the ones who've improved since writing it.
- "The homepage got slow last week. What do you do first?" Process under ambiguity, which is most of the job. Good answers measure before touching anything: what shipped recently, what the network waterfall shows, whether it's slow for everyone or just some people, what the performance panel says. Weak answers jump straight to a favorite fix. A developer who optimizes before measuring will happily keep doing it on your payroll.
- "Here's a dropdown built out of divs. What breaks, and for whom?" Accessibility as reading comprehension. I'm listening for semantics first (this wants to be a button and a list), then keyboard access, focus management, and what a screen reader would announce. Candidates who reach for ARIA attributes before reaching for the right element have memorized a fix without understanding the problem.
- "Tell me about a technical argument you lost." Collaboration, from the losing side. The best answers include what happened next: they committed to the team's decision anyway, and about half the time they admit the other side turned out to be right. A candidate whose every story ends with them being correct has either never been wrong or can't tell. Both are problems you'd be hiring.
Notice what's missing: trivia. Most published lists of frontend developer interview questions are documentation recall in a trenchcoat. The job is knowing how to look things up, not having looked them up already, so I let the documentation keep its job and ask about judgment instead.
Why I skip whiteboard algorithms
For frontend roles, an algorithm puzzle on a whiteboard measures two things: whether the candidate rehearsed that puzzle recently, and how their nerves hold while writing code on glass in front of strangers. Neither predicts whether they can build an accessible checkout flow. In twenty years of frontend work I have inverted zero binary trees in production, and on an average Tuesday I would fail that round myself.
The actual job is the DOM, CSS, async data, browser quirks, half-written requirements, and other people, so the technical hour tests those. Instead of asking someone to write performative code, I ask them to read real code: a component much like the ones in our codebase, then what it does, where it breaks, what they'd change. Rehearsal doesn't help there; understanding does. People who are good at this work are visibly comfortable inside code they didn't write, because that is most of what the job is.
Take-home vs live coding
Anyone who tells you one format is simply correct hasn't run enough loops. Take-homes remove performance nerves and let people work in their own editor on their own schedule, which is how the actual job works. They also tax whoever has the least spare time, parents especially, and strong candidates skip them entirely when a competitor's process is shorter. Live coding shows you collaboration as it happens, and nerves distort it badly enough that some excellent developers read as mediocre for one artificial hour.
-
Take-home
What it buysNo performance nerves, their own editor, their own schedule, which is how the job actually runs.
Taxes whoever has the least spare time, parents especially, and strong candidates skip it when a competitor's process is shorter.
-
Live coding
What it buysCollaboration as it happens, watched directly rather than inferred afterwards.
Nerves distort it badly enough that some excellent developers read as mediocre for one artificial hour.
-
What I run instead
45-minute pairingOne small, genuine bug. They drive their own machine, search and docs allowed, and I play the pair rather than the judge.
If someone would rather have a take-home, it is capped at two hours and I read every line that comes back.
My compromise is the 45-minute pairing exercise in the table above: one small, genuine bug, and the candidate drives on their own machine with search and docs allowed while I play the pair, not the judge. I care about what they check first, how they move through unfamiliar code, and whether they think out loud. When someone genuinely prefers a take-home, I offer one capped at two hours and I read every line that comes back. Assigning six hours of homework and then skimming it is a company telling on itself.
Red flags point both directions
From my side of the table, the flags are consistent: a portfolio project the candidate can't walk through, which is usually someone else's tutorial wearing their name; every previous team described as idiots; "I'd just use a library" as the answer to how anything works; and no questions for me at the end. Curiosity shows up in the interview because it shows up everywhere.
What I watch for in a candidate
- A portfolio project they can't walk through
- Every previous team described as idiots
- "I'd just use a library" as the answer to how anything works
- No questions for me at the end
What you should watch for in us
- Trivia quizzes about CSS edge cases nobody hits
- Five or more rounds
- Unpaid take-homes sized in days
- Interviewers who plainly haven't read your resume
- A company that won't name a salary range
Both lists are my own, from the hiring side and from sitting on the other one
Candidates should keep their own list, and mine would include: trivia quizzes about CSS edge cases nobody hits, five or more rounds, unpaid take-homes sized in days, interviewers who plainly haven't read the resume, and companies that won't name a salary range. That last one is a choice, not an oversight. The Chicago numbers are public enough that I collected them in the salary guide, so silence about pay is telling you something. The interview is the company on its best behavior; it does not improve after you sign.
What a portfolio tells me that a resume can't
A resume says React. A live URL shows me whether the modal traps focus, whether the images have alt text, and whether the layout survives a real phone. Judgment doesn't fit on a resume, and it's visible inside ninety seconds of clicking through something a person finished. That's why my screen starts at the portfolio and treats the resume as its index, and why I wrote a separate note on what that screen looks for. The short version holds at every level: fewer projects, genuinely finished, live at a URL.
Companies standing up an interview loop, or repairing one that keeps selecting the wrong resume, can bring me in; the shape of that engagement is on my services page. Candidates get the cheat sheet for free: the loop above has no tricks in it. Show me something you built and tell me the truth about it. That clears more bars than most people expect.