Most interview prep starts in the wrong place: a list of the hundred most common questions. The job description is a better starting point. It tells you the level you're being hired at, the stack you'll be tested on, the problems the team is trying to solve, and often how the loop is structured. Read it carefully and you can spend your prep time on the rounds you'll actually face.
This guide shows how to turn a posting into a prep plan in about thirty minutes.
Step 1: Read the posting three times, for three things
Read it once for the level, once for the work, and once for the process. Trying to take in all three at once is how you miss the details that matter.
The level
Titles are inconsistent between companies, so look past them to the language:
- Scope words. "Own", "lead", "drive", "set direction", and "across teams" signal senior or staff expectations. "Contribute", "implement", and "with guidance" signal junior to mid-level.
- Years of experience. Treat it as a rough calibration, not a filter. It tells you what size of story the behavioral round will expect.
- Who you'd work with. "Partner with product and design" means you'll likely get a product or collaboration question. "Mentor engineers" means you'll be asked about mentoring.
The level decides how deep the system design round goes, how big your behavioral stories need to be, and whether a product-sense round is likely.
The work
Underline every technology, domain, and problem statement. Then sort them:
| Category | What to look for | How it shows up in the loop |
|---|---|---|
| Core stack | Languages, frameworks, databases named in the requirements | Live coding language, technical deep-dive topics |
| Domain | Payments, search, ads, infrastructure, healthcare | System design prompts, product questions |
| Current problems | "Scale our platform", "migrate to", "reduce latency" | Deep-dive and design questions, and "tell me about a time" prompts |
| Nice-to-haves | The "bonus" list | Rarely tested directly; useful in the recruiter screen |
A posting that says "you'll help us move from a monolith to services handling millions of events a day" is telling you what the system design round will be about.
The process
Many postings describe the loop outright: "a recruiter call, a technical screen, a take-home, and an onsite with four interviews." If yours doesn't, look for clues:
- "Pair with us" or "collaborative coding" points to live coding rather than a timed puzzle.
- "Take-home" or "work sample" means you'll need to build something and then defend it.
- Senior postings without a stated process almost always include system design and a behavioral round.
- Startups often add a founder conversation that mixes product sense and motivation.
Write down the rounds you expect, in order. That list is your prep plan.
Step 2: Map each round to what it's really testing
Every round has a surface task and an underlying test. Prepare for the underlying one.
- Recruiter screen. Surface: tell us about yourself. Underneath: can you explain your background and your reasons for this role clearly, and are there logistics that would block an offer?
- Live coding. Surface: solve the problem. Underneath: do you clarify, choose an approach for a reason, communicate while you work, and test your own code?
- Take-home. Surface: build the thing. Underneath: do you scope sensibly, write code someone else can read, and explain your tradeoffs in the review?
- Technical deep-dive. Surface: answer questions about fundamentals and past projects. Underneath: how deep does your understanding go, and how do you behave at the edge of it?
- System design. Surface: design a system. Underneath: can you scope an ambiguous problem, make estimates, and defend tradeoffs when the requirements change?
- Behavioral. Surface: tell me about a time. Underneath: what did you personally do, at what scope, and what did you learn?
- Salary negotiation. Surface: here's the offer. Underneath: can you hold a position calmly and ask for what you're worth?
Step 3: Turn the posting into specific practice
Generic prep is better than nothing. Specific prep is much better. For each round on your list, write one or two practice prompts drawn from the posting itself.
Example. A posting for a senior backend engineer on a payments team mentions Go, Postgres, Kafka, "exactly-once processing", and "on-call rotation". A reasonable plan:
- Recruiter screen: a 90-second background that ends with why payments, and why now.
- Live coding (Go): problems involving concurrency and maps, practised in Go rather than your most comfortable language.
- System design: design an idempotent payment ledger; design a webhook delivery system with retries.
- Technical deep-dive: Postgres isolation levels and locking; Kafka delivery semantics and consumer groups.
- Behavioral: an incident you handled on call; a time you pushed back on a risky launch.
- Negotiation: a counter-offer that includes level and sign-on, not just base salary.
That plan takes five minutes to write and is far more useful than a generic question list.
Step 4: Practise out loud, against pushback
Reading answers builds recognition. Interviews test recall and reasoning under pressure, which you only build by doing. Three rules make practice count:
- Say it out loud. Explaining while you think is a separate skill from thinking. If you practise silently, the interview is the first time you've done both at once.
- Get interrupted. Real interviewers ask follow-ups, change constraints, and question your assumptions. Practise with someone (or something) that does the same.
- Rerun what went badly. The second attempt at a round you fumbled teaches you more than a first attempt at a new one.
Step 5: Prepare questions that prove you read the posting
At the end of every round you'll be asked what questions you have. Use the posting:
- "The posting mentions moving to event-driven processing. Where is the team on that today?"
- "What does on-call look like for this team, and what's changed about it recently?"
- "What would you want someone in this role to have done in their first ninety days?"
Questions like these show you paid attention, and the answers tell you whether you want the job.
A checklist you can reuse
- Level identified from scope words, not just the title
- Core stack, domain, and current problems listed
- Expected rounds written down in order
- One or two posting-specific practice prompts per round
- Each round practised out loud at least once, with follow-ups
- Weakest round rerun
- Three questions for your interviewers, drawn from the posting
Hardmode automates the first half of this: add your CV, paste a job link, and it reads both, identifies the level and stack, and builds an interview plan you can practise round by round, with an interviewer that asks about your actual experience. The second half, the reps, is still up to you.