The question you should ask before you answer

The worst answer in a rehearsal is rarely the least knowledgeable one. It is the one that answers a different question, confidently, for three minutes.

The candidate hears "design a rate limiter" and starts sketching a token bucket. The interviewer meant a rate limiter for one internal service with a known caller, not a public API with abusive clients. The answer is coherent. It is also about a system nobody asked for.

A clarifying question would have changed the answer. It would also have shown the interviewer something the answer cannot: that you know which assumptions matter.

What a question buys you

An interview question is usually underspecified on purpose. The missing details are the decision space:

• Scale. A thousand requests a day and a million a second are different problems.
• The constraint that wins. Cost, latency, consistency, or operational simplicity. You cannot optimise all four at once, and the interviewer usually has one in mind.
• The boundary. What is already built, what you are allowed to assume, and what is out of scope.
• What "done" means. A working prototype, a design that survives an audit, or a migration with no downtime.

You are not asking for the answer. You are asking which answer is being graded.

The question is part of the signal

Interviewers are told to assess communication, not only knowledge. A candidate who states an assumption and checks it is easier to work with than one who disappears into a whiteboard for ten minutes. The question is evidence of the same judgement the rest of the interview is trying to measure.

The failure mode is not asking too much. It is asking nothing and then defending a design built on a guess.

How to ask without stalling

One question, one assumption, then an answer.

"Before I start: is this public-facing, or internal? I will assume public and design for abusive clients unless you tell me otherwise."

That sentence does three things. It names the fork, states the default you will use, and gives the interviewer a chance to correct it. You are not waiting for permission. You are making your reasoning visible.

If the interviewer says "you decide", decide out loud and keep going. The point is not to extract a spec. It is to show that you know a spec is missing.

What not to ask

Avoid questions whose answer is in the posting, the prompt, or the last sentence the interviewer said. Avoid a list of five questions before you have thought for ten seconds. Avoid using the question to delay the part where you have to commit to something.

The useful question is narrow, tied to a decision you are about to make, and answerable in one breath.

Practise the move, not the hint

Most rehearsal tools grade the answer. That is the visible part, but the move before the answer is the one you can carry into a real room.

In a rehearsal, you can ask the interviewer for constraints before you answer. The answer stays beside the question for the rest of the session, it is not written into the transcript, and it does not change your grade. The point is to practise asking, not to collect hints.

The next time you rehearse, pick one question you would normally guess at. Ask it first. Then answer with the assumption stated. The answer will be shorter, more specific, and easier to defend.

That is usually the difference between a correct answer and a good one.