The Interview Prep Path

STEP 01

Build the projects that actually get you interviews

Before you can prep for interviews, you need interviews lined up to prep for. The fastest way there usually isn't another tutorial clone - it's building something that fixes a real, specific annoyance, ideally your own.

Pick a project like this

• "Solving a problem for someone" and "building something that interests you" are the same thing, if you do it right. Find something genuinely annoying in your own workflow - there are always other people with that exact same problem.
• One engineer wanted daily reps at system design and noticed there was no easy way to practice it every day - so they built a small app around exactly that gap. The project came from a personal itch, not a spec sheet.
• Don't treat "solves a real problem" and "has real engineering depth" as a tradeoff you have to pick between - the strongest projects are usually both at once.
• Want distributed-systems depth for a fintech or infra track? Anchor it in a domain you already care about instead of a generic tutorial clone - it reads as far more genuine in an interview, and you'll actually enjoy building it.
• Ship it publicly, even if it's small. A live link, a public repo, or a short post on X does more for a startup application than a private folder ever will - see Step 3 for exactly why that matters at earlier-stage companies.

STEP 02

Document your work before you need it

This is the step everyone skips and then regrets in the room. Resume bullets and behavioral answers both come from the same well: things you actually did. If you don't log them when they happen, you will not remember them three months later when a recruiter asks.

Keep a brag sheet

• Keep one running doc. Any time you ship something, fix something hard, or handle an on-call incident, write a few lines the same day.
• Save the receipts, not just the summary - screenshots or quotes if someone senior praised the work, the PR link, and any usage or retention numbers from the first few weeks.

The formula that turns a task into a resume line

Every strong bullet point and every strong behavioral answer follows the same underlying shape. A useful way to frame it is the XYZ formula:

Fill in a concrete outcome for X, a real number or metric for Y, and the specific action you took for Z. A vague line like "worked on backend features" has no X, Y, or Z in it - that's exactly why it doesn't land.

If your resume gets zero replies

Having the right experience and having a resume that reads that way are two different problems. A common pattern: someone has genuinely strong, relevant experience for nearly every role they apply to, but gets almost no responses - because the bullets describe duties instead of outcomes. The fix is the same formula, applied without mercy to every line:

• When it's time to actually write or update your resume, feed your whole brag-sheet doc - plus standup notes, ticket summaries, playbooks, and scripts - to an AI assistant, alongside the specific job descriptions you're targeting, and ask it to surface what's genuinely relevant per role.
• Treat the first draft as a draft. One engineer used this process to get their resume "good enough" for a first pass, then planned a second revision after a few real interviews showed which parts of their background actually kept coming up.

Where behavioral stories actually come from

A lot of people freeze on behavioral questions not because they lack good stories, but because they're trying to invent the perfect answer cold, live, in the room. Two things make this much easier:

• Read a handful of common behavioral questions before the interview, and match each one to a real memory from your brag sheet. This turns the round into recall, not invention.
• Look for opportunities to put yourself into situations at work worth remembering in the first place - volunteering for the on-call incident, the cross-team escalation, the awkward pushback conversation. The story-finding gets easier once there are more real stories to find.
• If you haven't interviewed in years because you took an early offer and stayed, that's not a weakness to hide - it's just rust. The skill of narrating your own work out loud comes back with a few rounds of practice, the same as anything else.

STEP 03

Know what kind of process you're walking into

"Interview prep" means something different depending on where you're applying. Figure out which lane you're in before you decide what to study.

Big tech: the full loop, start to finish

Experienced candidates consistently describe the same core structure for this online assessment:

• Coding, part A - one traditional data-structures problem (medium difficulty; passing every test still takes real time).
• Coding, part B - an "AI coding assistant" round: you're dropped into an existing codebase (your choice of Node/MERN, Python/Django, or Java/Spring Boot) with a few broken tests, and you fix them with an assistant that can guide you but won't write the fix for you. Read every failing test first, then ask the assistant which files or routes each one touches before changing anything. The assistant will help with syntax and direction, but it won't hand you the whole solution.
• Work simulation - a straightforward debugging exercise.
• Work style survey - answer through the lens of the company's published leadership principles, not your own instincts. Read them beforehand.

Heads up: the coding portion alone can run 90 minutes. Experienced candidates note that the survey questions become harder to answer thoughtfully once fatigue sets in - pace yourself, or take the assessment when you're fresh.

And regardless of company: assume a human reviews your OA code if you advance. Clean variable names and standard conventions matter even when every test passes.

Passing the OA isn't the finish line - it's the entry ticket to the actual loop. Experienced candidates commonly encounter a sequence of focused one-hour interviews. Expect that final loop to mix coding, system design, and behavioral rounds, with the exact combination varying by team. Treat a strong OA as the start of prep, not the end of it.

Study in the order you're actually failing

• Not getting the OA at all? The problem is upstream - fix your resume and personal projects first, not your algorithms.
• Failing the OA itself? That's a straightforward signal to grind coding fundamentals.
• Failing the coding round? Add communication practice on top of the algorithms - panels are also grading how you talk through a problem.
• Failing system design? That's the one worth over-investing in anyway - of every round in the loop, it's also the most directly useful once you're actually on the job.

This isn't just an early-career footnote either: several new grads independently noticed the same shift - interviews at every level are drifting away from pure algorithm grinding and toward system design, even for entry-level roles. Treat Step 4 as worth your time regardless of title.

Startups: expect anything

Hiring here is reputation-driven - a warm intro or visible public work (posted on X, a live project) carries more weight than it would at a big company. The process itself depends on stage:

• Past Series B, expect something close to a standard loop: coding, system design, hiring manager conversation.
• Earlier than that, it can be an AI-assisted coding round, a take-home project, a week-long paid trial, or just a conversation over coffee.
• Pick carefully. A company that just raised usually has cash and real urgency to hire. A process that feels shady or chaotic is usually a preview of the job itself - do due diligence on the founder and talk to current employees before you join.

AI Engineering: SWE plus one extra layer

The core bar barely changes - solid coding (Python and TypeScript come up most) and the same system design fundamentals like containerization and scaling. What's added is a specific skill most SWE interviews never touch: designing retrieval-augmented generation systems and agent harnesses. By one estimate, roughly 85% of current AI engineering job descriptions are centered specifically on RAG - chunking, embeddings, vector search, evaluation - not "AI" in the abstract. If you're prepping for this track, that's where to spend your study time.

STEP 04

System design: know how deep to go

A common early mistake is either staying too abstract everywhere, or trying to memorize every database's internals. Neither is what's actually being tested.

A simple, high-level design - client → load balancer → stateless servers → a primary NoSQL store with async replication - is a fine starting point. You generally don't need to name a specific product like Cassandra or MongoDB everywhere in the diagram. What you do need is the ability to go deep in one area when the interviewer pushes - and that area is very often the database layer. If that's where they lean in, you should be able to explain how the actual engine behaves, not just its category.

• Pick one component of your design ahead of time that you could explain at an implementation level - most people choose the datastore.
• It's fine to stay conceptual everywhere else in the diagram.
• If asked "which specific technology," treat it as an invitation to go deep, not a trick question.
• If you genuinely understand the high-level concepts, the low-level specifics tend to follow naturally when you're pushed - so don't panic-memorize database internals in isolation. Understand the tradeoffs first, then let specific products slot into that understanding.

STEP 05

Technical & incident-response rounds

These rounds reward two things equally: getting the architecture right, and being honest about what you don't know. Below are two real technical rounds, broken into what worked and what didn't - read them as templates for your own answers, not just stories.

STEP 06

Behavioral & culture-fit rounds

These rounds are less about your resume and more about whether the people in the room want you on their team.

• Before a final round with a hiring manager or product lead, actually use the company's product and understand how it works - don't rely on the marketing page.
• Come in with real opinions, ideally ones that line up with the company's stated values. A neutral answer reads as no answer.
• If you're interviewing at a very early-stage startup and feel underqualified on paper, remember: if they're already talking to you, they've seen your resume and don't care as much as you think. At that stage, mindset and fit outweigh a clean technical background - see the case study in Step 3.

This carries past the interview, too: one engineer describes a fairly average project during their internship, but real, deliberate effort spent getting to know their manager as a person - which turned into a return offer and a fast promotion once they joined full-time. Spend the first few minutes of every 1:1 on life outside work, not just status updates. The relationships you build often matter as much as the work itself.

STEP 07

Talk money: from the recruiter screen to the signed offer

Money conversations start earlier than most people expect, and this is the last step people rush through because they're relieved to be done. Slow down at both ends.

When a recruiter asks for a number too early

You're not obligated to hand over a precise figure before you've even started interviewing. A few ways to buy room without stonewalling the conversation:

• Ask about the role's level, location, and scope first - you genuinely can't give a fair number without that context, and saying so is true, not just a dodge.
• Pre-research a realistic band across a few comparable companies - public bands and salary data are more available than most people assume - and quote the top of that band, leaving room to negotiate down from there.
• If a company's published band doesn't reach where you need to be, it's fine to say so upfront - it saves everyone the rest of the process.
• For companies you already know pay well, come with a specific reason you deserve the top of the band: your current comp, hard-to-find experience, or a promotion you're already on track for that you need reflected in the offer.

Negotiate before you sign

You need a real basis for asking, not just nerve. In rough order of strength:

• A competing offer - hardest to get, but the strongest card at the table.
• A genuine willingness to walk - e.g. cost-of-living or family costs that need to be reflected in the number.
• Your trajectory where you are now - "I'm on track for a promotion in six months that gets me to $X; I need to start there."

If the salary itself is capped by band, negotiate the rest: extra PTO, a bigger sign-on bonus, more equity.

• Don't talk yourself out of asking. By this point the company has already spent real time and money on the process - restarting a search can cost them far more than your ask.
• Never accept a verbal offer. Ask for everything in writing first - base, healthcare, 401k match, sign-on, equity - and negotiate against the written version, not the excitement of the phone call.

BONUS

Try these yourself

Six real pre-screening questions from a SpaceX phone call, asked back-to-back with no warm-up - the recruiter called fifteen minutes late into a thirty-minute slot and went straight into them. Good practice material regardless of where you're interviewing - they test reasoning under pressure more than memorized facts.

• Q1 · Codebase inspectionYou inherit a complex, safety-critical Python codebase. What are the first three things you'd check, and why?
• Q2 · Build systemsWhat's the most frustrating build-system failure you've had to fix, and how did you make sure it didn't happen again?
• Q3 · Virtualization vs. containersWhen would you reach for a VM (QEMU, KVM) instead of a container (Docker, Kubernetes) - give a concrete example.
• Q4 · Data modelingDescribe a data modeling decision - yours or inherited - that caused performance problems. What changed, and what was the lesson?
• Q5 · Network designYou've just been dropped on Mars and need to design a basic, reliable comms network for a small colony with limited contact to Earth. Where do you start, and what core technologies do you reach for?
• Q6 · ObservabilityHow would you design observability for a essential production service you didn't build, so the team can quickly tell if it's healthy?

Even a candidate who found this tough noted the recruiter was likely filtering hard given volume - plenty of people never get "interview ready" for a screen this fast-paced. If these six trip you up, that's normal, not a red flag. Practice out loud a few times and revisit them.