Clarifying Questions to Ask in a Technical Interview

Why ask it

Keep it to two sentences: what comes in and what you hand back. A correction at this point costs seconds, and the same misread found after the code is written means starting again. If the interviewer simply agrees, write your version at the top of the editor and check your finished code against it.

Why ask it

Trace it by hand and say each step aloud. Examples carry rules the wording left out, such as the order of the results or whether an item can be used twice. When the interviewer's expected output differs from yours, stop and find out why before you design anything.

Why ask it

Each of these is a different amount of work. A yes or no lets you stop at the first hit, while returning positions means you cannot sort the input without keeping the original indexes. Write the return type into the function signature before anything else, so a mismatch shows while it is still one line to change.

Why ask it

'Any valid answer' is the easy case, and you can return the first one you find. 'The smallest', 'the earliest' or 'all of them' each add a requirement that changes the loop. For a ranked list, ask how ties are broken as well: alphabetical or first-seen order means a second sort key, which is easier to build in than to add later.

Why ask it

Substring and subsequence, subarray and subset: these pairs sound alike and lead to different algorithms. Checking a term takes one breath. Do the same for any word in the prompt that could be read two ways, such as 'unique', 'valid' or 'balanced'.

Why ask it

Starter code usually arrives with a signature, and its types are most of the specification: what comes in and what goes out. A recursive solution tends to want an extra argument such as an index or a running total, and if the signature is fixed you wrap a helper around it. With no starter code and raw input to read yourself, parsing is part of the task, so leave minutes for it.

Why ask it

An exercise lets you skip input checks and mention them instead. If the reply is 'production', naming, error handling and tests become part of what is being judged, and it is worth saying which you are adding as you go. The reply is often somewhere in between, so ask what they would like to see handled.

Why ask it

Some interviewers hold an extension in reserve and some will not say, which is fine. If one is coming, keep the first solution simple and easy to change, and do not spend ten minutes polishing it. It also tells you how to split the clock.

Why ask it

No other answer does as much to choose the algorithm. A few hundred items forgives a nested loop, while millions push you toward one pass or a sort. If you hear 'assume it fits in memory', repeat that as a stated assumption and keep going.

Why ask it

Decimals make equality checks unreliable and rule out using a value as an array index. Mixed types mean you need a rule for comparing them, which you should ask for and not invent. In a typed language the answer goes straight into the signature.

Why ask it

Negative numbers quietly break several familiar shortcuts, including a sliding window over sums and stopping early once a total passes the target. Zero matters wherever you divide or multiply. If everything is positive, say that you are relying on it, since that is where a follow-up tends to push.

Why ask it

A small known range, such as ages or scores out of 100, lets you count into a fixed array instead of sorting. At the other end, sums, products and counts of combinations are what overflow. In Java or C++ the answer picks between an int and a long, and in Python you only need to mention that the language handles it.

Why ask it

Duplicates decide between a set and a map of counts. They also raise a second question: if the input repeats, may the output repeat too, or should each result appear once? Problems about pairs and triples are where skipping this hurts most.

Why ask it

Sorted input is a strong hint toward binary search or two pointers, and it is seldom mentioned for no reason. If it is not sorted, follow up by asking whether you may sort it yourself. That costs time and loses the original positions, which matters when the answer is an index.

Why ask it

Permission to modify in place can save all the extra memory: you can sort the array, mark visited cells in the grid, or reverse the list where it sits. If the caller needs the data untouched, say you will work on a copy and count that copy in your memory use.

Why ask it

Lowercase letters only means a fixed array of 26 counters will do. A wider character set calls for a map, and with full Unicode even 'one character' needs defining. Say which you are assuming as you declare the counter, so the choice is on the record.

Why ask it

Palindrome and anagram problems turn on this. If case and punctuation are ignored, normalize the string once at the top and the rest of the code stays simple. If they count, 'Aa' is two different characters, and one of your test cases should include it.

Why ask it

With a stream you cannot sort, look back, or know the length, so the solution has to keep a small running state such as a heap or a few counters. 'All at once' is the common answer, and asking took five seconds. Keep it in mind after you finish, because 'now suppose the input never ends' is a natural second part.

Why ask it

The representation decides your first ten lines. An edge list usually has to be turned into an adjacency map before you can traverse it, and a grid is a graph whose neighbors you compute. For a tree, check whether it is a binary search tree or only a binary tree, because the ordering is what makes the fast solutions possible.

Why ask it

Returning zero, returning an empty list and raising an error are all defensible, so the interviewer's preference is the specification. Write the check as the first line once you know. While you are there, think about a single element too, since loops that compare neighbors often fail on a list of one.

Why ask it

'Assume it is valid' frees you to spend the time on the algorithm, and you can list in a sentence what you would check in real code. If validation is wanted, ask what should happen on bad data: skip the record, return an error, or stop. Those three lead to different code, so get one named before you write the check.

Why ask it

A search that finds nothing or a target that cannot be reached is often left undefined until the code trips on it. Settle the return value before coding and the final line of the function writes itself. Then use that exact case as one of your tests.

Why ask it

If each position may be used once, a target of 10 with a single 5 has no answer, and your lookup must not pair an item with itself. If reuse is unlimited, as with coin denominations, you stay on the same item instead of moving past it, which is a different loop. Check your reading against the worked example before you plan.

Why ask it

On interval problems this one answer is the difference between a less-than and a less-than-or-equal in your comparison. Ask it with a concrete pair, such as a meeting that ends at 2 and another that starts at 2. Then check whether the endpoints are inclusive, which is the same trap in a different place.

Why ask it

Four directions or eight is a one-line change if you keep the moves in a small list, and a painful one if you wrote four separate if statements. While you are on the subject, ask whether the edges wrap around and which cells are blocked. Two islands that touch only at a corner make the test case that shows which rule you coded.

Why ask it

A cycle without a visited set is an infinite loop, so the answer decides whether you need one. A graph in several pieces means starting a traversal from every node, not only the first. The linked-list version is worth asking too: can the list loop back on itself?

Why ask it

Ask it after you have named your own, not instead of naming them. It invites the interviewer to hand over the one their test cases are built around. If the question comes back as 'which do you think matter?', give three, say which you will handle first, and carry on.

Why ask it

Some interviewers will name a target and some will say 'as good as you can get', which tells you the obvious solution is not the last stop. If they do give one, it is a strong clue: linear time points to a hash map or a single pass, and logarithmic time points to binary search or a heap.

Why ask it

'Use what you need' opens up hash maps and memo tables, the usual way to buy speed. A request for constant extra space rules those out and steers you toward pointers, swaps and reusing the input. State the space your approach uses when you describe it, so the trade is visible.

Why ask it

This is the plain way to ask what to optimize for. A reply about the setting helps most: a phone, a batch job overnight, a request a person is waiting on. With no steer either way, go for the faster version, state the memory it costs, and describe the leaner alternative in a sentence.

Why ask it

Repeated calls change the answer. It becomes worth sorting once, building an index or caching results up front, so each later call is cheap, where for a single call that setup is wasted work. When the reply is 'many times', split the code into a build step and a query step and give the cost of each.

Why ask it

It comes up when you are asked to build something that holds state, such as a cache, a counter or a rate limiter. In a coding round the reply is frequently no, and a one-line comment saying so is enough. A yes means a lock or a concurrent structure around the shared data, and you should say what the lock protects and what it costs in throughput.

Why ask it

Choose the language you are quickest in if the choice is yours. The library half matters more than it sounds: a built-in sort, heap or deque can remove half the code. When the task is to build that very structure, expect a no, and ask which parts you may still lean on.

Why ask it

If it will be executed, leave time to run it and fix typos, and test early with a small case. If not, spend that time tracing by hand, and do not stall over a method name you half remember. How this works differs by company and by round, so it is fair to ask the recruiter beforehand as well.

Why ask it

Knowing whether one problem or two is planned tells you how long clarifying, coding and testing can each take. If the interviewer says there is a second question waiting, cut the discussion short and get a working answer down. Glance at the clock again when you finish the first draft.

Why ask it

Asking first turns a silence into a plan, and the interviewer knows you have not frozen. Come back with something concrete, even if it is only the brute force and why it is too slow. If the interviewer would rather hear you think aloud, do that: the reasoning may be what they are there to see.

Why ask it

Describing the brute force in one sentence, with its cost, is a safe opening either way. Whether to code it is the real question. When time is short, typing out the slow version can leave nothing for the better one, so ask before you commit the minutes.

Why ask it

Give the idea in three or four sentences with its time and space cost, then ask. A nod means go, and a question back such as 'what happens with duplicates?' is a hint that the plan has a hole, delivered before you spent fifteen minutes typing. Do not expect a verdict on whether it is optimal.

Why ask it

This sets the working rule for the rest of the session. Some interviewers want every question, others want to see you decide. Whichever it is, write each assumption as a comment so it can be challenged, and so you remember it when a follow-up changes it.

Why ask it

It keeps the main logic in one readable piece. For something routine, such as checking a palindrome or swapping two elements, you may be told to skip the body entirely. If the helper is where the hard part lives, the interviewer will ask you to write it, and that tells you where the problem's weight sits.

Why ask it

This is how to ask for a hint without asking for the answer. Naming the exact obstacle, for example 'I can find the pair but not without checking every combination', lets the interviewer give a small nudge. Long silence is the worrying alternative, because nobody can help with a thought they cannot hear.

Why ask it

Say what is wrong with the current path in one sentence, for instance that this data structure forces a nested loop. With five minutes left, a slow answer that works is the safer thing to leave on the screen, and you can say what you would change. Deleting code without a word is the worrying version, because the interviewer cannot tell a plan from a panic.

Why ask it

Offer this before you are asked. Pick one ordinary input and one edge case you agreed on earlier, and follow the variables line by line instead of reading the code and nodding. If you find a bug, say so and fix it calmly: one you catch yourself counts for you, and one the interviewer has to point out does not.

Why ask it

Save it for when you believe the code is right and have run your own cases. 'Try an empty string' is a gift: trace it at once. Before asking, check the riskiest lines yourself, usually a loop boundary and the first and last element, so the interviewer's case is not one you could have found.

Why ask it

With minutes left you can rarely do both. If speed is the request, say where the time goes before changing anything; if cleanup is, rename the worst variable and pull out the repeated block. When the clock is nearly gone, describe the improvement aloud and leave the working code alone.

Why ask it

A design prompt is often one line, and this turns it into a short list of actions: post, read, search, pay. Write them where both of you can see them and number them. Later you can point at each box in the diagram and say which action it serves, and a box that serves none can go.

Why ask it

Nobody designs a whole product in one sitting. Propose a cut yourself, such as 'timeline and posting, but not search or ads', and ask if that matches what they hoped to cover. A reply that narrows it further is good news, since it leaves time to go deep on two features instead of sketching six.

Why ask it

A thousand users and a hundred million are different designs: one server and a database against partitioning, queues and caches. Ask for daily active users or requests per second, whichever the interviewer has. If you are told to estimate, say your number and the reasoning behind it, then build to that.

Why ask it

Read-heavy systems lean on caches and replicas. Write-heavy ones push you toward queues, batching and a careful choice of storage. A rough ratio is enough, and the product usually suggests it: many more people scroll a feed than post to it, while a logging pipeline is nearly all writes.

Why ask it

A page a person is waiting on and a report that runs overnight have little in common. Tight latency justifies precomputing and caching; a loose one lets you keep the design simple. Ask which operation the number applies to, because reads and writes rarely need the same speed.

Why ask it

A like count that lags by a few seconds harms nobody. A bank balance or the last seat on a flight is another matter. The answer tells you where you need strong consistency and where replicas and eventual updates will do, and it can differ from one part of the same system to the next.

Why ask it

Size per record times records per day times retention gives a storage figure you can say aloud. It tells you whether one database is enough and whether old data can move somewhere cheaper. If records are large, such as images or video, ask whether they live in the same store as the metadata.

Why ask it

Listen for which failure the interviewer cares about: lost messages, duplicate charges, a feed that will not load. That points to where you need retries, replication or operations that are safe to repeat. 'It must never lose a write' and 'showing a stale page is fine' lead to very different amounts of machinery.

Why ask it

A yes saves ten minutes of drawing boxes nobody wanted to discuss. Name each piece you are assuming so it is on the record. If the interviewer says to design one of them, that is the focus area announcing itself.

Why ask it

Some rounds expect a back-of-the-envelope estimate of traffic and storage and some find it a distraction. When numbers are wanted, round hard and keep the arithmetic visible, since the method matters more than the last digit. When they are not, one sentence on order of magnitude is still worth saying.

Why ask it

Ask once the overall diagram is drawn and there is time left. The answer is the interviewer telling you where the remaining minutes should go: the data model, the feed ranking, the queue. If it comes back as 'where would you go?', choose the part most likely to fail under load and explain that choice.