5 exercises on confirming constraints, input ranges, and expected output before you write a line of code.
Key patterns
Just to clarify, should it return X or Y? — pin down the output.
How large can the input get? — tie scale to complexity.
How should I handle invalid input? — confirm the contract.
Let me make sure I have got this right... — restate, then check.
0 / 5 completed
1 / 5
The interviewer says: Write a function that finds duplicates in a list. Before coding, you want to confirm the expected output. Which question is most natural?
Clarify the shape of the output before you design.
The output type drives the whole solution, so confirm it first. The softener Just to clarify... is the most common natural opener. Note how the good option offers concrete options (values vs boolean vs counts) rather than an open vague question:
Just to clarify, should it return X or Y?
What should the function return when there are no duplicates?
Do you want the result sorted, or is any order fine?
Option B is too basic and slightly rude; C silently assumes (the mistake to avoid); D conflates language choice with the actual ambiguity. Offering a small menu of expected outputs shows you understand the design space.
2 / 5
You need to know how big the input can get so you can pick an algorithm. Which is the best question about input ranges?
Tie the constraint question to a decision you must make.
Asking about scale is most persuasive when you explain why it changes your approach. Phrases for constraints:
Roughly how large can the input get?
What are the constraints on n?
Is there an upper bound I should design for?
The strong option links size directly to complexity (O(n²) vs linear), proving you think about scalability. Option A is vague; C silently assumes; D is a closed yes/no that yields no useful number. In a real interview, knowing n often decides between brute force and a hash-based or two-pointer technique.
3 / 5
It is unclear how the function should behave on invalid input (e.g. null). Which question best confirms error-handling expectations?
Confirm the contract for invalid input.
Error behaviour is part of the function's contract and interviewers love that you ask. Offer the realistic options: throw, return a sentinel, or assume valid input. Phrasing:
How should I handle invalid input?
Can I assume the input is always well-formed?
Should I validate, or is that out of scope here?
Option A is dismissive; C ignores robustness; D is too vague to get a useful answer. Naming the concrete alternatives (throw / return null / assume valid) shows you know the standard contracts and keeps the interview moving.
4 / 5
You want to restate the problem in your own words to confirm you understood it. Which is best?
Play the problem back precisely before coding.
Restating in your own words catches misunderstandings early and is a hallmark of strong communicators. The natural frame is Let me make sure I have got this right... followed by a precise paraphrase and a yes/no check. Useful patterns:
Let me make sure I have understood: ...
So, to confirm, the goal is to... — is that right?
In other words, I need to..., correct?
Option A is sloppy; C skips the confirmation; D shifts effort back to the interviewer and signals you were not listening. A crisp paraphrase that names the input, output, and a key constraint (order here) is ideal.
5 / 5
Mid-problem the interviewer mentions the list might be streamed rather than fully in memory. What is the best follow-up clarification?
Probe a new constraint and check its implications.
When the interviewer adds information, confirm what it implies for your design rather than freezing. Here the key implications are memory limits and single-pass processing. Phrases:
Does that mean I cannot keep everything in memory?
Should I optimise for a single pass?
So latency matters more than total throughput here?
Option A and D show poor composure; C ignores a constraint that fundamentally changes the solution. Echoing the constraint back as a precise design question (single pass, bounded memory) keeps you in control and demonstrates systems thinking.