Interview playbook
Knowing the material is half of it. The other half is running the round: using the time well, thinking out loud, and giving the interviewer the signals they are scoring. This page covers the four rounds most software engineering interview loops have.
DSA / coding round (45–60 min)
Typical plan for one problem in 45 minutes
| Minutes | Do this |
|---|---|
| 0–5 | Restate the problem, ask about input size and edge cases, write 2 examples |
| 5–12 | Say the brute force and its complexity, then the better idea. Get agreement before coding |
| 12–35 | Write clean code, talking as you go |
| 35–42 | Dry-run an example line by line; fix bugs calmly |
| 42–45 | State final time and space complexity; mention one improvement |
What gets scored: problem solving, code quality, communication, testing your own code.
Phrases that help
- "Let me start with the brute force so we have a baseline: that's O(n²)."
- "The bottleneck is the repeated lookup, so a hash map should take it to O(n)."
- "Before I code: does that approach sound good to you?"
Common mistakes: coding in silence; jumping to code without examples; never testing; giving up on DP instead of writing the recurrence out loud first.
Machine coding / LLD round (90–120 min)
| Minutes (of 90) | Do this |
|---|---|
| 0–5 | Clarify requirements; write down assumptions |
| 5–15 | List entities and the interfaces (the parts likely to change) |
| 15–65 | Write the core flow first, so it runs early |
| 65–80 | A small main or tests; handle errors |
| 80–90 | Extensions, concurrency, and how you'd scale it |
What gets scored: working code, sensible classes, extensibility (can a new rule be added without edits everywhere?), readability, handling edge cases.
Tips
- Working beats perfect. A running, simple design scores higher than a beautiful one that doesn't compile.
- Put changing rules (pricing, allocation, scheduling) behind interfaces: that is the "extensibility" signal.
- Keep names boring and clear. No clever one-liners.
System design / HLD round (45–60 min)
| Minutes (of 45) | Do this |
|---|---|
| 0–5 | Functional and non-functional requirements; agree on scope |
| 5–10 | Estimates: QPS, storage, and the one number that drives the design |
| 10–17 | API and data model |
| 17–30 | High-level architecture: draw the boxes, walk one request end to end |
| 30–42 | Deep dives: the bottleneck, failures, consistency, hot keys |
| 42–45 | Summarise trade-offs and what you'd do next |
What gets scored: structured approach, sound trade-offs (and saying them), depth in at least one area, handling failures, reasonable numbers.
Phrases that help
- "Given ~40k reads a second and a 100:1 read ratio, I'll cache the hot keys and keep the write path separate."
- "The trade-off here is consistency versus latency; for this feature, stale-by-a-second is fine because…"
- "What happens if this component dies? Let me walk through it."
Common mistakes: drawing boxes without explaining why; no numbers; going wide and never deep; ignoring failures; not checking in with the interviewer.
Behavioral / hiring manager round (45 min)
- Prepare 6–8 real stories that cover: a hard technical problem, a conflict, a failure, leading without authority, a tight deadline, improving a process.
- Tell each in STAR form (Situation, Task, Action, Result) in about 2 minutes, with numbers in the result ("cut p99 latency from 800 ms to 120 ms").
- Say "I", not "we", for your part.
- Have two good questions ready for them about the team and how success is measured.
The week before
- Do two timed mocks per round type using the timer on each chapter.
- Re-solve 10 DSA problems you've already done, from a blank page.
- Pick 3 HLD chapters and explain each out loud, start to finish, in 30 minutes.
- Sleep. A tired brain loses more points than one missing topic.