Coding Interview Fundamentals

Most candidates lose the coding interview in the first ninety seconds — before they've written anything. They hear the prompt, panic a little, and start typing. Big mistake. The strongest engineers I've watched do the opposite: they slow down at the start, and it makes the rest look effortless.

What actually gets scored? Not just "did the code run." Interviewers grade how you clarify an ambiguous problem, whether you talk through trade-offs, how you test, and whether you can reason about time and space. A correct-but-silent solution often scores lower than a slightly-imperfect-but-well-communicated one.

So let's talk process. Memorising patterns matters, sure. But a repeatable method for attacking any unfamiliar problem is what stops you from freezing. Here's the one I recommend — some folks call it UMPIRE.

The UMPIRE method

1. Understand. Restate the problem in your own words. Ask about input size, edge cases, duplicates, empty input, negative numbers. Every clarifying question buys you thinking time and signals rigor.
2. Match. Which pattern does this smell like? Sliding window? Two pointers? A graph in disguise? Say it out loud: "This looks like a frequency-counting problem."
3. Plan. Sketch the approach in plain English before touching syntax. Walk the interviewer through it. Let them course-correct you now, cheaply.
4. Implement. Code it. Narrate as you go, but don't over-explain every semicolon.
5. Review. Trace one small example by hand. Off-by-one? Null case? Do it before they ask.
6. Evaluate. State the time and space complexity, then name one thing you'd improve with more time.

A tiny worked example

Prompt: "Return true if a string has all unique characters." Watch the method, not the code:

// Understand: ASCII or Unicode? Case-sensitive? Empty string?
// Match: "have I seen this char?" → hash set
// Plan: iterate once, track seen, bail early on a repeat
function allUnique(s) {
  const seen = new Set();
  for (const ch of s) {
    if (seen.has(ch)) return false;  // early exit
    seen.add(ch);
  }
  return true;
}
// Evaluate: O(n) time, O(k) space where k = distinct chars.
// Follow-up I'd raise: "no extra space" → sort first, or a bitmask for a-z.

Notice how the comments are the interview narration. That running commentary is what earns the "strong communicator" checkbox on the rubric.

The mistakes that quietly sink people

• Coding in silence. If the interviewer can't follow your reasoning, a working answer still reads as luck.
• Skipping edge cases. Empty input and single-element input are free points. Leaving them out is a free deduction.
• Optimising too early. Get a brute-force working, say "this is O(n²), here's how I'd cut it," then improve. A finished slow solution beats an unfinished clever one.
• Not testing. Trace your own example. Catching your bug looks far better than the interviewer catching it.

How to build the instinct

Process without practice is just theory. Solve problems out loud, on a timer, the way you'll actually perform. Start with the eight core structures, layer on array patterns, and once you're comfortable, follow the multi-week study roadmap. Then rehearse under pressure with mock interviews so the method becomes muscle memory.

FAQ

Should I really talk the whole time? Talk during Understand, Plan, and Evaluate. It's fine to go briefly quiet while implementing — just resurface every minute or so.

What if I don't know the optimal solution? Say so, then build the brute force anyway. "I'll start with the obvious approach and improve it" is exactly what senior engineers do daily.