Key takeaways
Sierra deleted the coding interview. In an April 2026 post on the company's own blog, the three authors described removing the coding and algorithms rounds from the engineering loop and replacing them with an onsite in three stages. You plan a product with the interviewers, build it alone for two hours with whatever AI tools you want, then demo it and defend the choices you made. The coding phone screen is gone too, replaced by a system design interview. That is the core of the process the post describes, alongside a debugging interview still in pilot, and it rewards judgment under a clock over recall.
What did Sierra remove from its engineering interview process?
Sierra's post is direct about what the old loop looked like. In the company's April 22, 2026 post, Vijay Iyengar, Arya Asemanfar and Angie Wang describe the previous engineering process as "two coding interviews plus interviews for algorithms, system design, and culture fit, followed by reference checks." Standard and scalable, and the post says something about it had started to feel off.
The diagnosis they give is specific. The signal from that loop was mostly about mechanics, which the post lists as typing syntax into an editor, remembering algorithm details and stitching frameworks together. When the interviews stopped producing clear signal, hiring managers leaned harder on referrals and prior experience instead. That is worth reading twice. By Sierra's own account the old loop had stopped telling the company what it needed to know.
So the post's central sentence is short. "We removed our coding and algorithms interviews and replaced them with an AI-native onsite." Sierra's stated goals for the replacement were that it be representative of the daily work, high signal about where a candidate would excel, and a positive experience.
What happens in Sierra's Plan, Build and Review onsite?
The onsite has three named stages, and Sierra's post describes each one.
Plan. A working session with the interviewers to decide what to build. The post says "the candidate drives ideation, while interviewers ask questions to strengthen it," and that the idea is chosen from the candidate's own domain so the interviewers can watch product thinking happen. Instead of a spec, you get asked what you would make, and then pressed on it.
Build. The interviewer leaves the room. The candidate then has, in the post's words, "2 hours, using the AI tooling and frameworks of their choice," with "complete freedom to pivot or adjust scope as they go." Two things in that sentence matter more than the clock. The tools are yours to pick, so a candidate who has never worked with a coding agent is at a real disadvantage. And scope is yours to cut, which the post says outright is fine.
Review. You demo what you built. The post says interviewers "review the code to understand their technical judgment," naming data model, abstractions and extensibility as what they look at, and that they discuss the path to production. Then the line that separates this from a take-home. "We also dig into how they used AI along the way." The post does not elaborate on what that covers, so expect the question and have an answer.
Sierra also tells candidates the rubric in advance. The post says the company shares evaluation criteria and advice ahead of time, with the example that it is "OK to cut your scope as you build, and to skip boilerplate (CRUD, auth) to focus on what's unique." Read that as an instruction. A candidate who spends forty minutes on a login form has misread the assignment.
What replaced the coding phone screen at Sierra?
A system design interview. Sierra's post explains the swap in one move. The old phone screen had candidates write code without AI into an online editor, and the post's reasoning is that vibe-coding an app is easy while getting it into production in a scalable way is the harder and more relevant problem. So "we replaced the phone screen with a system design interview."
There is a second interview in pilot, and it targets the gap the onsite leaves. The Plan, Build, Review loop tests building something from nothing. It does not test working inside what the post calls an existing, messy codebase. So Sierra's post describes a debugging interview in which candidates get "a medium-sized codebase and a draft PR from a colleague that introduces a cross-cutting feature," with the job of reviewing and improving it using coding agents. The post is candid that "the level of AI used in this interview is still TBD," because, in the post's words, new models can zero-shot many fixes. If you interview at Sierra, ask the recruiter whether the debugging round is part of your loop and what the AI rule is that week. The post says it is still being decided.
For infrastructure candidates, the post says the same onsite applies and that Sierra has "amended the interview slightly to better capture the signal we need for infrastructure." Ask what the amendment is. The post does not say.
What is Sierra screening for?
The clearest statement is in the post's own conclusion. "We're hiring for strengths, not just an absence of weakness." The post says the format gives Sierra richer signal about a candidate's spikes and gaps, and that debriefs shifted from asking whether to hire someone to asking "where would this person thrive, and how do we support them?"
Two observable qualities get named as what the format makes easy to see. Agency, which the post frames as whether you pivot when you get stuck. And judgment, framed as how you scope what to build inside the time limit. Neither is a trivia question, and neither can be rehearsed by grinding a problem set. Both show up in the Build stage when the plan meets reality.
The post also addresses the obvious objection. An open-ended build is hard to grade consistently. Sierra's answer is "evaluation criteria that are agnostic to what the candidate builds, and we run interviews in pairs" to improve calibration. Two interviewers, one rubric, whatever you built. That is the mechanism that makes the format defensible, and it tells you the interviewers are scoring process and decisions rather than the cleverness of the idea.
Beyond engineering craft, Sierra's careers page says interviews evaluate "not only your capabilities, but also how well you align with our values," and its about page lists five of them, including one called Craftsmanship, described as getting the details right "from the words on the page to the system architecture." In an onsite where interviewers read your code and your product flows, that is one of the values the careers page says the interview measures.
What the prep sites get wrong
Search for Sierra's interview process and you will find guides describing coding rounds and an algorithms interview. That describes the loop Sierra's own post says it retired. Their post is dated April 22, 2026. Any guide that predates it, or that never read it, is describing a process the company has publicly replaced.
The AI allowance is easy to misread as a concession. Sierra's post says the third stage of its onsite, Review, includes a discussion of how the candidate used AI, and the post's opening argument is that an engineer's value now comes from combining technical ability with product thinking and business context rather than from the precise lines of code. Read together, those two statements make the tool part of what is being evaluated. This is the mirror image of the interview copilot problem. Sierra hands you the tool and then evaluates your judgment in using it.
Use candidate reports for texture. Use the post for structure, and ask the recruiter to fill the gaps the post leaves. The same discipline applies at Rippling and Jane Street.
How to prepare for the Sierra loop
- Pick your coding agent now and use it daily until the onsite. Sierra's Build stage lets you choose your tools, and two hours is not long enough to learn one. Whatever you bring should already be an extension of how you work.
- Rehearse scoping under a clock. Take a product idea in your domain, give yourself two hours, and build the one flow that proves the idea while skipping auth and CRUD. Sierra's post says cutting scope and skipping boilerplate is fine, so practice doing it.
- Prepare two or three product ideas from your own domain before Plan. The post says the session focuses on an idea in the candidate's domain and that the candidate drives ideation, and a candidate who arrives with options drives the session instead of being dragged through it.
- Keep a running log of your AI decisions during Build. Review asks how you used AI. Being able to say what you accepted, what you threw away and why is the difference between a demo and a defence.
- Prepare for a system design interview as the screen. The post is explicit that the coding phone screen was replaced.
- Ask the recruiter three things the post leaves open. Whether the debugging pilot is in your loop, what the current AI rule for it is, and how the onsite is amended for infrastructure roles if that is your track.
The pattern worth taking away
Sierra's old loop, in the post's own words, produced signal that was mostly about typing syntax into an editor and remembering algorithm details. The post argues that this stopped measuring the job once coding agents could produce the code, and rebuilt the loop around what an engineer does with that capability. Define the problem, make the tradeoffs, ship the flow that matters, and explain why.
That is a harder interview. The clock is real, the scope is yours, and the interviewers are reading both your code and your decisions. The preparation that pays is a hundred hours of building small things with an agent, until scoping and defending a build feels like an ordinary Tuesday. Sierra's post wrote down what the onsite asks of you. Take it at its word.