Questions I hope you ask in a frontend interview

Most candidates treat questions as a courtesy round at the end. In my frontend screens, the questions you ask mid-problem are part of what I mark. They show whether you can shrink ambiguity before you ship the wrong slice.

I am Harry Ashton. I built CodePrepped so engineers stop guessing what hiring managers actually listen for. This sits next to the first ten minutes of a pair, what I ask after you finish, and what I mark in a 45-minute screen. Same bar. Different signal.

Photo: fauxels / Pexels.

I am not grading how many questions you ask

Volume is a weak signal. Five questions that do not change your first slice look like nervous filler. One question that changes the acceptance criteria looks like product sense. I care about whether your question unlocks a safer build, not whether you filled silence.

If you never ask anything, I assume you are guessing. If you ask only for permission on every micro-choice, I assume you will not own a ticket. The middle is what I hire: you name the risk, you ask for the constraint, you decide the rest.

Questions that change the first slice

Good questions are boring and specific. They usually sound like this:

• “Is keyboard access in scope for the first cut, or visual-only for now?”
• “Should an empty list show a CTA, a blank state, or keep a skeleton?”
• “Do we optimistically update, or wait for the server before flipping the toggle?”
• “Is this mobile width in scope in the first twenty minutes?”

Each one points at a user-visible decision. Each one lets you protect time. Weak substitutes are “what stack should I use?” when the repo already chose, or “is this okay?” after every three lines.

Product questions I hope you ask

Frontend interviews are still product interviews in disguise. I listen for whether you locate the user:

• Who is blocked if this fails mid-flow?
• What is the recoverable state after a 401?
• Which field is required versus nice-to-have for the MVP path?

You do not need a persona workshop. You need one sentence that shows the UI is for someone other than the interviewer. Candidates who only ask framework trivia rarely notice the empty state until I force it.

Constraint questions that sound senior

Constraints are gifts. Ask for them early:

• Time: “If we only ship one interaction, which one matters?”
• Dependencies: “Can I add a library, or should I stay in the existing toolkit?”
• Accessibility: “Is focus management part of the bar for this screen?”
• Data: “Is the API paginated, or should I assume a small list?”

When you invent constraints without asking, you risk polishing the wrong thing. When you ask and then ignore the answer, that is worse. Write the constraint down in a comment or a one-line note in the PR description habit — even in a live screen, say it out loud so I hear you bind to it.

Questions that waste the clock

These rarely help, and they often cost trust:

• Asking me to design the component tree for you.
• Asking which colour token to use before any behaviour works.
• Asking whether TypeScript is “required” when the repo is already strict.
• Asking for the “best” state library as a stall when local state would do.

If you are stuck, narrate the fork and pick one. “I will keep this in component state for the first slice; we can lift it if a sibling needs it” is a decision. “What would you do?” ten times is pair-programming me into your solution.

How this differs from the follow-up round

After you finish, I ask follow-ups about ownership and failure modes. During the build, your questions are the inverse: you are probing the brief so those failure modes are smaller. Silence during the build plus perfect vocabulary in the follow-ups still reads as practised narration, not product judgment.

In a take-home, the README is where those questions should already be answered in your assumptions list — see what I actually open. In a live screen, your voice is that README.

What a pass sounds like

A pass is short and binding:

• you ask one or two constraints that change the slice,
• you restate the goal in your own words,
• you stop asking once the path is clear,
• you surface a new question only when the requirements move.

I should be able to repeat your plan back to you. If I cannot, you have not made it crisp enough yet — and a clarifying question is the fix, not a longer monologue.

What a soft no sounds like

Common soft nos around questions:

• zero questions, then surprise when the brief had an obvious fork,
• questions that only seek reassurance (“is this fine?”) with no proposed option,
• debate-club questions that delay shipping,
• ignoring a clear answer and building the opposite,
• saving every question for the last two minutes as theatre.

Curiosity without ownership is still a miss. Ownership without curiosity often ships the wrong thing. I hire the loop: ask, decide, ship, verify.

How to practise without scripting a Q&A

Do not memorise a list of “smart questions.” Practise a loop on a tiny prompt:

1. Read the brief once. Write three forks that would change the first slice.
2. Pick the one fork that is highest risk for the user.
3. Ask that question out loud, then build as if the answer were the stricter option.
4. After ten minutes, note whether the question actually saved rework.

CodePrepped’s daily loop and Code Arena bouts are built for that rhythm: short reps, visible states, then a review pass. If you only practise silent LeetCode, the live clarifying round will feel optional. In frontend hiring it is not optional. It is how I tell whether you can run a ticket without me in the room.

Should I ask questions at the very start?

Yes, one or two that change scope. Then start. A five-minute interrogation with a blank screen is not senior behaviour.

What if the interviewer gives a vague answer?

Propose a default. “I will assume optimistic UI and call that out in a comment.” Vague briefs are common on the job. Owning a default is the skill.

Is it bad to ask about accessibility?

No. Asking whether focus order is in scope for the first cut is a strong signal. Asking me to list every WCAG criterion is not. Bind it to the UI you are about to build.

Do system-design questions count here?

Only when they shrink this screen’s risk — caching, client versus server state, or how errors surface. Save whiteboard epics for a round that asks for them.