The interview
Forty-five minutes, one or two problems, and a scorecard you never see. This page is about how to run that time, which is a separate skill from knowing algorithms — and it is the one most people neglect.
Here is the uncomfortable part. Two candidates can produce identical working code and receive different verdicts, because what is written down afterwards is not just whether the code ran. It is whether the interviewer could follow your reasoning, whether you checked your own work, and whether they would want you on their team when something breaks at 2am.
All of that is trainable, and none of it is trained by doing more problems silently.
How to spend the 45 minutes
Timings are a shape, not a schedule. What matters is that all five phases happen, because skipping any one of them costs points that were free.
1. Understand the question
Read it, then restate it in your own words and get agreement. This costs twenty seconds and prevents the single most expensive failure mode there is: forty minutes spent solving a problem you were not asked.
Then ask about the input. Not vaguely — specifically, because each answer changes your solution.
- How large can the input get? This tells you the target complexity.
- Can it be empty? Can it have one element?
- Are there duplicates? Negative numbers? Is it sorted?
- What should I return when there is no valid answer?
- Can I modify the input, or must I leave it untouched?
Two or three of those, chosen for the problem, is right. All five every time sounds like a script.
2. Think out loud, and get buy-in
This is the highest-value stretch of the whole interview and the one candidates
most often skip. Say the brute force first, with its complexity: “I could compare every
pair, which is O(n²). Given n can be 10⁵, that is too slow, so let me look for
something better.” You have now established a floor and shown you can evaluate your
own work.
Then name the pattern and the signal that suggested it: “It says contiguous subarray, which usually means a sliding window.” Sketch the approach on the board or in comments, state its complexity, and ask before you code: “Does that approach seem reasonable to you?”
That question is worth asking every time. If your approach is wrong, you find out now rather than at minute thirty. If it is right, the interviewer has effectively agreed to it, and the rest of the interview becomes collaborative rather than adversarial.
3. Write it
Now go quiet-ish. Narrate the structure, not every token — “I'll set up the two pointers, then handle the shrink condition” — and stop narrating during the fiddly three lines where you need to concentrate. Interviewers understand silence while you think. They do not understand silence for ten minutes.
Write real code, not pseudocode, unless asked otherwise. Use meaningful names;
left and right rather than i and j costs nothing and reads as care. If you
need a helper, write the main logic first and stub the helper — that keeps the shape of
your solution visible.
If you get stuck, say so and say where: “I know I need to shrink the window here, I'm working out whether the condition should be strict.” A specific admission invites a hint. Silence invites a lower score.
4. Test it yourself
Do not ask whether it is correct. Show that it is. Trace your code by hand against a small input, out loud, saying what each variable holds. Then deliberately check the cases that break most solutions:
- The empty input.
- A single element.
- Two elements — where most off-by-one errors surface.
- All identical values.
- The target absent entirely.
- Negative numbers, if they are allowed.
Finding your own bug here is a positive signal, not a negative one. It demonstrates exactly the habit that makes someone safe to ship code. Fix it calmly and say what the fix does.
5. Complexity, trade-offs, and questions
State time and space with the reason attached, not just the letters: “O(n log n)
time, dominated by the sort; the sweep after it is linear. O(n) space for the map, or
O(1) if I sort in place, but that loses the original indices which this problem
needs.”
Then offer one improvement you did not make and why: “With more time I'd replace the
linear scan with a heap, which would take this to O(n log k).” That single sentence
shows you know your solution sits on a spectrum and that you chose a point on it
deliberately.
Leave two minutes to ask them something real. What they are working on, what the hardest technical problem on their team has been, how they make decisions. Not the compensation, and not something you could have read on the careers page.
What is actually being scored
Most companies use a rubric with roughly these categories. Notice that only two of the five are about algorithms.
Problem solving
Did you find a reasonable approach, and did you get there through reasoning rather
than recall? Interviewers can tell the difference, and a solid O(n log n) answer you
clearly derived scores above an optimal one you evidently memorised.
How to score well: Say the brute force first. Name the pattern and the signal. Explain why the approach works, not just what it does.
Weight: heaviest
Coding
Does it run? Is it readable? Are the boundaries right? Most candidates who fail here had the correct approach and an off-by-one error they never checked for.
How to score well: Meaningful names. Small functions. Handle the empty and single-element cases explicitly. Trace it by hand before declaring it done.
Weight: heavy
Communication
Could the interviewer follow your thinking? This is not politeness — your reasoning is the primary thing being graded, and it is invisible unless you say it.
How to score well: Narrate structure, not syntax. Ask before coding. When stuck, say precisely where. Accept hints gracefully and say what you now understand.
Weight: heavy, and most often underestimated
Complexity analysis
Can you state the cost of your own code without hedging, and say whether it is good enough for the given constraints?
How to score well: Volunteer time and space before being asked, with the reason attached. Mention the recursion stack. Say when something is amortised rather than average.
Weight: moderate, and easy to lose
Testing
Did you verify your own work, or hand it over and hope? Skipping this is one of the cheapest ways to lose points.
How to score well: Trace a small input out loud. Then deliberately try the empty, single, duplicate and absent cases. Say what each one is testing.
Weight: moderate, and frequently skipped
A worked example of thinking out loud
This is what the first six minutes should sound like. It is longer than you would expect, and that is the point — the reasoning is the deliverable, not just the code.
/*
PROBLEM: given an array of integers, return the indices of two numbers
that add up to a target.
WHAT I SAID, in order:
"So I'm given an array of integers and a target, and I need to return the
positions of two numbers that sum to it. Let me check a few things first:
can the array be empty, and is it guaranteed there's exactly one answer?
Can the same element be used twice? And can the values be negative?"
-> exactly one answer, cannot reuse an index, negatives allowed.
"The brute force is to check every pair with two nested loops. That's
O(n^2) time and O(1) space. It's correct, so it's my floor. Given the
constraints say n can be 10^4, that's 10^8 operations, which is too slow.
Let me look for something better."
"The repeated work is that for each element I'm searching the whole array
for its complement. If I could look up 'is target minus current present'
in constant time, the whole thing becomes one pass. That's a hash map."
"So: walk the array once, and for each element check whether its
complement is already in the map. If it is, I have my answer. If not,
store the current value with its index and continue. One subtlety --
I need to check before I insert, otherwise an element whose double is
the target would pair with itself."
"That's O(n) time and O(n) space. I've traded memory for speed, which is
the right call here because the constraints care about time. Does that
approach seem reasonable before I write it?"
*/
function twoSum(nums, target) {
const indexOf = new Map(); // value -> index
for (let i = 0; i < nums.length; i++) {
const need = target - nums[i];
if (indexOf.has(need)) return [indexOf.get(need), i];
indexOf.set(nums[i], i); // AFTER the check
}
return [];
}
/*
THEN I TESTED IT, out loud:
[2, 7, 11, 15], target 9
i=0: need 7, map empty, store {2:0}
i=1: need 2, map has 2 at index 0 -> return [0, 1] correct
[3, 3], target 6 -- the duplicate case
i=0: need 3, map empty, store {3:0}
i=1: need 3, found at 0 -> [0, 1] correct, and this is exactly why
the check comes before the insert
[3, 2, 4], target 6 -- must not pair 3 with itself
i=0: need 3, empty, store
i=1: need 4, absent, store
i=2: need 2, found at 1 -> [1, 2] correct
[] -- returns [], as agreed
*/
console.log(twoSum([2, 7, 11, 15], 9)); // [0, 1]
console.log(twoSum([3, 3], 6)); // [0, 1]
console.log(twoSum([3, 2, 4], 6)); // [1, 2]
console.log(twoSum([], 1)); // []Output
The mistakes that cost the most
In rough order of how often they decide an outcome.
Coding in silence
The most damaging and the easiest to fix. Your reasoning is what is being scored, and an interviewer cannot score what they cannot hear. Narrate structure; go quiet only for the genuinely fiddly parts.
Starting to code immediately
It looks decisive and reads as impulsive. Two minutes of clarifying and four of explaining buys you a much better twenty minutes, and often catches a misunderstanding that would have cost the whole interview.
Solving the wrong problem
Restate the question in your own words and get agreement before you do anything else. Twenty seconds against forty minutes.
Ignoring the constraints
If n can be 10⁵, an O(n²) design is wrong — not slow. The constraints tell
you the intended complexity, so read them as a hint rather than as trivia.
Refusing hints
A hint is not a penalty; it is the interviewer trying to get you to a scoreable place. Take it, say what it changed for you, and move. Fighting a hint wastes the clock and reads as inflexible.
Declaring victory without testing
“I think that works” invites them to find your bug. Find it yourself — then finding it becomes evidence of rigour rather than of carelessness.
Optimising something that is already fine
If your solution meets the constraints, stop and say so. Chasing an unnecessary constant factor while the clock runs is a self-inflicted wound.
Freezing when you do not know
Say what you do see. “I don't immediately recognise the pattern. I can see a brute
force at O(n²) — let me write that and then look for structure I can exploit.” A
partial solution with visible reasoning scores. Silence does not.
What to say when you are completely stuck
It happens to strong candidates, and how you handle it is itself a signal. In order:
- Say where you are. “I can see this needs me to track the best value so far, but I'm not sure how to handle the case where the array is all negative.” Specific beats vague, and it invites a targeted hint.
- Work a small example by hand. Out loud, on the board. Three or four elements. This unsticks people more often than any amount of thinking, and it shows the interviewer your process.
- Say what pattern it resembles and why that is not quite working. Even a wrong guess gives the interviewer something to correct, which is far more useful to them than silence.
- Write the brute force. Working and slow beats elegant and absent. It also frequently reveals the structure that leads to the real answer.
- Ask directly. “Could you give me a nudge on the data structure here?” This is allowed, it is normal, and it costs less than ten minutes of visible flailing.
Before and after
Two small things that are worth more than they sound.
Before: have your first four sentences ready, so nerves do not eat the opening. Test your setup. Have water and paper. If it is a shared editor, know whether it runs code — it usually does not, which means your hand-tracing is the only testing available and you should say so.
After: write down the problem and what you fumbled, within the hour, while it is fresh. That note is the highest-quality study material you will ever get, because it is a record of your actual gaps under actual pressure. Then stop replaying it; you cannot recover information from rumination that you did not already capture in the note.