Knowing every pattern in this site doesn’t help if you freeze the moment someone reads you a problem out loud. The coding interview is a communication test wrapped around a coding test — the interviewer is watching how you think, not just whether you eventually produce working code. This page is the playbook: the shape of the loop you’ll face, a repeatable seven-step framework for any problem, and what to actually say at each step.

What you’ll learn

• The typical FAANG-style interview loop — phone screen through onsite.
• A repeatable seven-step framework: clarify, examples, brute force, optimize, code, test, analyze.
• What to say out loud at each step, and what the interviewer is quietly scoring.
• How to get unstuck without going silent for five minutes.
• How to talk through complexity analysis like it’s second nature.
• The most common ways candidates lose points, and a brief look at behavioral basics.

The interview loop

Most FAANG-style processes follow the same rough shape, whether the company calls it “phone screen + onsite” or “loop”:

The coding rounds are where this whole site pays off directly — and they’re graded less on “did you get the optimal answer instantly” and more on “did you get there through a process I’d trust in a teammate.”

The seven-step framework

Run every problem through the same sequence, in the same order, every time. Interviewers have seen hundreds of candidates skip straight to coding — doing the earlier steps out loud is itself a huge signal.

  graph TD
    N0["1. Clarify"] --> N1["2. Examples"]
    N1 --> N2["3. Brute force"]
    N2 --> N3["4. Optimize"]
    N3 --> N4["5. Code"]
    N4 --> N5["6. Test"]
    N5 --> N6["7. Analyze"]
    N6 -- "bug found or better idea" --> N3

1. Clarify

Restate the problem in your own words and ask about the shape of the input before writing a single line of code.

Say: “So given an array of integers, I need to return the two indices whose values sum to a target — can the array have duplicates? Is it always sorted? What should I return if there’s no valid pair?”

Scored on: whether you notice edge cases the prompt didn’t spell out — empty input, negative numbers, duplicates, integer overflow (less of a concern in Python, but worth mentioning for languages that have it).

2. Examples

Write down (or ask to write down) one small example by hand, and one edge case. This surfaces misunderstandings before they’re baked into code.

Say: “Let me trace a quick example: [2, 7, 11, 15][2, 7, 11, 15] with target 99 should give indices 0, 10, 1. And an empty array, or no valid pair, should give… what would you like for that case?”

Scored on: catching ambiguity early is cheaper than catching it after you’ve written twenty lines of code around the wrong assumption.

3. Brute force

State the naive $O(n^2)$-or-worse solution out loud, even if you never type it. It proves you understand the problem and gives you a baseline to optimize from.

Say: “The brute force is to check every pair with a nested loop — that’s $O(n^2)$ time, $O(1)$ space. I think we can do better with a hash map.”

Scored on: never skip this step even when the optimal approach is obvious to you — naming the brute force shows you can recognize why the optimization is an improvement, not just recite a memorized answer.

4. Optimize

This is where pattern recognition does the heavy lifting — see the Pattern Recognition Guide (next page) for the cue-to-pattern lookup. Name the pattern and the trade-off before coding it.

Say: “Sorted array plus pair-sum is the cue for two pointers — or since this one isn’t sorted, a hash set trades $O(n)$ space for a single $O(n)$ pass instead of sorting first.”

Scored on: articulating why the optimization works, not just that it exists.

5. Code

Write clean, working code — meaningful variable names, small helper functions where they help readability, and a narration of what you’re doing as you type so the interviewer isn’t watching you in silence.

Say: “I’ll use a dictionary mapping value to index as I scan once left to right, checking for the complement before inserting the current value.”

Scored on: syntax correctness matters less than most candidates fear — structure, naming, and whether the code matches the approach you just described matter more.

6. Test

Trace your own code against the examples from step 2 by hand, out loud, before the interviewer asks you to. Then check the edge cases.

Say: “Let me trace this against [2, 7, 11, 15][2, 7, 11, 15], target 99… at index 0, value 2, complement 7 isn’t in the map yet, so I insert 2. At index 1, value 7, complement 2 is in the map — return [0, 1][0, 1]. Matches.”

Scored on: finding your own bugs before being told about them is one of the strongest signals in the whole interview.

7. Analyze

State the final time and space complexity, and mention any trade-offs against the brute force or alternative approaches.

Say: “This is $O(n)$ time and $O(n)$ space — trading memory for speed compared to the $O(n^2)$ brute force, or $O(n \log n)$ if we sorted first and used two pointers.”

Communication tips

• Think out loud, always. Silence for more than about 30 seconds reads as “stuck,” even if you’re actually making progress in your head.
• Narrate before you type. Say what you’re about to code, then code it — don’t make the interviewer reverse-engineer your plan from keystrokes.
• Ask, don’t assume. Constraints on input size, value ranges, and expected output format are all fair game to ask about, and asking is free signal.
• State assumptions if no answer is available. “I’ll assume the array fits in memory and values can be negative” keeps you moving without waiting on an answer that may not come.

Getting unstuck

Going quiet is the worst thing you can do when stuck. Instead:

1. Re-read the constraints. Constraints often hint at the intended complexity — see Contest Strategy later in this phase for the constraint-to-complexity table, which applies just as much to interviews.
2. Fall back to the brute force. A working $O(n^2)$ solution beats a broken $O(n)$ one — say so, and offer to optimize if time allows.
3. Ask for a hint. “Is there a data structure that would help me look up values faster here?” is a completely normal thing to ask, and most interviewers will nudge you.
4. Simplify the problem. Solve a smaller or restricted version first (ignore duplicates, assume sorted input) and generalize once that works.
5. Time-box it. If five minutes pass with no progress, say what you’re stuck on explicitly rather than staring silently — that’s still a demonstration of process.

Common mistakes

• Jumping straight to code without stating an approach — the interviewer can’t follow your reasoning if there isn’t any spoken reasoning.
• Debugging in silence. Narrate what you’re checking as you trace through the code, the same way you would for the initial test step.
• Ignoring edge cases until asked — empty input, single element, all duplicates, and negative numbers are worth a mention even if the interviewer doesn’t bring them up first.
• Skipping the complexity statement at the end — always say it, even if it feels obvious.
• Over-engineering. Building a fully generic, configurable solution for a 45-minute problem burns time better spent on correctness and testing.

Behavioral basics

A short behavioral round or a few behavioral questions embedded in a coding round are common. The STAR structure keeps answers concise:

Prepare two or three stories in advance (a conflict, a failure, a project you’re proud of) so you’re not improvising STAR structure live — the content matters less than answering in a focused, complete way.

🧪 Try It Yourself

Recap

• Every FAANG-style loop mixes coding rounds with system design and behavioral rounds — each is scored mostly independently.
• The seven-step framework — clarify, examples, brute force, optimize, code, test, analyze — is the same for every problem, and running it out loud is itself the signal.
• Getting unstuck means falling back to the brute force, re-reading constraints, or asking a targeted question — never going silent.
• STAR (Situation, Task, Action, Result) keeps behavioral answers short and concrete.

Next: Pattern Recognition Guide — the cue-to-pattern lookup table that powers step 4 (optimize) of the framework above.