Coding Prep
Run a Coding Interview
A concise protocol for clarifying, planning, building, testing, and explaining a coding solution under interview pressure.
Interview coding is a conversation under a clock. Your job is not to produce perfect code in silence. It is to make sound decisions visible: establish the rules, state a plan, build the smallest useful version, and test the risks.
The same loop works for a practical build and an algorithmic problem. The details change after the plan, not before it.
Run this loop every time
| Move | What to do | What the interviewer learns |
|---|---|---|
| Clarify | Restate the problem, constraints, available tools, and what a complete answer means. | You do not build on unstated assumptions. |
| Ground | Walk one normal input and one edge case before proposing a solution. | You understand the behavior, not just the keywords. |
| Plan | Name the data, operations, and complexity target before opening the editor. | You can make trade-offs deliberately. |
| Build | Ship the smallest working path, run it, then add the next requirement. | You can make progress without over-designing. |
| Verify | Test the cases most likely to break your approach and narrate the result. | You can find and explain risk. |
Spend the first minute well
Ask only questions that change the solution. Good defaults are:
- What input sizes and latency expectations matter?
- What behavior should happen for empty, duplicate, invalid, or missing input?
- Can I run code, use the standard library, documentation, or an AI tool?
- Is a clean baseline enough first, or should we optimize before implementation?
Then say the decision you made. For example: "I will treat duplicate events as idempotent, keep the latest value by key, and test that update before adding expiry." A stated assumption can be corrected. A silent one becomes a bug.
Practical build rounds
Practical prompts add requirements in phases. Do not design the final system in minute one. Design a base that can accept the next likely change.
Build a thin vertical slice
Name the core state, expose one operation, and run one assertion before you broaden the API. A passing slice is a platform for the next phase. An elegant abstraction with no working path is not.
For a small account tracker, that means deciding the key and value shape,
implementing credit(account_id, amount), and verifying one balance before
adding transfers, expiration, or reporting.
Preserve the decisions that matter
Before each new phase, say what changes and what stays stable. If expiry arrives,
the store may change from value to (value, expiry), while the public read
method stays the same. This is where a simple first version earns its keep.
Keep the conversation attached to the code
Narrate the boundary, not every keystroke: "The write path updates both indexes; now I am checking that the read path sees the same state." If you are blocked, state the hypothesis and run the smallest check that can disprove it.
Algorithmic rounds
Algorithmic prompts reward a precise route from constraints to a pattern.
State the baseline before the optimization
Give the straightforward approach and its time and space cost. Then name the bottleneck and the data structure that removes it. This makes the optimized solution easy to follow and gives you a safe fallback if time gets tight.
For Two Sum: "Checking every pair is quadratic. A value-to-index map turns the second lookup into constant time, so one pass is linear time and linear space."
Use examples to protect the invariant
Trace a normal case, then the boundary that threatens the approach: duplicate values, an empty collection, a one-item input, a negative value, or a window at its limit. Explain what must remain true at each loop iteration before coding.
Finish with a deliberate test order
- The ordinary case from the prompt.
- The boundary case that could invalidate an assumption.
- The input where the optimized approach avoids the baseline bottleneck.
Use AI as a tool, not a substitute
Tool policy belongs to the interviewer and company. Ask before using an AI assistant, then keep ownership of the solution: plan first, delegate a bounded task, read the output, run it, and explain what you accepted or changed.
Useful prompts ask for a counterexample, an edge-case checklist, or a small helper after you have chosen the design. "Solve the whole problem" removes the reasoning the interview is meant to evaluate.
Run an honest rep
Choose one unfamiliar prompt, set a timer, and keep the interviewer in the loop. Afterwards, record one failure in the process, not just whether you finished: unclear requirements, slow pattern recognition, unstable state shape, or missing tests. Use that diagnosis to select the next challenge.
- Start a coding mock - practice the conversation, implementation, and feedback loop with AI.
- Browse practical challenges - build and run phased implementations in the browser.
- Use the Solution Shape Atlas - identify the practical build shape before the timer starts.
Done reading? Mark it so it sticks in your dashboard.