Interview preparation

Eight weeks to ready.

A week-by-week plan that interleaves DSA patterns with design, a playbook for every round you'll face, and the frameworks to use in the room. Finish each week with a mock interview.

The plan

~10 hours a week, in order.

WeekDSA patternsDesignGoal

Week 1

Arrays & strings

LLD: OOP + SOLID15 problems. Say the pattern out loud before you code.

Week 2

Search & stacks

HLD: foundations + estimation15 problems + one back-of-envelope per day.

Week 3

Lists, heaps, greedy

LLD: creational + structural patterns15 problems + design Parking Lot, LRU Cache.

Week 4

Trees

HLD: caching, databases, sharding15 problems + design URL Shortener.

Week 5

Graphs

LLD: behavioural patterns + concurrency15 problems + design Elevator, Rate Limiter.

Week 6

Backtracking & DP

HLD: queues, consistency, reliability15 problems + design Chat, News Feed.

Week 7

Mixed & timed

Problem bank, mixedHLD: advanced + 3 full design problems2 timed problems/day from the bank, unseen. 3 mock interviews.

Week 8

Mocks & polish

Problem bank, mixedBehavioural story bank + AI system design1 mock per day across round types. Fix the weakest area only.

In the coding round

Clarify before you code.

The most common way strong engineers fail: they start typing in minute two, solve a slightly different problem, and run out of time fixing it. Six steps, every time.

  1. 01

    Clarify

    Restate the problem. Ask about input size, ranges, duplicates, negatives, empty input, and what to return when there's no answer. Write 2 examples, including one edge case.

  2. 02

    Match

    Name the brute force and its cost. Then scan for cues: sorted? contiguous? 'next greater'? dependencies? Name the pattern and why it fits.

  3. 03

    Plan

    Say the algorithm in 3–5 plain sentences and its target complexity. Get a nod before you type.

  4. 04

    Implement

    Write clean code with good names. Narrate decisions, not keystrokes. Leave helper functions for later if they're obvious.

  5. 05

    Review

    Dry-run on your small example, then the edge case. Fix bugs out loud — catching your own bug is a positive signal.

  6. 06

    Evaluate

    State time and space. Offer one follow-up improvement or trade-off unprompted.

Self-check after every practice problem

  • Pinned down inputs, outputs and edge cases before writing code
  • Said the brute force and its complexity first
  • Named the pattern and why it applies
  • Dry-ran the code on an example without being asked
  • Stated final time and space complexity
  • Kept talking — no silent stretches over a minute

Round by round

Know what each round is scoring.

Phone screen

One or two medium problems in ~45 min, often in a shared editor with no autocomplete.

What they're scoring

Can you get to working code quickly and talk while you do it?

How to prepare

  • Drill Easy/Medium from the first 8 patterns until each takes under 20 minutes.
  • Practise typing in a plain editor — no LSP, no run button.
  • Have a 60-second 'tell me about yourself' that ends on what you want next.
Mock a phone screen round

Coding (DSA)

1–2 problems, usually Medium with a Hard follow-up. Expect to discuss complexity and test your own code.

What they're scoring

Problem decomposition, pattern recognition, clean code, and testing without being told to.

How to prepare

  • Use the framework below on every practice problem, not just in mocks.
  • Always state brute force first, then improve — interviewers want to see the jump.
  • Dry-run your code on a tiny input before saying 'done'.
Mock a coding (dsa) round

Low-level design

Model a system in classes (Parking Lot, Splitwise, Elevator) and write key parts in ~45–60 min.

What they're scoring

Clean abstractions, SOLID, sensible patterns, extensibility, and concurrency awareness.

How to prepare

  • Clarify requirements and list entities before drawing anything.
  • Name the pattern and why ('Strategy, because pricing rules change').
  • Close with how you'd extend it — new vehicle type, new payment method.
Mock a low-level design round

System design

Design a large-scale service (feed, chat, payments) in 45–60 min. Senior bars expect you to drive.

What they're scoring

Requirements discipline, estimation, sound high-level design, depth on 2–3 hard parts, explicit trade-offs.

How to prepare

  • Time-box: 5 min requirements, 5 estimates, 10 high-level, 20 deep dives, 5 wrap-up.
  • Pick deep dives yourself — the hardest part, not the easiest.
  • Every choice gets a 'because' and a 'the cost is…'.
Mock a system design round

Behavioural

Stories about conflict, failure, leadership, ambiguity and impact. Often a 'bar raiser' round.

What they're scoring

Ownership, judgement, scope and self-awareness — at the level you're interviewing for.

How to prepare

  • Build a story bank: 8–10 stories, each tagged with the themes it can answer.
  • Use STAR, but spend 60% of the time on Action and quantified Result.
  • Say 'I', not 'we', when describing what you did.
Mock a behavioural round

Hiring manager

Past projects in depth, how you work, why this team, what you want next.

What they're scoring

Fit, motivation, and whether your experience matches the scope of the role.

How to prepare

  • Pick 2 projects you can go 5 levels deep on — design, trade-offs, numbers, mistakes.
  • Research the team's product and have 3 real questions.
  • Be clear about the level and scope you're targeting.
Mock a hiring manager round

Behavioural

STAR, weighted.

Situation
10%
One or two sentences of context. Team, stakes, constraint.
Task
10%
What you specifically owned. Not the team's goal — yours.
Action
50%
The decisions you made and why, including the options you rejected.
Result
30%
A number if possible (latency, revenue, incidents, time saved) and what you learned.

Story bank

Have one ready for each.

  • A project you led end to end
  • A production incident you owned
  • A disagreement with a senior / manager
  • A time you were wrong
  • Delivering under an impossible deadline
  • Mentoring or unblocking someone
  • Pushing back on a requirement
  • Ambiguous problem, no clear owner
  • A trade-off you'd make differently now
  • Your biggest measurable impact