Before you write a line of code, spend 60 to 90 seconds asking about inputs, constraints, edge cases, and the exact output the interviewer wants. This is not stalling. Coding questions tend to be vague and underspecified on purpose to allow the interviewer to gauge the candidate's attention to detail and carefulness, so you should ask at least 2 to 3 clarifying questions. The candidates who impress do not ask generic questions like "can I use extra space." They ask questions that visibly change the solution they are about to build.
We run mock interviews all day, and the single most common self-inflicted wound we see is a strong coder who solves the wrong problem because they never confirmed what "the problem" was. Below is the playbook we give people: what to ask, in what order, and how to turn a clarifying question into a signal that you think like an engineer.
Why interviewers plant ambiguity on purpose
The vagueness is the test. Many questions are under-specified on purpose, so you should always validate input first, check for invalid, empty, negative, or different-type input, and never assume you are given valid parameters. When you ask about these upfront, you are demonstrating the same instinct a reviewer wants to see in a pull request: distrust of unstated assumptions.
There is a scoring dimension here too. Problem-solving and communication are rated separately from whether your code compiles. A candidate who clarifies scope, states assumptions out loud, and confirms the output contract is generating positive signal before writing anything. A candidate who silently starts typing is betting the whole interview on a guess about intent. For how these signals roll up, see our breakdown of how coding interviews are scored.
One caution: clarifying is not the same as thinking out loud during implementation, and it is not the same as fielding follow-ups after you finish. This playbook is specifically the opening move.
The five categories worth asking about
Not all questions are equal. Random questions read as nervous filler. Structured questions read as senior. Work through these five buckets, and stop once each is resolved.
1. Inputs and types
Confirm what you are actually receiving. Is the input an array, a string, a tree node, a 2D matrix? What are the value ranges? Can values be negative, zero, floats, or Unicode? Clarify if there are duplicate values in the array, because the presence of duplicates can make the question simpler or harder.
Take Clari's most-asked problem, Unique Binary Search Trees. You are given an integer n and asked for the count of structurally unique BSTs with nodes 1 to n. The clarifying questions that matter: what is the maximum n (this decides whether an O(n^2) DP is fine or you need the closed-form Catalan number), and can n be 0? An empty tree is one valid structure, so n = 0 returning 1 is a real edge case, not a trick.
2. Size and constraints
Ask for bounds. "How large can the input get?" is the question that quietly determines your entire approach. If n fits in the thousands, an O(n^2) solution is fine. If it reaches millions, you are being pushed toward O(n) or O(n log n). Constraints are how the interviewer tells you which algorithm they expect without saying it. When you tie your complexity target to a stated bound, you are showing the judgment that separates a mid-level from a senior candidate. This matters most on dynamic programming problems, where the naive recursion and the optimized table can differ by orders of magnitude.
3. Edge cases and malformed input
After you understand the problem statement, ask questions to make everything clear and think of the edge cases: what if the input is empty, or is too big? Name the specific empties: empty array, single element, all duplicates, already-sorted, all-negative.
Clari's second problem, Create Binary Tree From Descriptions, is a clarifying-question goldmine. You are handed a 2D array where descriptions[i] = [parent, child, isLeft]. Good questions surface real behavior: are the descriptions guaranteed to form a valid tree, or could there be a cycle? Is there exactly one root? Can the same parent-child pair appear twice? Are node values guaranteed unique? Each answer changes whether you need cycle detection, how you find the root, and which data structures you reach for. This is a tree problem where a hash table for value-to-node lookup falls out naturally once you confirm values are unique.
4. Output contract
Confirm exactly what you return and in what shape. Do they want the count or the actual objects? Sorted or any order? Indices or values? One-indexed or zero-indexed? In place or a new structure? For Unique Binary Search Trees the ask is a single integer, but a close cousin (Unique Binary Search Trees II) asks you to return every tree. Confirming which one you are solving saves you from building the expensive version of a cheap question.
5. Assumptions to state, not ask
Some things you should assert rather than ask, then let the interviewer correct you. Paraphrase and repeat the question back at the interviewer to make sure you understand exactly what they are asking, and clarify any assumptions you made. Saying "I am going to assume node values fit in a 32-bit integer, tell me if that is wrong" is faster and stronger than asking an open question. It shows you can move.
A 60-second script you can reuse
Here is the sequence we coach. It fits into a minute and works on almost any prompt.
1. Paraphrase: "So I'm given [input], and I need to return [output]. Is that right?"
2. Inputs: "Can values be negative / zero / duplicated? What's the type?"
3. Size: "What's the max input size? That'll drive my complexity target."
4. Edges: "How should I handle empty input or a single element?"
5. Output: "Do you want the count, or the actual result? Any ordering?"
6. Assume: "I'll assume [X] unless you'd rather I handle it. Sound good?"
Notice what this does. By step 3 you have already committed to reasoning about complexity, and by step 6 you have taken a clear position instead of hedging. That editorial confidence is what interviewers remember.
Mistakes that make clarifying questions backfire
Asking questions is not automatically good. These patterns actively hurt you:
- Asking what you could infer. If the examples clearly show duplicates, do not ask whether duplicates exist. Read the examples first.
- Rapid-fire with no purpose. Ten questions with no hypothesis behind them reads as panic. Tie each question to a decision: "If duplicates are allowed, I need a hash map instead of a set."
- Asking, then ignoring the answer. If they tell you the array can be empty and your code crashes on empty input, the clarification was worse than useless.
- Never stopping. Two to three good questions, confirm, then move. Endless clarifying is its own form of avoidance.
- Asking for the algorithm. "Should I use DFS or BFS here?" outsources the problem to the interviewer. Ask about the problem, decide the approach yourself.
The best way to internalize the rhythm is reps. When you practice with realistic mock interviews, force yourself to run the 60-second script every single time until it is muscle memory. In a real interview under stress, you default to whatever you rehearsed.
FAQ
How many clarifying questions should I ask?
Aim for two to three substantive ones, then confirm your understanding and start. The guidance from most interview handbooks is to ask at least 2 to 3 clarifying questions. More than four or five, without tying each to a decision, starts to read as stalling rather than diligence.
What if I ask a question the interviewer refuses to answer?
Sometimes they say "you decide" or "assume whatever is reasonable." That is a signal to state your assumption explicitly and move on. Say what you are assuming, note that you would confirm it in a real system, and proceed. They are testing whether you can make a defensible call.
Should I ask clarifying questions in a phone screen too?
Yes, and arguably more so, because a phone screen has less time and a wrong assumption is more costly. Keep it to the highest-leverage two questions: confirm the output contract and the input constraints, then start. The compressed format rewards candidates who scope fast.
Do clarifying questions matter for easier problems?
They matter most when a problem looks easy, because "easy" problems are where candidates skip scoping and get burned by an edge case. Even for a simple array or string task, confirm empties, duplicates, and output format. The 30 seconds you spend rarely costs you and frequently saves you.