The Coding-Interview Playbook - How to Pass the Technical Round (Staff+ oriented)

What this is: the meta-guide for the other six. Not "how to invert a binary tree" - how to walk into a 45-minute coding round, read the problem, pick the right pattern, write clean code while talking, test it, and come across as someone the panel wants to work with. Process, decision tables, and communication first; algorithms live in guides 01-06.

Series map: 00 playbook (this file) · 01 two-pointers & sliding window · 02 binary search, stacks & intervals · 03 trees & graphs · 04 recursion & backtracking · 05 dynamic programming · 06 Staff+ practical coding & OOD. Companion (separate track): data-structures-java-kotlin-study-guide.md - which collection to reach for, HashMap/ConcurrentHashMap internals, Big-O with cache/boxing/GC, the equals/hashCode/Comparable contract. When a guide needs a heap, trie, or union-find as a tool, it uses it and points you there for the internals.

The mental model#

The coding round is a communication-and-judgement test wearing an algorithm costume. The company is not buying a solution to Two Sum - they already have it. They are simulating one hour of working with you and asking a hiring committee: do we want this person on the pager rotation, in code review, in a design meeting? Everything else derives from that.

Concretely, you are scored on five axes, not one: problem-solving process, communication, code quality, testing, and how you behave when stuck. Pattern recognition - the thing most people grind for - only gets you past the front door; it is the price of admission, not the thing being evaluated once you're inside. A candidate who silently produces an optimal solution often scores below one who talks through a slightly-slower approach cleanly, because the silent one gave the panel nothing to write on four of the five axes.

Three corollaries that this whole guide unfolds from:

1. A wrong-but-communicated approach beats a right-but-silent one on the rubric, but not by enough to skip the algorithm. interviewing.io's ~100K-interview study found raw problem-solving and coding scores still dominate outcomes (a 4-4-2 code/solve/communicate profile advances far more than a 3-3-4). Communication is a floor you must clear, not a substitute for solving the problem. Its weight rises at senior/staff; it never fully replaces the code.
2. The interviewer is a collaborator you are steering, not a judge you are performing for. Seniors drive: they state assumptions, propose, and check in. Juniors wait for hints. The single most senior behaviour is making the implicit explicit - out loud, before you're asked.
3. You are being watched most closely at the moment you get stuck. Anyone can type out a memorised solution. How you recover from a dead end is the highest-signal minute of the interview.

Keep this sentence in your head the whole hour: "I am showing them what it's like to solve a problem with me."

1. The interview loop and formats#

The full-time backend loop at FAANG-type firms in 2025-26 is fairly standardised. Treat exact counts as typical, not guaranteed - they vary by company, team, level, and req.

Per coding round budget (~45 min): roughly 5 min clarify + approach, 5 min design/plan with buy-in, 20-25 min code, 5-8 min test + complexity, 2 min follow-up. You will not get the full 45 to code - plan for ~25. Rounds that give you two problems expect the first solved in ~20.

Content, as of 2025-26: predominantly live, LeetCode-style DS&A; modal difficulty Medium-to-Hard, and the bar has crept up (~15% / 10 percentile points harder than early 2022). Complete, bug-free implementations with edge-case handling are now expected - partial solutions read as a miss. Alongside pure algorithms there's a clear tilt toward "practical" prompts: simulate a system's behaviour, "write a class that processes a stream," design/implement a data structure with an API, parse/evaluate an expression - especially at infra companies. Take-homes and pair-programming remain rare at FAANG; more common at startups and mid-caps (Stripe/Coinbase/OpenAI lean open-ended and realistic).

AI-assistant policy is a live, moving target. Big-tech generally still prohibits AI in coding rounds (Amazon reportedly flags a large share of covert use); many startups now permit or encourage it. Confirm per company with your recruiter - do not assume.

Snowflake-specific (self-reported, treat as emphasis not spec): recruiter screen → OA (HackerRank/CodeSignal, ~90-120 min, 2-3 medium-hard problems, sometimes SQL/data-processing) → a 60-min technical phone screen (live coding, often "simulate system behaviour" plus language-internals discussion) → a 4-5 round virtual onsite reported as roughly 2 coding + 1 system design + 1 behavioural, with a project/tech-talk round added at senior levels. End-to-end ~2-6 weeks. Reputation: one of the harder non-FAANG loops; the OA is repeatedly called "the hardest aspect," skewing harder than average LeetCode. Topic emphasis reflects a data-warehouse/infra company: heavy DP, graphs (BFS/DFS), backtracking, and distinctively concurrency/thread-safety (locks, races, thread-safe structures), plus SQL fluency (window functions, JSON/semi-structured) and "simulate the system" coding (web crawler/BFS, dependency ordering/Kahn's, stream processing, stack parsing). See §9.

Currency flag: everything in this section is 2025-26. Round counts, OA presence, and AI policy change quarterly. Ask the recruiter for the current format; it is a normal, expected question.

2. The execution framework - a minute-by-minute playbook#

Have one framework and run it every single time, out loud, until it's muscle memory. Names vary (UMPIRE, Clarify-Plan-Code-Test-Analyze, REACTO); the steps are the same. The point is not the acronym - it's that under stress you fall back to a rehearsed sequence instead of freezing or diving straight into code (the #1 unforced error).

U-M-P-I-R-E: Understand · Match · Plan · Implement · Review · Evaluate.

Step-by-step, with sentences to actually say#

1. Understand / clarify (2-4 min). Restate the problem in your own words. Nail down input types, output type, ranges/constraints, and edge cases before thinking about algorithms. Work one small example by hand.

"Let me make sure I've got this. I'm given an array of ints and a target; I return the indices of the two that sum to it. Can the array be empty? Can values be negative? Is there always exactly one solution, or zero-or-many? Are duplicates allowed? Roughly how large is n?"

Constraints are not trivia - they are the answer key (see §3). Reading them is a senior tell.

2. Match (1-2 min). Say out loud which pattern the cues point to. This is where §4's cue→pattern map earns its keep.

"'Find a pair summing to a target' plus 'unsorted' - that's the complement-lookup / hash-map pattern. If it were sorted, I'd reach for two pointers instead."

3. Plan - brute force, then optimal, then GET BUY-IN (3-5 min). State the brute force with its complexity first (it proves you understand the problem and gives you a floor). Then propose the optimal with its complexity. Then stop and ask before you type.

"Brute force is every pair - O(n²) time, O(1) space. I can do better: one pass with a hash map from value→index, checking for the complement as I go. That's O(n) time, O(n) space. I'll trade memory for speed. Shall I code the hash-map version, or would you like to see something else first?"

That last sentence - the buy-in - is the highest-leverage phrase in the interview. It prevents you from coding the wrong thing for ten minutes, and it reads as collaborative.

4. Implement (15-25 min). Code cleanly while narrating intent, not syntax. Names, guard clauses, small helpers (§6). Narrate the invariant, not the keystrokes.

"I'll keep a map of values I've already seen. For each element I compute what I still need; if I've seen it, I'm done; otherwise I record the current value and move on. The invariant is: the map always holds every value strictly to the left of i."

5. Review / test (3-6 min). Do not say "that should work." Dry-run a concrete normal input line by line, tracking state in a trace table (§6). Then walk the edge-case checklist: empty, one element, duplicates, negatives, overflow, all-same, already-sorted, no-answer. Fix bugs you find out loud - self-correction is a positive signal, not an admission of failure.

"Let me trace [3,2,4], target 6. i=0: need 3, map empty, store {3:0}. i=1: need 4, not seen, store {3:0,2:1}. i=2: need 2, seen at index 1 → return [1,2]. Correct. Now edge cases: empty array returns empty; single element can't form a pair; if the same value is reused I store index after checking, so I won't match an element with itself."

6. Evaluate (1-2 min). State final time/space, and name a realistic improvement or a scaling concern. This is where you plant a Staff+ flag (§8).

"Final: O(n) time, O(n) space, single pass. If n didn't fit in memory I'd stream and shard by hash; if I needed all pairs rather than one, the map would store lists of indices."

The discipline that separates seniors: you narrate the whole time, you ask before coding, and you test without being told to. Silence during any step is lost signal.

Below is the canonical worked example (Two Sum) that the script above runs on, in both languages. Note the guard on the return contract and the "store after check" ordering that the dry-run verified.

3. Constraints → complexity target (reverse-engineer the intended solution)#

Before you design anything, read n. The input size tells you the intended time complexity, which tells you the family of techniques, which often tells you the specific pattern. Doing this out loud - "n is 10⁵, so O(n²) is 10¹⁰ operations, too slow; I need n log n or better" - is a senior move that eliminates whole branches of the search space in ten seconds.

Mental yardstick: a modern CPU does ~10⁸ simple operations per second in the "will this pass" sense CP folks use. Interviews rarely enforce runtime, but the constraint still encodes the expected solution - matching it signals you know your Big-O.

How to actually use it, in order:

1. Read the constraint. Compute the naive cost. If naive fits, say so and consider just doing it - clarity beats cleverness (§8: don't over-engineer).
2. If naive is too slow, the table names your target. 10⁵ and naive is n²? You need to shave a factor of n → sort (removes a loop), hash (removes a lookup loop), two-pointer/sliding-window (removes the inner loop), or binary search (turns n into log n).
3. A huge value range with a small n (e.g. "coins up to 10⁹, at most 20 of them") screams binary-search-on-answer or bitmask, never a DP array indexed by value.

Trap: "n ≤ 20" almost always means an exponential solution is intended and fine. Candidates burn ten minutes hunting a polynomial algorithm that doesn't exist. The tiny constraint is permission to brute-force with bitmask/backtracking.

4. The master pattern-recognition cheat sheet (cue → pattern → guide)#

This is the table you internalise. In the room, the sentence "the cue here is X, which is the Y pattern" is worth its weight in offer letters. Cues are drawn from the standard pattern catalogues (Grokking/DesignGurus, NeetCode).

How to read it live: most Mediums are one primary pattern plus a data-structure choice. Hards are often two patterns stacked (e.g. binary-search-on-answer whose feasibility check is a greedy sweep; or DP whose transition uses a monotonic deque). When one cue doesn't crack it, ask "what's the sub-problem?" and re-run the table on that.

5. Study roadmap + priority tiers#

Grind patterns, not problem count. The goal is: read a prompt, recognise the pattern in under a minute, and reproduce the template from memory. Use Blind 75 as the spine (one representative per pattern), NeetCode 150/250 as the expanded set (spaced repetition across a pattern), and Grokking the Coding Interview patterns for drilling recognition. Aim for ~200-250 quality problems understood, not 600 skimmed.

Suggested order (build dependencies): hashing & two pointers → sliding window → binary search → stacks/monotonic → trees (DFS/BFS) → graphs (BFS/DFS → topo → union-find → Dijkstra) → backtracking → 1-D DP → 2-D/knapsack DP → heaps/intervals/greedy → Tier 3.

How to practise so it sticks:

• Timebox. 25-30 min per Medium. If stuck, read the approach (not the code), close it, and re-implement from scratch. Reading solutions passively teaches nothing.
• Spaced repetition. Re-solve day 1, day 7, day 30. If you can't reproduce a pattern's template cold in ~20 min, it isn't learned - it's recognised, which collapses under interview stress.
• Mock out loud. Half your prep should be verbalised - solo rubber-duck or peer mocks. The bottleneck at the real thing is talking-while-thinking, and you can't cram that on the day.
• Log your misses. Keep a list of why you missed each problem (wrong pattern? off-by-one? gave up early?). Patterns in your misses are worth more than the solutions.

Pre-interview timeline (compress or stretch to fit your runway):

6. Writing interview-clean code#

The bar in 2025-26 is a complete, correct, readable solution - not a partial or a code-golf one-liner. "Solid, honest, maintainable" beats "clever, hacky, unreviewable" on every committee. Optimise for the reviewer over your shoulder.

Which language? Pick fluency over fashion. The round tests problem-solving, not language trivia - code in whatever you're fastest and least buggy in. For a Kotlin-2 backend engineer that's Kotlin; use it, and know these room-specific edges cold (cross-ref the companion DS guide for collection internals):

• Kotlin wins on density → less boilerplate means more minutes to think and talk: data class for tuples/return types, destructuring (val (a, b) = pair), when, ranges (for (i in 0 until n)), null-safety that forces edge-case thinking, and stdlib (groupingBy, maxByOrNull, ArrayDeque, sortedBy).
• Kotlin traps: use IntArray/LongArray (not Array<Int>) to avoid boxing; grids are Array<IntArray>. Int is 32-bit - overflow is real, promote sums to Long. No ternary - if/else is an expression. Recursion has no TCO unless you mark a genuinely tail-recursive function tailrec. TreeMap/PriorityQueue come straight from java.util.
• Java wins on ubiquity and explicitness but costs verbosity: Map<Integer, Integer>, autoboxing, and the classic Integer identity trap (== compares references outside the -128..127 cache - use .equals/unbox). int overflow and int[] vs Integer[] are the usual bugs.

Whichever you choose, have its map/list/deque/heap/sorted-structure APIs memorised - fumbling the standard library on a Medium reads as under-preparation.

Checklist while typing:

• Meaningful names. seen, need, runningSum, left/right - never a, x, tmp, flag.
• Guard clauses first. Handle null/empty/single-element up top; don't nest the happy path.
• Small helpers. Extract the messy inner step (e.g. isValid(...), neighbors(...)); it reads better and isolates bugs.
• No premature optimisation. Clarity first; micro-opt only if the constraint demands it and you've said why.
• Modern idioms. Java 17-21: record, enhanced switch, Map.getOrDefault/computeIfAbsent, var for obvious locals, text blocks. Kotlin 2: data classes, when, scope functions used sparingly, ArrayDeque, require/check for guards. Use real APIs only.

Before → after. The "before" is a common panic-mode answer: O(n²) max-subarray with terrible names. The "after" is Kadane's - O(n), guard clause, clear names. This before/after does double duty: it shows both "don't settle for brute force" (§3) and clean code.

Test your own code in the room - the dry-run trace table. Pick a concrete input and track every variable per iteration. This is how you find bugs before the interviewer does; narrate it. Trace of Kadane on [-2, 1, -3, 4, -1, 2, 1, -5, 4]:

Answer 6 (the subarray [4, -1, 2, 1]). The table proves correctness to the panel far more convincingly than "yeah that looks right."

The edge-case checklist (run it every time): empty · single element · two elements · all duplicates / all-same · negatives / zero · integer overflow (use long for sums; left + (right-left)/2 for mid) · already-sorted / reverse-sorted · no valid answer · maximum-size input (does your recursion blow the stack?).

7. Communication & handling being stuck#

Think aloud, always. The interviewer can only score what they hear. Narrate assumptions, the invariant you're maintaining, why you rejected an approach. Silence is not "focus" to them - it's missing data on the communication axis, and it makes them nervous.

When you're stuck (the highest-signal moment):

1. Never go silent. Say what you're stuck on: "I'm trying to avoid the O(n²) inner loop - I think there's a way to remember the best-so-far, but I haven't pinned the invariant." That sentence alone scores problem-solving points and often unblocks you.
2. Re-derive from a small example. Solve n=3 by hand, watch what your brain does, generalise the mechanic. Most "I'm stuck" is really "I stopped grounding in examples."
3. Re-run the cue table (§4). Wrong pattern is the usual culprit. "Let me reconsider - maybe this is binary-search-on-answer rather than DP."
4. Ask for a hint gracefully. "I have a working O(n²); I suspect an O(n log n) exists - am I on a reasonable track, or is there a data structure I'm not seeing?" Asking well is a positive signal (collaboration); flailing silently is not.
5. Fall back deliberately. A correct brute force beats a broken optimal. Around the halfway mark: "Let me get the O(n²) fully working and tested, then optimise if time allows." Then say the optimal's idea even if you don't finish it - stated intent still scores.

Recovering from a wrong approach: name it and pivot without drama. "This greedy fails on [...] - the counterexample shows a local choice that isn't globally optimal, so I'm switching to DP." Admitting and correcting is strength; committees explicitly reward candidates who handle their own misunderstandings gracefully, and ties go to them.

Time management: budget per §2. If the optimal isn't landing by ~60% of the clock, lock in the working sub-optimal and tell them you're doing so. Running out of time with nothing runnable is the worst outcome; a tested brute force is a real, scoreable result.

The interviewer's rubric - what "strong" looks like on each axis (Tech Interview Handbook's four axes, graded Strong-Hire → Strong-No-Hire and aggregated by committee; 2026 rubrics add code quality, edge-case/failure thinking, ownership, and - for infra - production-readiness):

Reality check (interviewing.io, ~100K interviews): raw coding and problem-solving scores dominate outcomes. Communication is a floor you must clear, then a multiplier at senior/staff - not a way to skip the algorithm. Be strong on solve+code and talk well; don't trade one for the other.

8. Staff+ framing - how coding rounds shift with level#

The biggest change up the ladder is the round mix, not the disappearance of coding. One credible 2025 synthesis (directional, not audited): junior ~80% algorithms / 20% behavioural; mid ~50% coding / 25% design / 25% behavioural; senior ~20% coding / 50% system design / 30% behavioural; staff+ ~90% system-design + behavioural/leadership with coding often a sanity check. Staff+ loops are explicitly non-standardised - could be an EM-style loop, a senior loop plus a design deep-dive, or accomplishment/architecture-review + presentation rounds - and depend heavily on panel composition (a panel of junior/mid engineers rarely generates a staff offer).

What the coding round measures once you're senior+: interviewers weight judgement over raw speed. You still code, but you're scored on:

• Modelling & interface design. Do you pick clean types and a sensible API before implementing? Name the operations and their contracts.
• Extensibility. "If the next requirement is X, this class absorbs it here." Show the seams.
• Tradeoff articulation. Every choice stated as a trade: memory vs latency, accuracy vs O(1) space, simplicity vs generality.
• Driving & surfacing ambiguity. You set the direction, state assumptions, and make the implicit explicit. Strong seniors lead; weak ones over-design or wait for hints.
• Production concerns inside a coding problem. Concurrency (is this thread-safe?), scale (does it hold at 10⁶ keys?), failure (what if the clock goes backwards, the input is unbounded, a dependency is down?).

The prompt itself skews practical/OOD - "design a data structure with this API," "write a class that processes a stream," a rate limiter, an LRU cache, a parser - rather than an obscure DP. That plays to backend strengths: you model a domain and evolve it. Guide 06 is the deep-dive; treat this as the framing.

A practical Staff+ example. "Write a rate limiter" is a classic infra-flavoured coding prompt (and, mapping to your world, exactly the sliding-window limiter shape inside a Kafka webhook-notification service like ONS). Note what makes it a staff answer: you state the single-threaded version first, name the concurrency concern explicitly, and call the accuracy/memory tradeoff against alternatives - all without being asked.

What NOT to do at Staff+ (each is a documented anti-pattern):

• Over-engineer / gold-plate. Building a plugin framework for a 30-line problem reads as poor judgement, not sophistication. Solve this problem cleanly; mention the extension, don't build it.
• Go silent / stop driving. At staff the interviewer expects you to run the session. Passivity reads as "can't lead."
• Ignore the interviewer's nudges. A hint you talk over is a No-Hire waiting to happen. Integrate it and credit it.
• Skip the tradeoffs. A correct solution with no articulated alternatives is a mid-level answer. The comparison is the point.

9. Company specifics (2025-26, with currency flags)#

Big-tech coding rounds, generally: live, LeetCode-style, Medium-to-Hard, bug-free-with-edge-cases expected. AI use generally prohibited in the coding round (Amazon reportedly flags a large share of covert use). The round mix thins on coding and thickens on design/behavioural as level rises (§8). Rubric-driven, committee-aggregated (§7).

Snowflake (self-reported; emphasis, not an official spec):

• Difficulty: among the harder non-FAANG loops; the OA is repeatedly called the hardest part, skewing above average LeetCode. Prepare for Hard, not just Medium.
• Topic emphasis (data-warehouse/infra DNA): heavy DP, graphs (BFS/DFS), backtracking; distinctively concurrency/thread-safety (locks, races, thread-safe structures - practise these, most candidates neglect them); SQL fluency (window functions, analytical queries, JSON/semi-structured); and "simulate the system" coding (web crawler/BFS, dependency ordering/Kahn's, stream processing, stack parsing).
• System design skews infrastructure over consumer products: a distributed rate limiter, an RPC system, a quota/metadata service, a resource scheduler - not "design Twitter." Expect probes into DB internals (MVCC, LSM-trees vs B-trees, columnar storage, query planning).
• Behavioural centres on ownership and individual contribution via STAR. Senior candidates typically get an added ~30-min tech-talk / project presentation: structure it as problem → technical choices → tradeoffs.
• Staff+: as everywhere, non-standardised and panel-dependent; more scope/leadership signal, coding as a sanity check.

Currency flag: the concrete Snowflake detail (question examples, "harder than FAANG," DP/graph emphasis) comes from prep-vendor guides and Glassdoor/Blind/LinkedIn self-reports aggregating LeetCode tags and small samples. It indicates emphasis, not a published spec - Snowflake, like most firms, doesn't publish its rubric. The level round-mix percentages are one source's synthesis: directional, not audited. Always confirm the current format with your recruiter; AI policy and the practical-coding shift are moving fast in 2025-26.

Problems & how to solve them (meta-problems in the room)#

Problem: You froze on a hard problem - blank for two minutes. Root cause: you tried to see the whole solution at once instead of grounding in an example, and you went silent so nobody could help. Fix: immediately drop to a concrete small input and solve it by hand, out loud. Narrate the mechanic your brain used and generalise it. Re-run the cue table (§4) on the sub-problem. The act of talking restarts problem-solving and converts dead air into scoreable signal.

Problem: You finished and the interviewer looked unimpressed. Root cause: usually you solved it silently or skipped complexity/tradeoffs, so they had nothing to write on communication, problem-solving, or CS-fundamentals - a correct answer that scores 3/5. Fix: after any solution, always close the loop - state final time/space, name one alternative and why you rejected it, name one edge case you handled, and one scaling concern (§2 step 6, §8). The comparison is what separates hire from strong-hire.

Problem: You ran out of time with nothing runnable. Root cause: you chased the optimal from the start, or over-clarified, or over-engineered - no working fallback. Fix: get a correct brute force coded and tested by ~40% of the clock (§3 says whether brute even needs improving). State the optimal's idea aloud even if unfinished - stated intent scores. Never let the buzzer find you with zero runnable code.

Problem: Your code worked but was messy - bad names, one giant function, no guards. Root cause: you optimised for "get it working" and forgot the reviewer axis; committees down-rank "clever/unreviewable." Fix: rename as you go (seen, runningSum, not m/c), guard clauses up top, extract the ugly inner step into a helper, delete dead code before you say "done." Readability is a scored axis in 2026 rubrics, not a nicety.

Problem: You couldn't find the optimal and it clearly wanted one. Root cause: wrong pattern lock-in, or you didn't read the constraint (§3) to see what complexity was even being asked for. Fix: re-read n and back out the target complexity - it names the technique family. Say the brute force's bottleneck explicitly ("the inner loop re-scans") and ask which structure removes it (sort? hash? heap? two-pointer? binary search?). Ask for a hint well (§7) - a graceful ask costs far less than silent flailing, and often unlocks the last step.

Interview framing / how to sound senior#

Power phrases (say these):

• "Before I code - constraints: how large is n, can values be negative, is the input sorted, is a solution guaranteed?"
• "Brute force is O(n²); I think I can get O(n log n) by sorting first. Want me to code the optimal, or start with brute force?" ← the buy-in.
• "The invariant I'm maintaining is …"
• "Let me trace a concrete example before I claim it works."
• "Tradeoff: this is O(1) memory but approximate; the exact version costs O(k). For a rate limiter I'd take the approximate one."
• "If this needed to scale to 10⁶ keys / be thread-safe / survive a failed dependency, I'd change …"

Anti-phrases (never say these):

• "This should work." → trace it instead.
• [silence for 90 seconds] → narrate the block.
• "I've seen this one, it's …" then type a half-remembered solution → re-derive; memorised code breaks under a twist.
• "Can I just use a library for this?" on an algorithm prompt → they want to see you build it.
• Arguing with a hint → integrate it and credit it.

Steer, don't perform: propose → check in → narrate → test → evaluate. The candidate who drives the session, states assumptions, and compares tradeoffs out loud reads as senior regardless of whether they reach the optimal.

Cheat-sheet - the whole playbook on one page#

The 6-step loop (say it out loud every time):

1. Understand - restate; clarify I/O, constraints, edges; work one small example.
2. Match - name the pattern from the cue table.
3. Plan - brute force + Big-O → optimal + Big-O → get buy-in before coding.
4. Implement - clean names, guard clauses, small helpers; narrate the invariant.
5. Review - dry-run trace table on normal + edge cases; fix bugs aloud.
6. Evaluate - final Big-O + one improvement + one scaling/failure concern.

Constraint → target complexity:

Cue → pattern (top of the list wins): sorted + pair/target → two pointers · contiguous + longest/shortest/at-most-k → sliding window · seen/dup/complement → hash map · sorted-or-rotated / minimize-the-max → binary search · list of [start,end] → intervals sort+sweep · next-greater/smaller → monotonic stack · k-largest/most-frequent/median → heap or quickselect · all subsets/perms/combos → backtracking · #ways / min-max cost / can-reach → DP · tree/graph/grid explore → DFS · fewest-steps unweighted → BFS · weighted shortest path → Dijkstra · prerequisites/build-order → topological sort · groups/connectivity/undirected-cycle → union-find · cycle/middle of linked list → fast/slow · values 1..n, O(1) space → cyclic sort · range-sum / subarray=k → prefix sum · O(1)-space number trick → bit manipulation.

Edge cases every time: empty · one · two · all-same · negatives/zero · overflow (long sums, left+(right-left)/2) · already-sorted · no-answer · max-size (stack depth).

Self-test#

1. State the five axes you're scored on. Which two dominate outcomes, and how does that weighting shift from junior to staff?
2. Recite the 6-step loop from memory. Which single step do most candidates skip, and what does skipping it cost?
3. Give the exact sentence you use to get buy-in before coding. Why is it the highest-leverage phrase in the interview?
4. n ≤ 20 and the problem asks for a min-cost subset selection - what complexity is the constraint permitting, and which technique?
5. n = 10⁵, your brute force is O(n²) - compute the operation count, say whether it passes, and name three ways to remove the factor of n.
6. From cue alone: "longest substring with at most two distinct characters." Pattern? Which guide? What's the invariant?
7. From cue alone: "minimum number of trucks so no truck's load exceeds capacity." Why is this binary-search-on-answer and not greedy-only?
8. Walk a dry-run trace table for Kadane's on [5, -9, 6, -2, 3]. What's the answer and the subarray?
9. You're stuck and silent for a minute. Give the exact sentence that converts the silence into a positive signal.
10. Halfway through, the optimal isn't landing. What do you do, and what do you say while doing it?
11. Two candidates: A silently writes the optimal; B narrates a working O(n²), states the O(n log n) idea, and tests. Who scores higher and why?
12. Name three "production concerns" you'd raise inside a coding problem to plant a Staff+ flag on a rate-limiter prompt.
13. What are the two most common ways to over-engineer a Staff+ coding round, and what should you do instead?
14. Snowflake: name two topic emphases most candidates under-prepare, and one thing about its OA you should plan for.
15. Your solution works but uses m, c, and one 20-line function. List the four edits you make before saying "done."

Lineage / sources#

Framework (UMPIRE / Clarify-Plan-Code-Test-Analyze) is the standard interview loop taught across Tech Interview Handbook, interviewing.io, and CodePath. Rubric axes (Communication, Problem Solving, Technical Competency, Testing) from Tech Interview Handbook's coding-interview rubrics; 2026 additions (code quality/maintainability, edge-case/failure thinking, ownership, production-readiness) from Prepfully's SWE rubric (2026). The "raw solve+code dominate, communication is a floor" finding from interviewing.io's ~100K-interview study. Pattern catalogue and recognition cues from DesignGurus/Grokking the Coding Interview and NeetCode 150/250; Blind 75 as the canonical spine. Loop formats, difficulty drift, and the practical-coding/AI-policy shift from Underdog.io (2025), Formation's senior guide, and interviewing.io's senior FAANG guide. Level round-mix and Staff+ non-standardisation from StaffEng's interviewing guide (directional synthesis, not an audited statistic). Snowflake specifics aggregated from Exponent, AlgoMonster, bugfree.ai, TechPrep, and Linkjob guides drawing on self-reported Glassdoor/Blind/LinkedIn accounts.

Currency: written for the 2025-26 cycle. Round counts, OA presence, AI-tool policy, and Snowflake detail are moving targets and partly self-reported - treat as typical emphasis, not guarantees, and confirm the current format with your recruiter. Companion guide data-structures-java-kotlin-study-guide.md owns collection choice and JVM/DS internals; algorithm depth lives in series guides 01-06.