Skip to main content

How to Answer Any Coding Interview Question

Below is a clear, end-to-end flow you can follow in a live coding interview. Every bullet is intentionally more detailed so you can read it once and know exactly what to do in the room.

Before you join (5–10 minutes)

Decide your “default toolkit.” Know which data structures and templates you can implement fast: sliding window skeleton, DFS/BFS stubs, binary search, two-pointer pattern, hash maps, min/max heaps, and a quick union-find. Having these in mind shortens your ramp-up time.

Set your mental baseline. You’re not expected to be perfect. Decide ahead of time what you’ll do if you get stuck for more than 2 minutes:

  1. Restate the subproblem in your own words.
  2. Try solving a smaller example.
  3. Ask the interviewer for a focused hint.

Kickoff script (1–3 minutes)

Restate the problem in your own words. Read the problem out aloud, whether it appears written in the editor or is given verbally, and then summarize the input, output, constraints, and "correctness". This catches misreads early and shows strong communication.

Clarify constraints and edge cases. Ask for max sizes (n, m, value ranges), whether input can be empty/negative/duplicate, and whether you can mutate inputs. Confirm time/space expectations (e.g., “Is O(n log n) acceptable?”).

Lock down examples. Propose one base example and one tricky edge case. Confirm the expected outputs. These will be your “truth set” for later dry runs.

Declare a plan. “I’ll start with a straightforward approach to get correctness, then we can discuss optimizing to X complexity if time permits.” This frames your path and reassures the interviewer that you’re methodical.

Structure your thinking (2–4 minutes)

Identify the pattern. Is this sliding window, greedy, graph traversal, backtracking, binary search on answer, DP, or tree/heap manipulation? Naming the category helps you pick the right tools quickly.

Choose a baseline solution. Start with the most obvious correct approach (even if O(n²)). Mention its complexity and why it’s correct. This creates a foundation that you can optimize from.

State the invariants. What stays true throughout? For example, “the window never contains duplicates,” “the heap top is the next smallest,” or “the DP state dp[i] represents …”. Invariants anchor your code and your explanation.

Implementation (12–18 minutes)

Narrate as you code. Explain variable names and each block’s intent. Write guard clauses early to avoid null/empty issues. Keep functions short (e.g., neighbors(), is_valid(), expand_center()).

Code for readability first. Favor clear loops and descriptive names over clever one-liners. Add minimal comments where intent isn’t obvious. If you must choose, choose understandability over micro-optimizations.

Keep state changes explicit. For pointers and indices, state the invariant before modifying them. For recursion, say what the call returns and what post-conditions you rely on when unwinding.

Be intentional with data structures. If you choose a map over a set, tell them why. If you need a heap, say what the key is and how it supports the algorithm’s invariant.

Testing, verification & debugging (5–8 minutes)

Dry run on agreed examples. Walk through line by line, updating the variables aloud. Confirm that outputs match expectations. This is where many subtle off-by-one or boundary bugs surface.

Explain correctness. Tie your dry run to the invariant or recurrence. For two pointers: “The window expands until invalid, then shrinks to restore validity.” For DP: “Each state uses only solved subproblems.”

Fix quickly and cleanly. If a bug shows up, say what you expected vs. observed, propose a small fix, and re-run the example. Don’t panic or rewrite everything—patch, verify, move on.

Re-state complexity. “Time is O(n log n) due to the heap operations; space is O(n) for the map. If needed, we can reduce space by …”

Optimization (optional, 5–7 minutes)

Identify the bottleneck. Is it sorting, nested loops, or a heavy data structure? Name it and quantify it. “The O(n²) step is this intersection check; a hash set can reduce it to O(n).”

Propose the next idea. For example: two-pointer after sorting, a monotonic stack for next greater, binary search on answer for feasibility problems, prefix sums to turn O(n²) into O(n).

Discuss trade-offs. “Approach A is simpler and robust; Approach B is faster but more complex to implement and reason about.” Interviewers value this judgment.

If you get stuck: A 3-step rescue

Shrink the problem. Use a tiny input to expose where the logic breaks. Replace complex data with a minimal “witness” that triggers the bug.

Probe a hypothesis. Add a quick print or assert (if allowed) to confirm/refute your assumption about state transitions or DS contents.

Ask a targeted hint. “I’m debating between a heap and a two-pointer strategy because the constraint X might make two-pointer infeasible. Which direction would you prefer I explore?”

Common pitfalls

  • Silent coding. Fix: Narrate intent before each block and after key steps.
  • Skipping constraints. Fix: Ask for n, ranges, memory limits up front.
  • Not testing edges. Fix: Always run your solution mentally on empty, single-item, max size, duplicates, negatives, and degenerate shapes.
  • Premature optimization. Fix: Get a correct baseline first, then refine.
  • Messy state handling. Fix: State the invariant aloud and write guard clauses early.

Final thoughts

Your interviewers are evaluating how you think as much as what you code. Make your reasoning visible, be systematic about testing, and show judgment when choosing trade-offs. If you keep the flow above, you’ll come across as clear, calm, and capable exactly what they’re hoping to see.

Next Lesson