Clarifying Questions to Ask in Coding and System Design Interviews

Ask clarifying questions about the inputs, the expected output, the scale and the edge cases before you choose an approach. In a coding interview that is usually two to five questions; in a system design interview, enough to pin down the features and the numbers. Ask only questions whose answers change what you build, repeat each answer back, and write it down where you can see it.

Why interview problems leave things out

Interview prompts are short on purpose. A real task arrives underspecified too, and part of what the interviewer wants to see is whether you notice what is missing before you build on a guess. Companies say so in their own preparation material. Meta's guide for software engineers tells candidates in the system design round to "be sure to ask clarifying questions", and Amazon's SDE II preparation page says that in system design "you should ask questions to complete and validate your design."

There is a practical reason as well. A question asked in the first two minutes costs ten seconds. The same misunderstanding discovered after twenty minutes of code costs the interview. "Can the list be empty?" and "are the IDs unique?" are cheap insurance.

One honest caveat: asking questions is not the same as communicating well. On Devana's coding rubric, clarifying questions count toward approach planning, but asking them on their own earns little. What scores is the plan you make with the answers. Interviewers react the same way: a list of questions followed by a plan that ignores them is worse than no questions at all.

The questions that matter in a coding interview

Most coding questions you need fall into five groups. You will not ask all of them; scan the list and ask the two to five whose answers you cannot infer from the prompt or the examples.

Inputs

• What type are the values: integers, floats, strings, Unicode? Can numbers be negative or zero?
• How large can the input get? (This decides whether O(n squared) is acceptable.)
• Is it sorted? Can it contain duplicates? Can it be empty or null?
• Does it fit in memory, or does it arrive as a stream?

Output

• What exactly do I return: the value, its index, all matches, or a count?
• If several answers are valid, which one, or does any one do?
• Does the order of the output matter? How are ties broken?

Edge behavior

• What should happen on invalid input: return a sentinel, raise an error, or can I assume it is valid?
• What if no answer exists?

Constraints on the solution

• May I modify the input in place, or should I leave it untouched?
• Is there a memory limit, or a single pass requirement?

Context

• Will this be called once or many times on the same data? (Many calls can justify preprocessing.)

Take diffing two enormous sorted indexes: two sorted lists of document IDs, find what was added and removed. The questions worth asking are whether the lists fit in memory (no, which rules out sets), whether IDs can repeat within a list (no, which keeps the merge simple), and whether the output must be in ID order (yes, which the merge gives for free). Three answers, and the approach is decided.

The questions that matter in a system design interview

In system design the prompt is even thinner, and scoping is part of the work. Spend the first five to eight minutes here. Group your questions so the interviewer can see the structure:

• Features. Which features are in scope? Which can we leave out? Who are the users?
• Scale. How many users, requests per second, reads versus writes? How much data, and for how long?
• Performance. What latency is acceptable, and for which operations?
• Consistency and availability. May some reads be stale? What happens if part of the system is down?
• Constraints. Any existing systems to build on, regions, compliance or budget limits?

Here is how that sounds on designing a URL shortener:

You: Before I draw anything: the core is creating a short link and redirecting. Are custom aliases, expiry and click analytics in scope, or should I focus on create and redirect?

Interviewer: All three are in scope, but redirect is the priority.

You: How many links in total, and how many redirects a second at peak?

Interviewer: About a hundred billion links, a hundred thousand redirects a second.

You: Any latency target for the redirect? And do analytics need to be real time, or is a few minutes' delay fine?

Interviewer: Under twenty milliseconds at p99. Analytics can lag.

You: Good. So: a read-heavy service, redirects must come from a cache, and analytics can be written asynchronously, off the redirect path. A hundred billion links means seven characters of base 62. Let me write those down and start from the redirect.

Every answer turned into a design decision on the spot, and the candidate said so. That last line is what makes the questions count: it shows the interviewer that you asked in order to use the answers.

How to ask them

• Propose instead of asking open questions. "I'll assume the input fits in memory; is that right?" is faster than "how big is the input?", and it shows you already know why it matters.
• Batch them. Ask two or three together rather than one at a time over five minutes.
• Repeat the answers back. "So, no duplicates and the list can be empty." It catches mishearing, which is common over video.
• Write them down. As comments at the top of the editor in a coding round, or in a corner of the whiteboard in a design round, where you and the interviewer can both refer to them later.
• Stop when the answers stop changing the design. Three good questions beat ten generic ones.
• Ask again later if you need to. Discovering a question halfway through is normal; say why it came up.

Example phrases

• "Before I start, a couple of questions about the input."
• "Can I assume the values are integers, and that the list isn't empty? If it can be empty, I'll return an empty result."
• "If there are several valid answers, is any one fine?"
• "What's the rough size of n? That decides whether I need better than quadratic."
• "Which features matter most? I'd like to focus the design on those and mention the rest."
• "Roughly how many requests a second, and what's the read to write ratio?"
• "Is it acceptable for a user to see slightly stale data here?"
• "So, to summarize what I'm building: ..."

Questions not to ask

• Ones the prompt already answers. Read the statement and the examples twice first; asking what is written signals you did not.
• "Which data structure should I use?" That is the problem you are being asked to solve. Propose one and say why.
• A dozen questions in a row. It delays the work without changing it. Prioritize the ones that move the design.
• Questions about the company's real stack. "What does your team use for this?" belongs at the end of the interview, not in the design.
• Questions you will not use. If the answer would not change anything you do, skip it.

When the interviewer says "you decide"

Some interviewers deliberately leave the choice to you, to see whether you can make a reasonable call. Do not keep asking. State an assumption, give a one-line reason, and design for it: "I'll assume up to a million items, which fits in memory, so I'll load them. If it were much bigger I'd stream them instead." That is often a better signal than the answer would have been, and it leads naturally into the trade-off discussion. How to explain trade-offs in a system design interview picks up from there.

Practicing it

The habit to build is reading a prompt and asking "what would change my answer?" before anything else. Try it on the worked problems by pattern: before opening the hints, write the two or three questions you would ask, then check them against the constraints. Then do it live, with someone who answers. How to think out loud in a coding interview shows how the questions lead into the rest of the conversation, and Devana's coding and system design mock interviews give you an interviewer who answers your questions out loud. In the design round, requirements scoping is the largest single communication metric, 30 of 100 points.

Frequently asked questions