How to prepare for a software engineering interview when nobody agrees what one should be

You're probably preparing for one interview: a coding screen, a system design round, a behavioral conversation, and a hiring manager chat. That's a reasonable guess, and at plenty of companies it's exactly right. It's also the reason a lot of strong engineers get blindsided, because the people running these processes do not agree with each other about what an interview is for, and some of them think the standard loop barely works.

This article covers the disagreements that are on the record from senior engineering leaders, and how to figure out which kind of process you're in. It also covers what each round is really testing, and how your preparation changes if you're interviewing as an IC versus as an engineering manager. Read the first two sections before you build a study plan, because the plan changes a lot depending on the answer.

The people quoted here run or ran engineering at scale. Farhan Thawar is VP and head of engineering at Shopify, where he hired around a thousand interns in a single year. David Singleton was CTO of Stripe. Will Larson has been CTO or an engineering leader at Carta, Calm, and Digg, and ran engineering teams at Stripe and Uber. Camille Fournier wrote The Manager's Path and was CTO of Rent the Runway. Dhanji R. Prasanna is CTO of Block. Ronny Kohavi ran experimentation at Microsoft, Amazon, and Airbnb. Karri Saarinen co-founded Linear. Brendan Foody runs Mercor. Geoff Charles was VP of product at Ramp, and Nikhyl Singhal was VP of product at Meta and Google. Every quote plays the exact moment it was said.

The disagreement most guides skip

Generic interview guides assume one universal loop and treat it as a fixed thing you study for. That assumption breaks down fast once you listen to people who run hiring for large engineering organizations, because they openly contradict each other on the most basic question: can a few hours of interviews tell you whether someone will be good at the job?

One side: interviews barely predict anything, so make the interview into the work

Farhan Thawar runs engineering at Shopify and is blunt about it. He calls the weak link between interview performance and job performance a dirty little secret that everyone already knows and mostly ignores.

His answer is to move the evaluation as close to real work as he can get it. He tells a story about hiring two machine learning candidates at his startup: one was a PhD who taught at a university and came with an employee referral, the other was a guy he met at a coffee shop who had never held a software job. He deliberately didn't let the resumes bias him. He brought both in to pair program. Within a few weeks it was clear the PhD wasn't going to work out, and the coffee shop guy is still there years later at Shopify. Thawar's framing for why he does it this way:

In practice that means pair programming as an evaluation, internships and co-op programs treated as the real hiring funnel, and a serious 30, 60, and 90 day period after you start. He's explicit about the tradeoff, and it's a rough one for candidates to hear: at his previous company roughly 20% of hires left inside 90 days, and under 1% left after that. He argues that's better for everyone because a bad fit gets discovered in weeks instead of years. Whether you find that reassuring or alarming, it's worth knowing before you accept an offer from a company that hires this way.

The other side: a conversation can tell you plenty, if you dig hard enough

Geoff Charles, who was VP of product at Ramp during its fastest growth, describes something close to the opposite belief. He thinks a well-run interview conversation does reveal how someone thinks, as long as the interviewer refuses to stay at the surface.

Notice what he's doing. He picks one decision from your past and keeps asking about it until he either finds real reasoning underneath or finds nothing. That's a different test from watching you write code, and the people it screens out are different too. Someone who can implement anything but can't reconstruct why they chose an approach two years ago will do fine on a coding screen and have a hard time in this round.

The two camps do agree on one thing, which is that the years listed on your resume are worth less than most candidates assume. Charles says Ramp deliberately overweights hunger and depth of thinking "rather than necessarily experience." Thawar has an interview step called the life story, built around a line he heard from someone else: a resume tells you what you did, but it doesn't tell you why you did those things. He wants to know why you moved between companies and whether the pattern shows curiosity and range. So if your prep plan is a list of the systems you've shipped, you have half of what either of them wants.

Whether you're allowed to look things up

Here's a second disagreement, and it's the one most likely to catch you off guard during the interview itself. Some interviewers consider a question that hinges on recall to be a legitimate filter, and others consider it a defect in the process. David Singleton, then CTO of Stripe, is firmly in the second camp.

He adds that candidates are welcome to ask their interviewer questions as they work, and that the exercises are built to resemble problems Stripe genuinely has to solve. So in that loop, looking something up costs you nothing and asking a question may actively help you.

Now the other camp. Ronny Kohavi, who ran experimentation at Microsoft, Amazon, and Airbnb, describes a favorite technical question that works precisely because most people fail it.

You can hold whatever opinion you like about which of these is a better way to hire. As a candidate what matters is that both interviewers exist and you can't tell them apart from the job posting. The practical response is to brush up on the language-level details of whatever stack the role names, spend an hour on the parts you'd normally look up, and then in the interview itself ask early whether you can use a search engine or documentation. That one question tells you which kind of interviewer you have, and nobody gets penalized for asking it.

How to tell which process you're in

You can usually find out in one email, and asking costs you nothing. Recruiters answer this question happily, because a prepared candidate makes their job easier.

That last question does more work than it looks like it does. A company that runs the Thawar model will tell you about a structured 30, 60, and 90 day evaluation, sometimes with real consequences attached. A company that puts its weight on the interview itself tends to describe onboarding instead. Once you know which one you're facing, you can split your prep.

The rounds you'll typically see

Most loops draw from the same set of rounds, mixed in different proportions. What follows is what each one is actually testing, which is often not what the name suggests.

The coding screen

Usually 45 to 60 minutes, one or two problems, live with an interviewer or on a timed platform. Companies that use it are testing whether you can produce working code under mild pressure while explaining yourself. The most common way to fail it is to stay quiet while you work. If you solve it perfectly without narrating, the interviewer has no evidence about how you got there, and the write-up afterward will be thin. Say what you're considering before you type it.

System design

Typically 45 to 60 minutes on an open-ended prompt like designing a rate limiter or a notification service. The prompt is deliberately too big for the time available, which means the round is really about how you scope. Start by asking about scale, read and write patterns, and consistency requirements, then say which constraint you're optimizing for and why. Most candidates who struggle here are drawing boxes before they've decided what problem they're solving.

The pairing round

You work on a real or realistic problem alongside an engineer for an hour or more. This is Thawar's preferred format for a reason. It shows whether you're pleasant to solve problems with, whether you can accept a suggestion without arguing about it for ten minutes, and whether you can take the lead when the other person goes quiet. Treat your partner as a colleague rather than a judge, because that's what they're checking.

The take-home or work trial

Anything from a four-hour project to a paid week on the team's actual codebase. Two things matter. Scope the work to the time given and say what you cut, because a sprawling unfinished submission counts against you more than a small complete one with a note explaining the tradeoffs. And write the README as if a reviewer has fifteen minutes, since one usually does.

Linear runs the most demanding version of this, and Karri Saarinen's description of it tells you what the scoping actually counts for.

Note that Linear keeps a conventional interview loop and puts the trial at the end, which is a middle position between the two camps above. Saarinen also says almost nobody has declined the trial, and that they'll schedule it around a weekend or a holiday if you're employed. If you're offered one, negotiating the timing is normal, and so is asking to be paid for it.

Behavioral and hiring manager rounds

This is where Charles-style digging happens, and it's the round engineers most often underprepare. You need a handful of stories with real technical detail in them, and you need to be able to answer follow-ups about the decisions inside the story. The behavioral interview questions playbook covers the structure for those answers, and the organizing your thoughts before speaking playbook helps if you know the material but lose the thread when you say it out loud.

What AI changed, and what it didn't

This is the newest disagreement and the one most likely to affect your next loop. The question is whether an engineering interview should let you use AI tools, and whether being good with them is evidence that you're good at the job.

Brendan Foody runs Mercor, which builds talent assessments, and he takes the permissive position as far as it goes.

Dhanji R. Prasanna, CTO of Block, is experimenting with the same thing and is openly unconvinced that it measures what people hope it measures.

Elsewhere in that conversation Prasanna says Block does look for people who are embracing these tools, so he isn't arguing you should avoid them. His point is narrower and more useful to you: he treats AI fluency as a signal about your attitude and not as evidence of engineering judgment. That gives you a decent working rule for any AI-permitted round. Use the tools freely, and make sure a listener can hear you deciding things the tool didn't decide for you. Say why you accepted one suggestion and rejected another, what you checked before you trusted the output, and where you'd expect the generated approach to break. That's the part both camps agree they're buying.

One practical warning: ask whether AI use is allowed instead of assuming. Companies are still arguing about this. Some rounds are explicitly AI-permitted, and others still treat it as cheating.

Preparing as an IC versus as an engineering manager

Interviewers judge the two tracks on almost nothing in common, and the manager side has shifted more in the last few years than most candidates realize.

The engineering manager story that used to win

Will Larson has run engineering at Carta, Calm, and Digg, and led teams at Stripe and Uber. He describes how fast the ground moved under engineering managers when hiring slowed down.

If your EM pitch is built on the size of the team you grew and how many engineers you hired, you are telling a story from the previous era. Larson names what replaced it: leading the team, getting deeper into technical details, and working out the right size and shape for a team, including the times you consolidated a team or cut one. Prepare examples for all of that. He also describes the failure mode he sees inside hiring pipelines, where candidates pile up at the offer stage because hiring managers can't get to confidence on anyone. If a process goes quiet on you after a strong final round, that's often what's happening, and it's rarely about a single answer you gave.

The IC track is a real answer now, with a condition

For years the assumption was that advancing meant managing. Nikhyl Singhal, who was VP of product at Meta and Google, argues that assumption has quietly reversed, and he describes it in the exact terms of two candidates walking into an interview.

He's hard on the other candidate in that comparison, the one who managed two people early and can't say much about what got built. His diagnosis is that the industry promoted a lot of promising ICs into management before teaching them the job, and now their story doesn't hold up in an interview. Camille Fournier, who wrote the book most engineers read before making this decision, reaches the same conclusion from a different direction.

Asked for a number, Fournier puts real mastery somewhere around ten years of a career spent substantially writing code, counting an undergraduate and graduate degree in her own case. She also warns that when a big company praises your communication skills and suggests management, they're often steering you toward project management, which she considers a poor route to real leadership. And on the job itself: you don't own your time as a manager, and you own less of it the more senior you get. She describes management as a service job rather than a role where you make all the decisions.

These three agree more than they disagree, so it would be dishonest to stage a fight here. The genuine caveat comes from Larson, who points out that the senior IC track only works when a company is willing to hold engineers accountable the way it holds managers accountable.

That gives you something concrete to ask about. If a company offers a staff or principal track, ask how many people are currently at that level, what the most recent promotion into it looked like, and who owns the hardest technical problem in the organization right now. Vague answers tell you the track exists on a slide and not much else.

What to ask them back

Your questions are part of the evaluation, and at senior levels they can carry as much weight as your answers. Larson has stopped using his interview time to sort candidates and started using it to help them decide.

Have a real answer ready, because "I'm looking for the best opportunity" wastes the moment. Naming two or three things you're optimizing for lets a good interviewer tell you honestly whether they have them. Here are questions that get you information rather than a rehearsed pitch:

One more question worth borrowing from the other side of the table. Geoff Charles asks candidates what the hardest thing they've ever done was, and his reasoning tells you exactly what he does with the answer.

Charles scores four things in that answer: what counts as hard for you, why it was hard, how you worked with other people through it, and how much of it you drove yourself. A story where the difficulty was mostly other people's fault answers one of those four. Pick a story where you had real agency, and say what you personally decided.

Frequently asked questions

Should I still grind algorithm problems?

If the recruiter tells you there's a live coding screen, yes, enough to be fluent with the common patterns and comfortable talking while you solve. If the loop is pairing, a take-home, and conversations, that time is better spent rehearsing explanations of your past technical decisions. This is the whole reason to ask about the format first.

Is a take-home assignment a red flag?

Not on its own, though an unpaid multi-day project for a first-round screen is worth pushing back on. Ask how long they expect it to take and whether they'll pay for the time. A company that treats the take-home as a serious sample of your work usually respects the hours, and one that shrugs at the question is telling you something.

How do I prepare for a pairing interview?

Practice narrating while you code, with a friend or out loud alone. Get used to reading unfamiliar code and asking questions about it rather than guessing. And practice being interrupted mid-thought, because your pair will do it, and your pair will do it too, and they're watching how smoothly you recover.

Should I take a manager role to advance?

Fournier's advice is to wait until you've done enough hands-on work to have real mastery, and Singhal argues the senior IC path now interviews well on its own. Neither of them says management is a bad job. They both say taking it early, before you're technically deep and before anyone teaches you the role, produces a career story that falls apart under questioning a few years later.

Can I use AI tools during a technical interview?

Ask, because the answer genuinely varies right now. Some companies build the round around it and want to see what you produce in an hour with whatever tools you like. Others still treat the round as a test of unassisted reasoning. Where it's allowed, narrate the judgment calls you're making about the output, because that's what the interviewer is listening for.

What if I bombed one round?

Loops are usually scored as a set, and one weak round rarely decides it by itself. What does sink candidates is a weak round plus no recovery, so if you realize mid-interview that you went down the wrong path, say so and correct it out loud. That behavior is itself a positive signal. The final round playbook covers preparing for the panel as a whole.

How much does the company's brand matter on my side?

Less than the match between what you want and what the team has. That's Larson's point about asking candidates to name what they're optimizing for. If you can't say what you want out of the next role, you'll evaluate offers on compensation and logo, and those are the easiest two things to be wrong about. The positioning playbook helps you work out what you're actually selling and looking for.

The engineering interview checklist