The interview flow#
Use the same mental loop on unfamiliar problems. The details change; the sequence keeps the reasoning visible and prevents premature coding.
- 01Understand
Build the right problem contract before solving.
- Restate
- Identify input/output
- Inspect an example
- 02Clarify
Ask only questions that could change the solution.
- Constraints
- Edge cases
- Assumptions
- 03Solve
Anchor correctness, then remove the bottleneck.
- Baseline
- Optimize
- Validate
- 04Code
Implement clearly while explaining decisions.
- Invariants
- Clear names
- Reviewable steps
- 05Test
Trace the algorithm and repair the smallest defect.
- Sample
- Edge case
- Boundaries
- 06Analyze
Close with costs, tradeoffs, and variations.
- Time
- Space
- Follow-up
5-Minute Review
The smallest useful version of the playbook.
- 01Restate the problem
- 02Clarify constraints
- 03Explain a correct baseline
- 04Identify the bottleneck
- 05Propose the optimization
- 06Confirm the approach
- 07Code in reviewable steps
- 08Test deliberately
- 09State time and space complexity
- 10Adapt to the follow-up
Explain decisions, not keystrokes.
Step 1 - Understand before solving#
Do not translate the first sentence directly into code. Establish the contract, then solve the problem you and the interviewer agree on.
- What exactly is the input?
- What should be returned?
- Is the input ordered?
- Can values repeat?
- Can the input be empty?
- What input scale matters?
“We're given an integer array and need the indices of two distinct elements that sum to the target. We can assume exactly one pair exists. Is that correct?”
Adapt the structure; do not memorize the sentence.Step 2 - Clarify what changes the solution#
Ask questions with algorithmic consequences. You do not need to enumerate every conceivable edge case.
- Can values repeat?
- Is the input sorted?
- Can the input be empty?
- What scale should I expect?
- If time and memory trade off, which matters more?
- Asking which language to use after it was established.
- Listing every edge case before understanding the core behavior.
- Asking something already answered by the prompt.
- Seeking permission for every ordinary implementation choice.
Ask questions that can change your solution.
Let constraints guide - not dictate - the approach#
Exponential search or backtracking may be reasonable.
A carefully justified O(n²) approach may be reasonable.
Usually investigate O(n log n) or O(n).
Linear or near-linear work often becomes important.
Rules of thumb only. Runtime constants, input shape, language, and interview expectations can change what is reasonable.
Walk through one useful example#
Use the example to expose behavior before selecting a pattern. For [2, 7, 11, 15] and target 9, ask what information a scan needs, what work a pairwise search repeats, and what could be stored.
Edge-case prompts worth keeping available
Empty input, one element, duplicates, negative values, very large values, already-sorted input, all-identical values, and the minimum or maximum valid size.
Choose only cases that stress the chosen data structure, invariant, or boundary.
Step 3 - Establish correctness, then optimize#
Start with a correct baseline#
- Describe the simplest correct solution.
- Give its time and space cost.
- Identify the operation responsible for the cost.
- Optimize that bottleneck.
Use signals, not memorized labels#
Validate the approach before typing#
- Data structure
- Hash map
- Stored state
- value → index
- Algorithm
- Scan once; check whether the complement was already seen.
- Complexity
- O(n) time, O(n) auxiliary space
“Does that approach sound reasonable?”
Confirmation creates a natural checkpoint before ten minutes are spent implementing the wrong model.
Communicate decisions, not keystrokes#
- Assumptions and approach changes
- Data-structure choices and invariants
- Meaningful tradeoffs
- Bugs you notice and test reasoning
- “Now I'm typing a for loop.”
- “Now I'm adding one.”
- Every bracket or ordinary syntax choice
- A continuous stream that leaves no room to think
Short focused silence is normal. Ten to thirty seconds can be useful; give context before a longer pause so the collaboration does not disappear.
Step 4 - Write interview-friendly code#
- Choose clear names and keep the invariant locally understandable.
- Use standard-library structures you can explain confidently.
- Separate a complex operation when a helper improves reasoning.
- Handle edge cases deliberately instead of scattering patches.
- Avoid enterprise-style architecture and clever one-liners under time pressure.
d = {}
x = 0
a = nums[i]seen = {}
left = 0
current_sum = ...Conventional short names such as i, j, and n remain reasonable when their meaning is obvious.
Step 5 - Test deterministically#
- Walk through the provided example.
- Trace the variables that carry the invariant.
- Test one meaningful edge case.
- Verify the actual return value.
- Recheck loop boundaries and termination.
| i | value | complement | seen | action |
|---|---|---|---|---|
| 0 | 2 | 7 | {} | store 2 → 0 |
| 1 | 7 | 2 | {2: 0} | return pair |
Debug without restarting#
- Reproduce the failing input manually.
- Find the first state that differs from expectation.
- Fix the smallest responsible piece.
- Retest the original and failing cases.
If you're stuck#
Use a recovery ladder instead of waiting for inspiration or abandoning the solution.
- 1
Restate what you know
- 2
Work through a tiny example
- 3
Describe the simplest correct approach
- 4
Identify repeated or expensive work
- 5
Ask what information would make the next step easier
- 6
Consider the matching data structure or pattern
- 7
Incorporate the interviewer’s hint
Questions that can unlock the next step
- What is the expensive operation?
- Am I recomputing something I could store?
- Would sorting make the useful relationship visible?
- Is the answer a contiguous range?
- Can I model the states and transitions as a graph?
- Does this state depend on solutions to smaller states?
- Can I search a monotonic answer space instead of constructing the answer directly?
Use hints as new information#
Acknowledge the hint, explain how it changes your reasoning, and update the approach. Do not ignore it or pretend you had already reached the same conclusion.
When the approach is wrong#
Name the flaw, state why a local patch is insufficient, and present the revised approach. A visible correction is stronger than defending a broken invariant.
Step 6 - Analyze and adapt#
State time and auxiliary space in terms of the relevant inputs, then justify them with operations - not adjectives.
Common complexity traps
- Nested loops are not automatically O(n²); count how often each pointer or edge advances.
- Slicing and collection copies may cost O(k), even when the syntax looks constant-time.
- O(n log n) sorting dominates an O(n) scan that follows it.
- Recursive depth contributes to auxiliary space.
- Heap insertion and removal are O(log n), while peeking is O(1).
- Hash lookup is O(1) on average, not an unconditional worst-case guarantee.
- Repeated immutable-string rebuilding can add otherwise hidden work.
Review Python operation costs or review Java collection costs.
Handle follow-ups as controlled changes#
- Identify exactly what changed.
- Check whether the existing algorithm still works.
- Name the new bottleneck.
- Modify the smallest necessary component.
A flexible 45-minute pace#
- Understand + clarify
Restate the contract and ask solution-changing questions.
- Develop + validate
Baseline, bottleneck, optimized approach, confirmation.
- Implement
Write the core algorithm in reviewable steps.
- Test + debug
Trace one sample and one meaningful edge case.
- Analyze + follow up
State complexity and adapt to changed constraints.
When time is running out#
- State the remaining logic clearly.
- Finish the core algorithm before polishing.
- Avoid unnecessary refactors.
- Explain known edge cases if you cannot implement them in time.
A full interview walkthrough#
Original practice prompt: Given an array of integers and a target, determine whether two distinct values sum to the target.
- 01Clarify
We need to determine whether a pair exists. May values repeat, and may I use extra memory?
- 02Example
For [2, 7, 11, 15] and target 9, the first two values form a valid pair.
- 03Baseline
Compare every pair. It is correct, but costs O(n²) time.
- 04Bottleneck
For each value, the baseline repeatedly searches for its complement.
- 05Optimize
Store values already seen in a hash set and check each complement in average O(1) time.
- 06Confirm
A one-pass set gives O(n) expected time and O(n) space. Does that direction sound reasonable?
- 07Code
Scan once; check the complement before adding the current value so one element is not reused.
- 08Test
Trace 2, then 7. Also test an empty input and duplicate values when the target is twice that value.
- 09Analyze
O(n) expected time and O(n) auxiliary space.
- 10Follow-up
If the input is sorted, use two pointers for O(n) time and O(1) extra space.
Weak workflow vs strong workflow#
Read → immediately code → get stuck → silently rewrite → run out of time → guess complexity
Understand → clarify → baseline → optimize → confirm → code → test → analyze
Treat it like collaborative problem solving#
Coding interviews remain evaluative, but listening, acknowledging feedback, communicating meaningful decisions, and adapting to changed constraints make your reasoning easier to assess.
What not to do#
Interview-day mini checklist#
- Choose your strongest interview language.
- Prepare the environment if one is required.
- Remove distractions.
- Restate → clarify → baseline.
- Optimize → confirm → code.
- Test → complexity → follow-up.
- Use a tiny example.
- Identify repeated work.
- Revisit constraints.
- Explain what you know and use hints.