A running order for the whole interview

Coding interviews assess how you think far more than whether you finish. A predictable process protects you when nerves take over.

1. Clarify — two minutes, always

Never start coding on the problem as stated. Ask:

• What is the input size? This names the target complexity.
• Can the input be empty, null, or contain duplicates or negatives?
• Is it sorted? Can I sort it, or mutate it?
• What should happen when there is no valid answer?
• Are ties possible, and does the tie-break matter?

Interviewers deliberately leave gaps. Finding them is part of the score.

2. Work an example by hand

Write a small input and produce the output manually. It confirms you understood the question, and it becomes your test case at the end. If your example disagrees with the interviewer's expectation, you have just saved twenty minutes.

3. State the brute force, with its complexity

"I could check every pair — O(n²) time, O(1) space. Let me improve it."

This banks a working answer and shows you know its cost. Never open with silence while hunting for the clever solution.

4. Improve, out loud

Name the bottleneck and the tool: "the repeated lookup is what costs us — a hash set makes it O(1), so the whole thing becomes one pass." Get agreement before you code; interviewers will steer you if you are heading somewhere unproductive.

5. Code, narrating structure

Write the signature and the main loop first, then fill in. Say what each block does as you write it. Use real variable names — left, right, seen, remaining — not a, b, tmp.

6. Test deliberately

Walk your hand-worked example through the code, line by line, out loud. Then the edges: empty, one element, all identical, largest value first, no valid answer.

Budgeting 45 minutes

If you are ten minutes in with no approach, say so and ask for a hint. Using a hint well costs far less than running out of time with an empty editor.