How to ask clarifying questions in a technical interview

Clarifying questions that change the answer

1. How large can the input get, and does it fit in memory?
2. Can values repeat, be negative, be empty or be null?
3. Is the input sorted, or can I sort it?
4. Should I optimise for time, memory or readability?
5. What should happen on invalid input — throw, return a sentinel, or ignore?
6. Is this called once, or many times on changing data?
7. For design: how many users, what read/write ratio, and what latency is acceptable?

Why interviewers want you to ask

Interview problems are deliberately under-specified. The interviewer is watching whether you notice that, because real work arrives the same way. A candidate who asks whether the array can be empty, then handles it, has shown judgement before writing a line. A candidate who dives straight in and handles it by accident has shown nothing. Most rubrics have an explicit line for problem understanding, and clarifying questions are the cheapest points available.

Coding versus system design

In design rounds the clarifying phase becomes requirements gathering: functional requirements (what it does), non-functional ones (scale, availability, latency), and back-of-the-envelope estimates. Our estimation interview guide covers the numbers part.

How to stop asking

Asking too many questions looks like stalling. Stop when the remaining unknowns would not change your approach, and turn the rest into stated assumptions: “I'll assume the input fits in memory; if not, I'd stream it.” Assumptions show the same judgement as questions without using the interviewer's time, and they give the interviewer a natural moment to redirect you.

Phrases that work

• “Before I start, can I check a few constraints?”
• “Should I expect duplicates, or can I assume unique values?”
• “Is it more important to get something working first, or to aim for the optimal solution?”
• “Let me restate it to make sure I have it: … Is that right?”
• “I'll assume X for now and come back to it if we have time.”

A worked example

Problem: “Given a list of meeting times, return the minimum number of rooms needed.” A strong opening sounds like this. “Before I start — are the times integers, and can a meeting end at the same moment another starts? If one ends at 10 and another starts at 10, do they share a room? Roughly how many meetings — thousands or millions? And can the list be empty?” Suppose the interviewer says integers, yes they can share, up to a hundred thousand, and yes it can be empty.

Restate: “So I'm returning the peak number of overlapping meetings, where touching endpoints don't overlap, for up to 100k meetings, and zero for an empty list. I'll aim for O(n log n) by sorting starts and ends separately and sweeping.” Then write two test cases from the answers: an empty list returns 0, and [[1,10],[10,20]] returns 1 because touching meetings share. Notice that two of the four questions changed the code — the tie-breaking rule decides whether ends are processed before starts at the same time — and the size question justified the algorithm choice. That is what good clarification looks like: every question earns its place.

Practising the habit

Clarifying is a habit, not knowledge, so it only sticks with out-loud practice. Take any practice problem, set a two-minute timer and say your questions aloud before touching code. Then write two test cases that came from your questions. After a dozen problems it becomes automatic. A free AI interview assistant can play the interviewer for this: CoPilot Interview's mock interviews let you ask clarifying questions and see whether your restatement matched the problem. See also what to do if you don't know the answer.

Disclosure: CoPilot Interview is our product, so weigh what we say about it accordingly. Everything else on this page applies whichever tool you use, or none.

Frequently asked questions

How many clarifying questions should I ask in a coding interview?

Usually three to five, covering input size, edge cases, ordering and what to optimise. Stop when the remaining unknowns would not change your approach, and state the rest as assumptions.

Is it bad to ask clarifying questions in an interview?

No — interviewers expect them, and most rubrics reward problem understanding. Asking too many, or asking things you could reasonably assume, is the only risk.

What should I ask in a system design interview?

Ask about users and scale, the read/write ratio, latency targets, consistency needs and which features are in scope. Turn the answers into a short requirements list and rough numbers before designing.

What if the interviewer won't answer my question?

Some interviewers say “you decide”. Pick a reasonable assumption, say it out loud with a reason, and move on. That is exactly what they wanted to see.