How to prepare for a tech interview from the job description

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, how to compare it with your own background, and how to spread the preparation over the time you have.

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 behavioural 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 behavioural stories need to be, and whether a product-sense round is likely.

The work

Underline every technology, domain, and problem statement. Then sort them:

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 behavioural 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.

When the posting says very little

Some postings are three bullet points and a benefits list. You can still work out a fair amount:

• The company's engineering blog, talks, and open-source code show the stack and the problems they write about.
• The product itself tells you the domain. Use it for twenty minutes and note what looks hard to build.
• Other postings from the same company often describe the same loop, and sometimes the team's current work, in more detail.
• The recruiter. It's normal to ask on the first call what the stages are and what each one covers. Most recruiters will tell you.

Where you're still guessing, prepare for the common shape: a recruiter screen, a coding round, a design round for mid-level and above, and a behavioural round.

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? Our 45-minute system design framework breaks this round down phase by phase.
• Behavioural. 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: Compare the posting with your background

The posting describes the person they want. Your CV describes the person you are. The interviewers will notice where the two differ, so notice it first.

Make two short lists:

• Overlaps. Requirements you meet with a concrete project. These are your strongest stories: lead with them in the recruiter screen, and prepare to go three levels deep on them in the technical deep-dive.
• Gaps. Requirements you don't obviously meet. For each one, decide how you'll handle it: an adjacent experience ("I haven't used Kafka, but I built a queue-backed pipeline on a database table, and here's what I'd expect to change"), some focused study before the interview, or an honest "not yet, and here's how I'd get up to speed".

A gap you've thought about reads very differently from one you're surprised by. The questions about it will come either way.

Step 4: 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:

1. Recruiter screen: a 90-second background that ends with why payments, and why now.
2. Live coding (Go): problems involving concurrency and maps, practised in Go rather than your most comfortable language.
3. System design: design an idempotent payment ledger; design a webhook delivery system with retries.
4. Technical deep-dive: Postgres isolation levels and locking; Kafka delivery semantics and consumer groups.
5. Behavioural: an incident you handled on call; a time you pushed back on a risky launch.
6. 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 5: Spread it over the time you have

Interviews rarely come with as much notice as you'd like. Fit the plan to the calendar rather than the other way round.

• A few days. Prepare the recruiter screen story, one design prompt from the posting, and your two strongest behavioural stories. Practise each out loud once. Skip anything you can't rehearse.
• One to two weeks. Work through every round on your list, one or two a day, starting with the earliest in the loop. Rerun the weakest round at the end of the first week.
• Three weeks or more. Add the study the gaps call for, run each round more than once, and do at least one full-length practice of every round you expect, timed.

In every case, practise in the order of the loop. The recruiter screen comes first and decides whether the rest happens.

Step 6: 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 7: 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
• Overlaps and gaps with your background listed, with a plan for each gap
• One or two posting-specific practice prompts per round
• A schedule that fits the time before the first interview
• 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.

Updated 21 October 2026