Stage 3 — Technical interview

60–90 minutes with frontend leadership. The most demanding stage. Some combination of: technical discussion, live coding exercise, design exercise, and possibly a take-home that you walk through. The bar isn't perfection — it's thinking like a senior engineer out loud.

01What this stage probably looks like

For senior frontend roles, common formats:

1. Discussion-heavy — they ask you about systems, patterns, trade-offs. Walk through how you'd build X, debug Y, scale Z.
2. Take-home review — they give you a small project beforehand and use the interview to walk through your code.
3. Live coding — pair on a small problem in real time. Sometimes a CodeSandbox / repl, sometimes whiteboard pseudocode.
4. System design — "design the frontend for an inventory dashboard with X requirements." More common at staff level but possible.

Likely some combination of 1 + (3 or 4). Plan for both.

02Discussion topics they'll probe

Reread these technical pages the day before:

03Live coding strategy

The protocol — say these things in order, regardless of the problem

1. Restate the problem in your own words. "So if I'm understanding right, we need to..." Catches misunderstandings before you write code.
2. Ask clarifying questions. What's the data shape? What edge cases? Performance constraints? Network failure? Empty state? "These are the kinds of questions I'd normally ask before starting." This is the most senior thing you can do.
3. Sketch the approach out loud. "I'm thinking I'll start by... then handle... and treat X as a stretch goal." This lets them course-correct early.
4. Talk while you code. Narrate your thinking. The interviewer learns more from your reasoning than your typing.
5. Test as you go. Run the code, console.log values. Don't write 80 lines and pray.
6. Acknowledge what you'd do with more time. "I'd extract this into a hook, add tests, and handle X edge case — happy to do any of those if useful."

Common live-coding prompts to expect

04Take-home strategy

If they sent a take-home before the interview, the interview is a code review of your submission. Prep:

1. Reread your own code. You wrote it days or weeks ago. Refresh.
2. Write a 1-page README — what you built, what you'd improve given more time, what trade-offs you made and why. Hand it to them at the start of the interview if possible.
3. Have an opinion on every choice. "I used X because Y. I considered Z but it was overkill for the scope."
4. Identify your weakest code. They will find it. Beat them to it: "I'm not happy with how I structured X — given more time I'd refactor to Y."
5. Prepare answers for likely follow-ups — how would you scale this, how would you test it more thoroughly, how would you handle X edge case.

05System design exercise

The 6-step protocol

1. Clarify scope. "What's the user flow? How many users? Real-time? Mobile? Offline-first?" 2–3 minutes here is well spent.
2. Define the surface. Sketch the main screens or features. "Sounds like we have these views: dashboard, detail, edit, list."
3. Identify the hard parts. What's actually challenging here? Real-time sync? 100k rows? Offline edits? Auth flow? Multi-tenant?
4. Walk through the architecture. Routing, data flow, state architecture, component boundaries. Reference real tools: TanStack Query for server state, Zustand for client, React Router for routing, react-hook-form for forms.
5. Address each hard part with a specific approach. "For the 100k rows: virtualization with AG Grid in server-side row mode, push grouping to the backend."
6. Acknowledge trade-offs and what you'd defer. "I'd start with X. If we hit Y problem, I'd reach for Z. Without that, it's premature."

Likely prompts

• "Design the frontend architecture for an inventory management dashboard."
• "How would you build a real-time collaborative editor?"
• "How would you migrate a legacy frontend incrementally?"
• "Design a multi-tenant SaaS frontend that supports white-label theming."
• "Design a frontend for a shop floor / production tracking screen — high-density data, frequent updates."

06Code review you might be asked to do

Some interviewers hand you a piece of (intentionally flawed) code and ask "review this." What they're testing: your eye, your priorities, your communication.

Common bugs / smells they'll plant:

• Missing useEffect cleanup
• Stale closures in event handlers
• Array index used as key
• Mutating state directly
• Inline object/function passed to memoized child
• useState dependent on props that should derive instead
• Async function passed to useEffect (you can't make the effect itself async)
• Missing error / loading states
• Inaccessible markup — div onClick, missing labels

Approach: scan the code top to bottom, identify issues at three levels — bugs (definitely wrong), smells (questionable), and stylistic preferences (last priority). Talk through them in that order. Distinguish "must fix" from "I'd suggest" — that's senior judgment.

07What they're scoring

08If you get stuck

You can also ask for a hint. "If you're willing to nudge me, I'd take a hint here." Most interviewers will, and how you take the hint and run with it is itself a signal.