What should you do in the first 5 minutes of a coding interview?

Ask two or three clarifying questions whose answers would change your solution, restate the problem in one sentence, then name a brute-force approach and the improvement you intend to write. Get a nod on the approach before you type anything.

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

Two or three. The test is whether the answer would change your code. Input size, duplicates and the exact return value usually qualify. Asking eight questions reads as stalling, and asking none reads as someone who will build the wrong thing.

Is it bad to ask clarifying questions in a coding interview?

No, it is scored. Google's own prep material tells candidates to ask questions when a problem is unclear and notes that problems are often left underspecified on purpose, precisely so the interviewer can watch how you handle ambiguity.

Should you start with the brute-force solution?

Name it, price it, then improve it. Saying the nested-loop version is O(n squared) and that hashing gets you one pass takes fifteen seconds and shows you reasoned to the optimal answer rather than recognising the problem from practice.

What if you have no questions because the problem seems clear?

Then state your assumptions instead. Saying you are assuming a non-empty array of 32-bit integers with duplicates allowed gives the interviewer the same chance to correct you, and it scores on the same rubric line as a question.

How long should you spend before writing code?

Roughly three to six minutes of a forty-minute round. Candidates almost never lose offers for spending five minutes on understanding and approach. They lose them for solving a problem nobody asked, which is what the five minutes prevents.

First 5 Minutes of a Coding Interview: What to Do

Almost every candidate who fails a coding round fails it before minute six. Not because they lacked the algorithm, but because they started typing against a problem they had only half understood, and spent the remaining thirty-five minutes defending that choice.

This is a guide to the first 5 minutes of a coding interview: what to ask, what to say, and what to settle with the interviewer before your hands touch the keyboard. It is the cheapest score improvement available to you, because none of it requires knowing a single new data structure.

What the first 5 minutes of a coding interview are for

The interviewer has one real question: if we hand this person an ambiguous ticket on Monday, what happens? The opening of a coding round is where they find out, and most problems are written to make the answer visible.

That is not a theory. Google's published prep material for technical internship interviews tells candidates to ask clarifying questions when a problem is unclear, and notes that interview problems are frequently left underspecified on purpose, so the interviewer can see how a candidate engages with the ambiguity rather than whether they reach one blessed answer. The missing detail in the question is often the question.

So the first five minutes are not a warm-up or a politeness ritual. They are a scored section of the round, and the rubric lines they move — problem understanding, approach and trade-offs, communication — are worth more in combination than correctness is on its own.

The one thing to take away: nothing you type can recover from solving the wrong problem. Five minutes of questions, a one-sentence restatement and an agreed approach costs you an eighth of the round and protects the other seven-eighths.

The clarifying questions to ask in a coding interview

The useful filter is brutally simple: would the answer change my code? If yes, ask. If no, you are performing diligence rather than doing it, and experienced interviewers can tell the difference immediately.

Two or three questions is the right number. Below are the ones that pass the filter on most array, string and graph problems.

Input shape and constraints

This is where most of the real ambiguity lives, because the constraints decide which complexity class you need to hit.

Size

"Roughly how large is n?" An input of a thousand elements permits an O(n squared) solution and you can stop optimising. An input of ten million rules out anything quadratic and tells you the interviewer is looking for a hash or a sort. One question, and the entire solution space narrows.

Type and range

"Are these 32-bit signed integers, or can they be arbitrary?" This is the question that decides whether a running sum can overflow, and whether you need to say so later. For strings: ASCII or Unicode, and does case matter.

Sortedness and structure

"Is the input sorted, or can I assume anything about its order?" If it is sorted, binary search or two pointers is probably the intended answer and sorting it again is a wasted log factor. Nobody will volunteer this.

Duplicates and empties

"Can the same value appear twice, and can the collection be empty?" These two cover the majority of the edge cases you will be marked on, and asking them at minute two is worth far more than discovering them at minute thirty.

The output contract

The second cluster is about what you are supposed to return, which candidates assume far too readily.

Indices or values? On a two-sum style question these are different functions.
One answer or all of them? "Find a pair" and "find every pair" are different problems with different complexities.
What if nothing matches? Return null, minus one, an empty list, or throw. Pick one out loud.
May I mutate the input? This single answer decides whether an in-place sort is free or forbidden.
Does order of the output matter? If not, you may have just saved yourself a sort.

The questions that are not worth asking

Asking everything is its own failure mode. These burn goodwill without buying information:

"Which language should I use?" Use the one you are fluent in and say which it is.
"Can I use built-in functions?" Assume yes, use them, and say "I am using the library sort here, happy to write merge sort instead if you would rather see that."
Anything the problem statement already answers. It reads as not having listened, which is the opposite of the signal you want.
Eight questions in a row. Past three, the interviewer stops reading it as rigour and starts reading it as avoidance.

If the problem genuinely looks unambiguous, do not manufacture a question. State assumptions instead: "I am assuming a non-empty array of signed 32-bit integers, duplicates allowed, and that you want the indices." That lands on the same rubric line and gives the interviewer the same opening to correct you.

Restate the problem, then agree the approach

Questions answered, you have two moves left before coding. Both are short. Both are heavily scored.

One sentence, in your own words

Restate the problem as you now understand it, in a single sentence, including the constraints you just confirmed. "So: given an unsorted array of up to ten million signed integers, possibly with duplicates, return the indices of one pair summing to the target, or minus one if there is none."

Two things happen. The interviewer gets a last chance to say "almost — I want every pair", which is the cheapest correction of the whole round. And your own working memory now holds a specification rather than a vibe, which is what stops the minute-twenty realisation that you have been ignoring duplicates.

Name the brute force and price it

Then say the obvious solution out loud before the clever one. Google's prep material suggests exactly this sequence — begin with a straightforward or brute-force approach, then discuss the trade-offs in time and memory on the way to something better.

In practice it is one breath: "Brute force is two nested loops, O(n squared) time and O(1) space. If I store each value with its index as I scan, I get a single pass at O(n) time and O(n) space. Given ten million elements I will take the hash — memory is the cheaper resource here. Shall I write that?"

That sentence does four things at once: it proves you can see more than one solution, it prices both, it ties the choice to a constraint you confirmed, and it ends with an invitation. Jumping straight to the optimal answer scores lower than candidates expect, because the interviewer cannot tell whether you reasoned to it or simply recognised the problem.

When the interviewer pushes back

Sometimes the answer to "shall I write that?" is a hint, not a yes. Take it. A Google engineer's own advice on technical interviews is that the interviewer is rooting for you and that the goal is to show how you reason rather than to produce a flawless answer — which is also why hints are offered rather than withheld.

The move is to restate the objection before answering it. "You are asking whether the hash handles the same element being used twice — you are right, I need to check the complement before inserting, not after. Changing that." That is a scored recovery. Repeating your original explanation slightly faster is not.

A minute-by-minute script you can rehearse

Treat the opening as choreography, not improvisation. On a forty-minute round:

0:00–0:45 — Listen and note. Write the problem down as it is read. Do not interrupt, do not start solving. Note the words that feel load-bearing.
0:45–2:15 — Two or three questions. Size, then the weird cases, then the output contract. One at a time; let each answer land.
2:15–2:45 — Restate. One sentence, with the confirmed constraints in it.
2:45–4:00 — Brute force, priced, then the improvement, priced. Tie the choice to a constraint.
4:00–4:30 — Name your edge cases. "Before I write it: empty input, a single element, all-equal values, and a pair that is the same number twice." Naming them now is worth more than finding them later.
4:30–5:00 — Get the nod, then start. "I will write the hash version and dry-run it on a small input at the end."

Five minutes. You have not written a line, and you have put evidence on four rubric dimensions. Candidates who skip this reach the same code about three minutes sooner and score materially worse for it.

What the first five minutes do to your score

We publish our rubric because a score you cannot inspect is not feedback. Taqari's coding round is judged on four criteria on a nought-to-three scale, and three of the four are substantially decided in the opening: correctness of approach, complexity reasoning and communication under questioning. Only the fourth — what you do with a hint — is spread across the round. The dimension-by-dimension breakdown is in our write-up of the real coding interview rubric.

A session that opened badly produces feedback that looks roughly like this:

Correctness of approach          1 / 3
  First code written at 00:38, before any constraint was
  confirmed. Solution assumed distinct values; duplicates
  surfaced at 21:40 and forced a rewrite.
  To reach 3: confirm duplicates and input size, then choose.

Complexity reasoning             1 / 3
  No cost stated for the chosen approach until asked at 18:02.
  To reach 3: price the brute force and the improvement in the
  opening, and say which constraint decided it.

Read that against the same candidate a week later, having changed only the opening, and the two rows move to 3 and 2 without a single new algorithm learned. That is the whole argument for rehearsing the first five minutes as its own skill, and it is why our sessions ask follow-ups instead of just running your tests.

Why silence in the opening costs double

An interviewer cannot score reasoning they cannot hear, so a wrong idea said out loud beats a right idea kept private. In the opening this is amplified: silence there also removes the interviewer's only chance to correct your reading of the problem. The structure for narrating without over-talking is in our guide to thinking out loud without rambling.

Service company to product company: where the opening differs

If you are interviewing out of a service company in India, the first five minutes are where the two cultures diverge most sharply, and it catches strong engineers out.

In a delivery context, the requirement usually arrives specified. Asking "can the input be empty?" about a ticket that says so is noise, so the habit never forms. Product-company rounds invert that: the problem is deliberately thin, and the interviewer is testing whether you notice. Candidates with four years of solid delivery experience routinely open by typing, because that is what competence has looked like for four years.

Three adjustments worth rehearsing before a product-company loop:

Assume the problem is incomplete. Not a trick — a design. Your first instinct should be to probe it, not to implement it.
Price your choices, always. "It works" is a delivery standard. "It is O(n log n) because of the sort, and here is when I would change that" is the product-interview standard.
Expect to be pushed on a working answer. "Why not the other way?" is not a signal that you are wrong. It is the trade-off dimension being scored.

None of this needs a new problem set. It needs the explanation layer rehearsed on problems you have already solved.

How to rehearse an opening when you have nobody to practise with

The opening is the easiest part of an interview to drill alone, because it does not need a counterparty to be useful.

Five problems, openings only. Read the statement, record yourself doing the full five-minute sequence, then stop. Do not solve it. You get five reps in the time one full problem takes.
Watch the recording with a checklist. Did you ask about size? Duplicates? The return value? Did you restate in one sentence? Did you price two approaches? Tick or cross — no self-grading in adjectives.
Do it on problems you have already solved. Knowing the answer is a feature here. It isolates the communication skill from the algorithmic one.
Then take it into a timed round where something actually pushes back on your assumptions. The full solo system is in our guide to practising coding interviews with nobody to practise with.

A week of this changes the opening permanently, because five minutes is short enough to become muscle memory. Thirty-five minutes of problem solving never does.

The bottom line

The first 5 minutes of a coding interview are the highest-leverage five minutes in your preparation, and almost nobody practises them. Two or three questions that would change your code, one sentence restating the problem, two approaches priced out loud, your edge cases named, and a nod before you type.

That is the whole script. It requires no new knowledge, it is identical across every array, string and graph problem you will ever be asked, and it protects you from the one failure that no amount of coding skill recovers from. Rehearse it until it is boring, then run a free mock round and read the opening two rubric rows before you look at anything else.