Interview strategy

What is actually being scored

At the advanced level the interviewer is not checking whether you can produce a correct program. They are estimating one thing: what is it like to hand this person an ambiguous problem and come back in three days? Every behaviour in this chapter is a proxy for that. Clarifying questions predict whether you will build the wrong thing. Stating a brute force before optimizing predicts whether you ship something or stall. Testing your own code predicts whether QA finds your bugs or you do. Naming a tradeoff unprompted predicts whether you will make a defensible technical decision alone.

Two candidates can both produce a working O(n log n) solution and receive "strong hire" and "no hire." The difference is almost never the code. It is that one of them narrated a decision process the interviewer could follow and trust, and the other silently emitted a memorized answer that could not be probed, extended, or debugged out loud.

The 45 minutes as checkpoints, not hopes

The timeline above says where each phase should sit. A timeline you only glance at does nothing for you; what helps is knowing, at each checkpoint, what must already be true and what you do if it is not. These are guides to calibrate against, not rules: a Hard problem pushes the approach phase longer and a simple one shortens it.

The checkpoint that does the most work is minute 12, because everything after it is expensive to undo. The one at minute 25 catches the commonest failure in the middle of the interview: a candidate who has been coding carefully for thirteen minutes and has a lovely helper function and no program. Look at the clock when you finish the approach phase, not only at the end.

The first five minutes: questions that change the answer

Silence here is the single strongest negative signal available, and it is the cheapest to fix. An engineer who starts coding from an under-specified problem statement is telling the interviewer exactly how they behave with an under-specified ticket. But not all questions are equal — "can I use a hashmap?" wastes the goodwill you are trying to build. Ask only questions whose answer would change your solution, and say why you are asking.

That last clause is the part that scores. You are not collecting facts, you are demonstrating that each fact eliminates a branch of your decision tree. Two or three questions asked this way beat ten asked mechanically.

A framework that works on a problem you have never seen

You will not recognize the problem. That is the point of an advanced interview. What you need is not recall but a procedure that visibly makes progress even from zero. Run these seven steps out loud, in order.

Step 3 is non-negotiable and candidates skip it constantly, believing a brute force looks weak. The opposite is true: it guarantees you have a solution on the board within five minutes, it proves you understand the problem, and it gives you a concrete complexity to improve on. An interviewer will almost always let you skip implementing it. What they will not forgive is twenty minutes of silence hunting for the clever answer.

Dry run: the seven steps applied to one concrete problem

"Given a list of daily prices, find the maximum profit from buying once and selling once later. n ≤ 10⁵."

The problem changes every time; the seven-step shape doesn't. That's the actual claim this framework makes — not that you'll recognize this specific problem, but that running the same seven questions on an unfamiliar one gets you from "no idea" to "one pass, O(n)" without needing to have seen it before.

Constraints → intended complexity: the highest-leverage table here

Interviewers and problem setters choose n deliberately. The bound is a hint about the intended solution, and reading it correctly can collapse a twenty-minute search into thirty seconds. Calibrate against the rough industry rule that ~10⁸ simple operations is about one second.

Read the second half of the constraints too. "Sum of all string lengths ≤ 10⁵" over many strings means linear in the total, which fits a Trie or Aho-Corasick built over all the strings at once. A value range like "values ≤ 100" alongside a huge n points at counting/bucketing. A memory limit matters as much as time: n = 5,000 with an O(n²) DP table is 25 million cells, easily 100-200 MB in JavaScript, which tells you the DP is meant to be rolled down to one or two rows. (At n = 10⁵ the table would be 10¹⁰ cells and the time 10¹⁰ steps, so no rolling saves it — the quadratic idea itself is out.)

Keywords to a first guess, and the check before you commit

The phrasing of a problem leaks its pattern. The table below is a list of first guesses, not answers: each phrase makes a pattern worth considering first, and the right-hand column is the one question that tells you whether the guess survives. Saying the check out loud is what separates a pattern match from a hunch.

If two rows fit, that is information, not confusion: say both guesses and use the check to choose. "This looks like a window or a prefix-sum problem; the values can be negative, so it is prefix sums" is a complete and strong sentence.

How to talk while you code

The goal is a continuous, low-effort narration that lets the interviewer follow your reasoning without interrupting. Not a play-by-play of syntax — nobody needs "now I'll write a for loop." Narrate decisions, and name your patterns, because naming is what proves the choice was deliberate rather than lucky.

Two mechanical habits pay for themselves. First, write the function signature and the return type before the body — it forces the contract to be explicit. Second, when you defer something, say so and leave a visible marker; an acknowledged gap is a plan, an unacknowledged one is a bug.

Being stuck, handled well

You will get stuck. It is expected and it is not disqualifying — freezing is. What is being measured is whether you have a procedure for it. Work this ladder out loud, in order, and say which rung you are on.

Note what that phrasing does: it converts "stuck" into "executing a deliberate step." Interviewers are instructed to give hints; taking one gracefully costs far less than most candidates fear, and refusing to ask while burning ten minutes costs far more.

Pivoting off a wrong approach without losing the interview

Sooner or later the approach you announced stops working. Candidates treat this as a catastrophe and either defend a failing idea or fall silent. It is neither: finding that an approach is wrong, early and out loud, is a strong signal, because it shows you test your own ideas. What costs points is finding out late, or finding out and hiding it.

There are three ways an approach fails, and each has a different tell.

The incorrect case deserves a worked example, because greedy is where candidates most often commit to something unproven. "Make change with the fewest coins: take the largest coin that fits, repeatedly." For some coin systems this is right. For others it is quietly wrong, and one small input shows it.

function greedyCoins(coins, amount) {
  const sorted = [...coins].sort((a, b) => b - a);
  let count = 0;
  for (const coin of sorted) {
    count += Math.floor(amount / coin);
    amount %= coin;
  }
  return amount === 0 ? count : -1;
}

function minCoins(coins, amount) {
  const best = new Array(amount + 1).fill(Infinity);
  best[0] = 0;
  for (let a = 1; a <= amount; a++) {
    for (const coin of coins) {
      if (coin <= a && best[a - coin] + 1 < best[a]) best[a] = best[a - coin] + 1;
    }
  }
  return best[amount] === Infinity ? -1 : best[amount];
}

With coins [1, 3, 4] and amount 6, greedyCoins returns 3 (it takes 4, then 1, then 1) while minCoins returns 2 (3 and 3). Amount 6 is the smallest amount where they disagree for those coins. With coins [1, 5, 10, 25] they agreed on every amount from 1 to 500, which is why the greedy habit survives: it works on the coins you grew up with.

Notice the structure of that speech: the claim, the smallest counterexample, the reason it fails, and what the reason tells you to build next. Three habits make a pivot cheap. Decide on a deadline: if you cannot make an idea work by a time you set in advance (say, five minutes), it is a wrong approach until proven otherwise. Keep what survives: the parsing, the helper functions and the examples usually carry over, and saying "the input handling stays, the core changes" shows control. Say what you learned: the counterexample or the missed constraint is the first line of the next approach, not an embarrassment to skip.

Proving it correct in one sentence

"Does it work?" is asked more often than "is it fast?", and "I tested it" is not an answer to it. A one-sentence correctness argument is short enough to say aloud and strong enough to convince. It names a fact that stays true throughout the algorithm (an invariant) or a reason a discarded option cannot matter. The table gives the shape for each family; fill the blanks with the specifics of your problem.

The first row, worked once on the sorted two-sum from the follow-ups below. The loop moves lo up when nums[lo] + nums[hi] < target. Why is that safe? nums[hi] is the largest value still allowed, so nums[lo] with any partner in range is at most nums[lo] + nums[hi], which is already too small: index lo is in no valid pair, and discarding it cannot lose an answer. The other branch is the mirror image. That is the entire proof, and it also tells you the loop ends: each step discards one index.

Test before you say "done"

Declaring completion and letting the interviewer find the bug is the most avoidable score loss in the entire interview. Finding it yourself, out loud, converts the same bug into a positive signal. Trace the given example first — line by line, tracking real variable values, not vibes — then run a deliberately chosen edge case.

Follow-ups: it is a stream, it is sorted, it does not fit on one machine

The first solution is rarely the end. Interviewers keep the same problem and change one assumption, and each change has a standard move. Hearing the change as "which resource just got taken away?" is what turns the follow-up from a surprise into a lookup.

Streaming: one pass, constant memory

A typical case: find the element that occurs more than half the time in a stream, without storing the stream. Keep a candidate and a counter. A matching element adds a vote; a different one cancels a vote; when the votes hit zero the next element becomes the candidate. If a strict majority exists, it cannot be cancelled out, because every cancellation removes one copy of it together with one copy of something else.

class MajorityStream {
  constructor() {
    this.candidate = undefined;
    this.count = 0;
  }

  add(x) {
    if (this.count === 0) {
      this.candidate = x; // nothing is standing: x takes the floor
      this.count = 1;
    } else if (x === this.candidate) {
      this.count++;
    } else {
      this.count--; // x cancels one vote for the candidate
    }
  }
}

The guarantee is conditional, and saying so is the point. If a strict majority exists, candidate is that value: I tested 3,000 random streams that each contained one. If no majority exists, the candidate is just whatever survived: after adding 1, 2, 3 it is 3 with a count of 1, and a second pass is the only way to confirm. A stream gives you no second pass, so the honest statement is "this tells you the majority if there is one".

Sorted input: the hash map was only buying you order

For two-sum, the hash-map solution is O(n) time and O(n) space. Given sorted input, the same question needs no extra memory.

function twoSumSorted(nums, target) {
  let lo = 0;
  let hi = nums.length - 1;
  while (lo < hi) {
    const sum = nums[lo] + nums[hi];
    if (sum === target) return [lo, hi];
    if (sum < target) lo++; // nums[lo] is too small even with the largest partner left
    else hi--; // nums[hi] is too large even with the smallest partner left
  }
  return [];
}

Time O(n), space O(1). It returns the pair's positions, or an empty array when there is none; I checked it against all pairs on 3,000 random sorted arrays, including empty ones. The follow-up lesson is general: a sorted input is a free resource, and a solution that ignores it is probably using more memory than it needs.

Distributed: can the answer be combined from the pieces?

For "the k largest of data spread over many machines", ask whether the global answer can be assembled from each machine's local answer. It can: every element of the global top k is also in the top k of the machine that holds it, so each machine sends only its own best k and one coordinator takes the best k of those.

function mergeTopK(shards, k) {
  const candidates = shards.flatMap((shard) => [...shard].sort((a, b) => b - a).slice(0, k)); // each machine sends only its own best k
  return candidates.sort((a, b) => b - a).slice(0, k);
}

The coordinator handles at most k times the number of machines items, however large the data is. I compared it with sorting everything on 2,000 random splits. Not every question combines this way: the median of the whole is not derived from the medians of the parts, so a distributed median needs a different design (counting values in ranges, then narrowing). Saying which kind of question you have is the senior answer.

Discussing tradeoffs at a senior level

The clearest seniority marker in the last ten minutes is raising a tradeoff before you are asked, and framing it against a use case rather than in the abstract. Intermediate candidates report complexity. Advanced candidates report complexity, name the alternative they rejected, and say what would change their mind.

Every one of those ends in a question or a condition. That is deliberate — it turns a monologue into a design conversation and invites the interviewer to supply real-world context, which is the exact interaction they are trying to score. It is also honest: which side of a tradeoff is correct genuinely depends on information you do not have.

Two more things to have ready without being asked. How would this scale past one machine? — even a sentence ("if the array doesn't fit in memory, I'd external-sort by chunk, or shard by hash of the key and merge") shows the thinking extends past the whiteboard. And what would you test? — naming three unit tests and one property ("the output should always be a permutation of the input") signals engineering maturity that pure DSA never reaches.

When the problem is NP-hard: recognise it, then say the right thing

Some problems have no known algorithm that stays fast as n grows, and an interviewer will occasionally give you one on purpose. Failing to notice is the costly mistake: you spend thirty minutes hunting a polynomial solution that, as far as anyone knows, does not exist. Noticing is cheap, because the disguises are few.

The clue that gives it away is almost always in the constraints: a bound like n <= 20, or n <= 40 with a sum question, is the setter telling you an exponential method is intended. The numbers decide how exponential. Counting steps against a budget of 10⁸ operations, the largest n that fits is:

Computed with a loop over n, so the cutoffs are exact for that budget. The table also explains the odd bounds: meet in the middle turns 2⁴⁰ into about 2 × 2²⁰ sums, which is why subset-sum questions go up to n = 40 while bitmask DP questions stop near 20.

Many problems look like the hard ones and are not, and mixing them up is the opposite error. The nearby pairs worth knowing: the shortest path is easy and the longest simple path in a general graph is hard (in a directed acyclic graph the longest path is easy again, by dynamic programming over a topological order); a tour using every edge once (Eulerian) is easy and a tour visiting every vertex once (Hamiltonian) is hard; deciding whether a graph can be coloured with two colours is easy and with three is hard.

A full mock: one Hard problem, start to finish

Everything above is easier to believe once you have watched it run on a real problem. Below is an interview on Sliding Window Maximum, written as a transcript. The notes in italics say which behaviour is being scored. Every piece of code shown was run: the brute force and the final function were compared on 3,000 random arrays, the trace table is the real output, and the wrong draft really returns what is claimed.

Interviewer: Given an integer array nums and a window size k, the window slides one position at a time from the left end to the right end. Return the maximum of each window.

You: Let me restate it: for every run of k consecutive elements, output the largest, so there are n - k + 1 answers. A few questions that change my approach. How large can n be? Can values be negative? Is k always between 1 and n?

Interviewer: n up to 10⁵, values can be negative, 1 <= k <= n.

Scored: three questions, each tied to a decision (target complexity, sign of values, an empty-window case that cannot occur).

You: Let me do the example by hand. For [1, 3, -1, -3, 5, 3, 6, 7] with k = 3, the windows are [1,3,-1], [3,-1,-3], [-1,-3,5], [-3,5,3], [5,3,6], [3,6,7], so the answer is [3, 3, 5, 5, 6, 7]. Brute force: for each window, scan its k elements.

function maxSlidingWindowBrute(nums, k) {
  const result = [];
  for (let i = 0; i + k <= nums.length; i++) {
    let max = nums[i];
    for (let j = i + 1; j < i + k; j++) if (nums[j] > max) max = nums[j];
    result.push(max);
  }
  return result;
}

You: That is O(n · k). With n = 10⁵ and k = 50,000 that is about 50,000 windows times 50,000 comparisons, roughly 2.5 billion, far past the 10⁸ a second I can count on. The bottleneck is that consecutive windows share k - 1 elements and I rescan them every time.

Scored: brute force with its complexity, the number checked against the constraint, the bottleneck named in one sentence.

You: First idea: remember the current maximum and only rescan when the element leaving the window is that maximum. Most windows are then O(1). Hold on, a decreasing array breaks it. In [8, 7, 6, 5, ...] the maximum is always the element that just left, so I rescan on every window. I counted it: on 20 decreasing numbers with k = 5 it rescans 15 times, on every window after the first, 75 comparisons; on 10,000 numbers with k = 5,000 it does 25 million comparisons. That is the brute force again in its worst case, so I'm dropping it.

Scored: a pivot. The idea was tested on an adversarial input before any code was written, and the counterexample was kept.

You: What the failed idea shows is that after the maximum leaves, I need the next candidate ready. A max-heap of (value, index) pairs does it: pop the top while its index is outside the window. That is O(n log n) with lazy deletion and would pass. But look at what the heap keeps that it never needs: if nums[j] <= nums[i] and j < i, then j can never be a window maximum again, because i is both larger and will stay in the window longer. So I can throw such a j away immediately. What remains is a list of indices whose values strictly decrease, oldest first. The front is the maximum; the front expires when it leaves the window; a new element removes smaller ones from the back. That is a monotonic deque, and each index is pushed once and removed at most once, so O(n).

Scored: the optimization is a derivation from the bottleneck, an alternative (heap) is named with its cost, and the key fact ("can never be a maximum again") is stated as the reason.

Interviewer: Go ahead and code the deque version.

You: Signature first: takes nums and k, returns an array. I'll use an array plus a head index rather than shift(), which is O(n).

function maxSlidingWindow(nums, k) {
  const result = [];
  const deque = []; // indices; their values strictly decrease from front to back
  let head = 0; // deque[head] is the front; moving head forward is a pop-front without shift()
  for (let i = 0; i < nums.length; i++) {
    if (head < deque.length && deque[head] <= i - k) head++; // the front slid out of the window
    while (deque.length > head && nums[deque[deque.length - 1]] <= nums[i]) deque.pop(); // smaller or equal values can never be a max again
    deque.push(i);
    if (i >= k - 1) result.push(nums[deque[head]]);
  }
  return result;
}

Scored: narrating decisions (head index versus shift(), why <= pops equal values) instead of syntax.

You: Now I trace the example, with real values. The table shows the deque after each step as index:value.

You: That gives [3, 3, 5, 5, 6, 7], matching my hand answer. Now edge cases. k = 1 should return the array itself. Take [1, 0]. I expect [1, 0] and ... my first draft of the expiry line was deque[head] < i - k, and it returns [1, 1]. That is an off-by-one: the window holds indices i - k + 1 to i, so an index equal to i - k is already out and the test must be <=. The final code above has the fix. It is worth knowing that the buggy draft produces the right answer on the given example, so the example alone would not have caught it.

Scored: tracing with values, then choosing an edge case that probes the boundary, and finding the bug before the interviewer does.

You: Complexity: each index is pushed once and popped at most once, so O(n) time. The live part of the deque never holds more than k indices; this array-and-head version does not free the consumed front, so its memory is O(n), and a circular buffer would make it O(k). Correctness in one sentence: the deque always holds, in order, exactly the indices in the window that are not dominated by a later index, so its front is the window's maximum. I also compared it with the brute force on 3,000 random arrays with negatives and repeated values, plus k = 1 and k = n.

Interviewer: What if the numbers arrive as a stream and you must report a maximum after each arrival?

You: The same code works almost unchanged: the loop body already handles one element at a time and only needs the indices it has seen, so I would keep the deque and a running index as fields and emit the front after each push once k elements have arrived. With a circular buffer, memory stays O(k). If the window were defined by time rather than by count, the expiry test would compare timestamps instead of indices; the structure is the same.

Scored: a follow-up absorbed by naming what changed (nothing about the algorithm, only what the front is compared against).

Signals that separate an advanced performance from an intermediate one

• Constraints are read as a hint, not as trivia. "n ≤ 20, so they intend an exponential-in-n solution — that means bitmask" is said in the first two minutes, not discovered at minute thirty.
• A brute force is stated with its complexity before any optimizing starts. There is always something on the board, and the improvement is measured against a named baseline rather than asserted.
• Patterns are named out loud as they are chosen. "Monotonic stack, because I need the next greater element and each index is pushed and popped once" — not just correct code that happens to be a monotonic stack.
• The bottleneck is identified explicitly ("the expensive part is re-scanning the prefix") and the optimization is presented as buying that specific work back with a specific structure.
• Getting stuck produces a described procedure, not silence. Re-read constraints → hand-trace a tiny case → identify the shape → check for two composed patterns → relax a constraint → ask a precise question.
• The candidate tests their own code before declaring done — a real trace with real values, plus a deliberately chosen edge case, and finds their own off-by-one.
• Tradeoffs are raised unprompted and tied to a use case, with a stated condition that would flip the decision, rather than a memorized complexity table recited on request.
• A wrong approach is abandoned early and out loud. The counterexample or the missed constraint is stated, kept on the board, and used as the first line of the next approach.
• Correctness is claimed with an invariant, not with examples. One sentence says what stays true throughout, or why a discarded option cannot matter.
• Hard problems are recognised as hard. When the constraints point at an exponential method, the candidate says which problem it resembles and works within the stated size instead of hunting for a polynomial algorithm.
• Corrections are absorbed without defensiveness. A hint is taken, integrated, and credited — "good catch, that breaks when the values are negative; let me fix the invariant" — because the interviewer is simulating what code review with you feels like.
• Uncertainty is stated honestly and bounded. "I'm fairly sure this is O(n log n) amortized but I'd want to double-check the resize cost" beats a confident wrong claim every time, and it is the difference between an engineer you can trust and one you have to verify.