What I ask after you finish the frontend coding problem

Most candidates treat the coding problem as the whole interview. In my frontend screens, the slice you ship is the warm-up. The follow-ups after you finish are where I learn whether you can own a change in production, or whether you only practised the happy path.

I am Harry Ashton. I built CodePrepped so engineers stop guessing what hiring managers actually mark. This sits next to the first ten minutes of a pair and what I mark in a 45-minute screen. Same bar. Later clock.

Photo: fauxels / Pexels.

I am not trying to trip you up

Follow-ups are not a gotcha round. I already saw you write. Now I need to know how you think when the requirements move, when something breaks, or when another engineer has to live with your choice.

If you freeze, I will rephrase. If you ask a clarifying question, that is a pass signal, not a stall. Silence after “any questions?” with nothing behind it is the soft fail.

What I ask about the code you just wrote

I start on the file you left open. Typical prompts:

• Walk me through the data flow from the click to the UI update.
• Which part would you extract if this grew one more feature?
• Where would a junior get lost reading this tomorrow?
• What would you test first if we only had twenty minutes?

I am listening for ownership language. “This handler owns the loading state” beats “React just re-renders.” Naming the boundary you chose matters more than reciting the framework docs.

The requirement change

Almost every strong hire has lived through a late change. I will add one realistic twist: empty states, offline, a second role, or a loading race. Then I watch whether you:

• restate the new constraint in your own words,
• point at the smallest place to change,
• protect the existing happy path,
• say what you would defer.

Candidates who rewrite half the file to show off lose time and clarity. Candidates who say “I would keep the current slice and gate the new branch behind a flag” usually understand product work.

Failure modes I actually care about

I ask what breaks. Not “list every error.” Specifics:

• What happens if the fetch returns 401 mid-session?
• What if two clicks land before the first response?
• What if the list is empty on a Monday morning?

Good answers name a user-visible state and a recovery path. Weak answers jump straight to try/catch folklore with no UI consequence. Frontend interviews are still UX interviews in disguise.

Performance without the buzzword bingo

If performance comes up, I do not want a tour of every memoisation API. I want you to pick one bottleneck you can justify from the code on screen. Example: “This list re-renders on every keystroke because the filter lives in the parent. I would move the filter or memo the row.”

If you cannot point at a line, do not invent a lecture. “I would measure with the React profiler before changing anything” is a stronger senior signal than a premature useMemo.

Accessibility I expect you to notice

I will ask one accessibility question tied to your UI. Focus order after a modal. Button vs div. Label association. Reduced motion if you added an animation. I am not running a WCAG audit in fifteen minutes. I am checking whether accessibility is part of your default checklist or an afterthought you hope I skip.

If you built interactive controls, I expect you to know how a keyboard user leaves them. If you do not, say so and outline how you would verify. Guessing ARIA roles you cannot defend costs more than an honest gap.

How you talk about trade-offs

I often ask: “What did you deliberately not do?” Strong candidates list a cut scope, a deferred abstraction, or a test they would add next. Weak candidates claim the solution is complete and general. Shipping judgment shows up as what you refused to gold-plate under time pressure.

This connects to how I read take-homes in what I actually open. The story after the code is the same story: decisions, not decoration.

What a pass sounds like

A pass is calm, specific, and tied to the session:

• you can narrate your own code without rereading every line,
• you absorb a requirement change without panic,
• you name one failure mode and one test,
• you leave a breadcrumb for the next engineer.

You do not need perfect vocabulary. You need a trail I trust.

What a soft no sounds like

Common soft nos after a correct-looking solution:

• cannot explain the data flow you just wrote,
• every follow-up becomes a framework trivia dump,
• no idea what the user sees when the network fails,
• accessibility and tests only appear when I force the topic,
• defensive answers when I change the requirement.

The coding problem proved you can type under watch. The follow-ups prove you can own the change.

How to practise without scripting yourself

Do not memorise follow-up answers. Practise a loop:

1. Ship a small interactive slice with loading, empty, and error states.
2. Close the editor and explain the data flow out loud for two minutes.
3. Have a friend change one requirement and force a minimal edit.
4. Write three tests you would add if the clock restarted.

CodePrepped’s daily loop and Code Arena bouts are built for that rhythm: short reps, visible states, then a review pass — not silent LeetCode with no narration. If you only practise green paths, the follow-up round will feel unfair. It is not. It is the job.

FAQ

Do I fail if my first solution was messy?

Not by itself. I care more about whether you can clean the mental model in the follow-ups than whether the first draft was elegant.

Should I bring up tests before you ask?

Yes, briefly. Name the riskiest path and how you would cover it. A monologue about coverage percentages helps nobody.

What if I used a library I cannot defend?

Say why you reached for it and what you would replace it with under a tighter constraint. Blind dependency choice is a yellow flag; honest constraint talk is not.

Are system design questions part of this?

Sometimes as a short bridge: caching, client vs server state, or how this screen talks to an API. I keep it anchored to the problem you solved, not a whiteboard epic.