System Design Hiring Is Really a Judgment Test
Some repeat architecture while others jump straight to scaling, but the ones who stand out reason through failure, cost, and change.
Tech hiring is tighter, and AI has raised the bar for what companies expect from senior engineers. When companies do open senior engineering roles, they are paying closer attention to quality of hire, adding more signal to the process, and trusting the old formats less.
And the system design round is where that scrutiny concentrates, because it is the one round an AI assistant will not get you through. The system design interview may look the same as it did a couple of years ago, but the grading rubric underneath it has changed a lot.
Consider Karat’s 2026 survey of 400 engineering leaders. It found that AI has widened the gap between strong and weaker engineers rather than closing it, and 73 percent of leaders now say a strong engineer is worth at least three times their total compensation. CoderPad’s State of Tech Hiring Report 2026 shows technical assessments up 48 percent globally since mid 2023, with 60 percent of talent leaders naming quality of hire as their top priority for the year.
We asked engineering leaders who personally conduct system design loops what they actually look for in a session. These insights are not usually found in prep guides and they converge on a shift most candidates have not yet noticed.
Buzzword-first designs are a huge turn off
Archit Agarwal, Principal Member of Technical Staff at Oracle, has in his engineering purview interviewed hundreds of engineers, especially for ultra-low-latency authorization work. And the failure he catches most often has nothing to do with AI. “I’ve seen a lot of engineers come in to a system design interview and, as soon as I give a problem, they start with ‘let’s use microservices,’ and start using distributed cache,” he shares, and when he asks how many users they are planning for, the answer rarely matches the architecture they just proposed. “That is a key difference between any interview-ready engineer and a genuinely good engineer,” he explains, because “a genuinely good engineer would not want to implement everything up front.”
Agarwal’s baseline is quite blunt, that “if the problem isn’t complex yet, don’t overengineer it.” And he, like many notable leaders, holds the position that “microservices aren’t the magical fix that fixes bad architecture. They just distribute that over the network.” What he seeks instead is one to two minutes of genuine alignment at the start, functional requirements first to establish what is being built and what the user needs, then the nonfunctional requirements that set scale, consistency, and latency. “Nonfunctional requirements are the ones that decide the architecture—not the other way around.” And not every system earns planet-scale treatment, since a tool used only by a company’s own engineers needs no multi-region deployment, and proposing one tells him the candidate is performing rather than designing.
He also weighs cost. It is something that always runs through his evaluation the same way, and he shared with us a line that reframed his own career, “a good engineer would design for performance, but a great engineer would design for performance per dollar,” and he pushes candidates to weigh a latency win against the infrastructure bill it creates. That cost lens is exactly where the interview has changed most, because the most expensive and least predictable component on the whiteboard is now the model.
Earlier this year, we spoke with Agarwal about trade-offs in modern system design, and later published another piece featuring his candidate-side advice on why senior engineers fail system design interviews.
Treat every AI component as one that will fail
AI is on every whiteboard now, and the reliability assumptions underneath it are exactly what interviewers have started to stress test. Rohit Poduval, Senior Software Engineer on Prime Video Trust and Safety at Amazon, opens with a test that did not exist two years ago. “Does the candidate treat an AI component as an unreliable dependency or a magic box?” “I ask them to design a system that uses an LLM. Content classification, recommendation filtering, whatever fits the role,” he explains, and then he watches what they do with it. “Weak candidates draw a box labeled LLM and move on, like it’s a database that always returns the right answer,” while strong candidates, he shares, “immediately ask: What happens when it’s wrong? What’s the fallback? How do we know it’s drifting?”
That one reaction most often separates people who have shipped AI systems from people who have read about them. LLMs return different outputs for the same input, and Poduval points out that you can enforce structure on the output, valid JSON or responses from an allowed set, but you cannot assert that the decision itself is correct with a traditional pass and fail test. Candidates who have built these systems talk about evaluation suites, guardrails that constrain what the model can do regardless of its output, and monitoring for drift in production. But candidates who have not will handwave past every one of those concerns. And that handwaving is quite visible within minutes.
“The next thing I probe: how do they test it?” Poduval shares, because traditional assertions do not apply to AI components. “Strong candidates talk about benchmark evaluations: a defined set of inputs with expected behavioral boundaries (not exact outputs) that the system must satisfy before shipping.” They also talk about continuous auditing against real traffic after launch, not just checks before deployment, because a model that passed benchmarks last month might be drifting today. His deeper observation is that with AI systems you often cannot enumerate every right answer before launch, so the old playbook of define requirements, build to spec, and ship no longer closes. The engineers he rates highly design for safe iteration instead, with shadow mode, holdback groups, evaluation frameworks from day one, and human escalation paths, because they expect to keep refining the definition of correct after launch. “That’s exactly where the memorized answers fall apart.”
Taking into consideration the resource-intensive workloads and the shrinking budgets, cost has to be something a candidate can defend out loud. Poduval changes a constraint mid session and tells the candidate the system now needs to handle ten times the traffic. “Candidates who’ve never dealt with inference costs at scale just say ‘add more instances’. Candidates who’ve lived it start talking about which requests actually need an expensive model vs which can be routed to cheaper classifiers,” he shares. They design tiered systems with routing logic that decides in real time which compute budget each request deserves.
The practical takeaway for anyone walking into a loop this year is direct, so state the fallback, the evaluation plan, and the per-request cost tier for any AI component before the interviewer has to ask. Everything on that checklist has an architectural counterpart, and we have captured the nuances of each in Sampriti Mitra’s practical deep-dive on core architectural patterns for LLM system design, which walks through the gateway, tiered fallback, model routing, and evaluation patterns behind it.
Constraint changes reveal who patches and who rethinks
Chandu Putta, Senior Software Engineer at MissionSquare Retirement, in our email interview shared what earns his confidence. “The signal that I trust the most is not the architecture a candidate produces, it’s how they think if I change a constraint in the middle of the interview.” In a recent loop he had candidates design a document processing pipeline, and midway through he added an LLM call to the extraction step, with variable latency and non-deterministic output. The majority of candidates bolted a retry mechanism onto their existing design and moved on. One candidate stopped and asked, “What’s the acceptable failure mode — an explicit error to the engineer or a silent degradation?” he recalls.
That question, to his mind, is the level marker, because it treats the new component as a design problem rather than a network hiccup. Putta is blunt about how he sizes this up, as “rehearsed candidates patch the existing design, but the real senior engineers discard it and start fresh with this new anchor.” The engineers he considers qualified for the job also ask about context boundaries and cost at scale without being prompted, he adds, and they raise a question that prep articles don’t teach, which is who decides whether the model output is good enough, the technology team or the business team. An engineer who asks that has sat in the meeting where the answer was contested.
Edward Tian, creator of GPTZero, sees the same moment through a different lens. He shares with us how his interviews confirm the pattern from another direction. “When we see candidates redesign their system following the introduction of a new constraint, we see that they are able to quickly identify the most significant aspect of their original design that has become the bottleneck,” he explains, and they design new components to replace it.
But weak engineers make incremental changes to accommodate the new requirement without revisiting the larger trade-offs the original design was built on. His sharpest distinction is about posture rather than knowledge, because “most engineers will assume that their original design is now incorrect after the constraint has been added and defend the changes made to it,” he shares. “Senior engineers will simply continue to increase the rate of evolution of their design until it meets their new constraint.”
Tian also shares how he has noticed a newer failure mode that improved AI tooling has made common. “Many candidates can produce beautiful pipeline diagrams for their LLM, but when we dig through more complex failure modes, for example context window, they really struggle,” and they default to talking about scaling the model. The diagram generated fluency, but probing exposes it.
Agarwal looks for something similar when he changes the requirements mid session. The candidate who absorbs the change, restates it in their own words to confirm alignment, and then highlights which parts of the system must change and which remain intact is showing him a structured redesign instinct rather than attachment to a diagram. He also likes to give away something candidates rarely hear from the other side of the table. “The curveballs that the interviewer gives you will never be in a way that you will have to scrap the complete diagram, the complete architecture, unless you were already off the track.” A constraint change is a test of surgical judgment, so the working advice is to name out loud what survives and what dies before you touch the whiteboard.
Can you defend the choice you just made?
Prakhar Chaube, Senior Software Engineer at InsurGrid who previously held the same level at Whatfix and has conducted more than 25 technical rounds, argues the design round should never hunt for a correct answer. He assesses the thought process and then questions the candidate on their component choices, because that questioning mirrors what happens inside real companies. “Most companies have some form of an Architectural Review Board, meaning it’s rare that a new implementation will not be questioned even if it is the right choice.” Candidates should know why the standard patterns work as standards rather than assuming a plug and play model, and the ones who can stand by their choice under pressure usually survive a real review. In his loops he is categorical about telemetry, since “if a candidate is not mentioning that in an interview it is a big no,” because “without proper observability the system is doomed to fail at scale and cause chaos during debugging.”
Chaube has also built a ladder for assessing AI fluency that moves well past the 2024 questions. “I first assess the basics like parameters, prompt structure, prompt security, hallucination,” he shares, then he wants to dig deeper into implementation scenarios drawn from real products, autonomous tasks orchestrated by a central model such as a code review agent or a login and scraping system. The final rung, he explains, is how candidates handle agent-guided coding, because “I look at their queries and flow” rather than their claimed experience. This method, he says, reliably separates candidates who prepared just for the interview from candidates who are genuinely strong. The preparation gap shows up in the follow-ups, never in the opening answer.
Sándor Dargó, senior software engineer at Spotify, has observed the same gap from years of interviewing in the C++ world, and his experience reinforces Chaube’s from a different stack. He describes a depth gap first, because a language whose standard runs about 2,000 pages guarantees that even genuine experts have blind areas, and the honest move is admitting them.
Dargó in our live interview session shared how he once told an interviewer he did not know a topic and did not want to guess. The interviewer replied that their team did not use it either, and he got hired. His second observation lands harder, as he has seen senior engineers who handle architectural questions with real thoughtfulness struggle to write simple algorithms live under pressure. Rehearse defending your choices against a hostile follow-up, not presenting them to a friendly one, and practice the small problems you assume you have outgrown.
Safety-critical systems raise the same bar higher
With more than 15 years in secure embedded systems, Hareesha KoratikereRameshappa, Senior Technical Product Manager at Phantom AI, likes to conduct design interviews where the system under discussion can kill someone. He evaluates whether a candidate can translate high-level product requirements into a structured, developable architecture without compromising safety, cost, accuracy, reliability, and power consumption. He looks for system-level thinking across hardware, firmware, application software, and flashing methodologies like OTA. And what he expects, he shares, is that “the candidate should understand the key elements of system design, such as system and operating modes, error and fault detection, active and history fault mode managements, transition to the safe mode, and recovery from the fault mode.” They must also supply the inputs verification depends on, KPIs, requirements, corner cases, and they must plan to monitor the system after deployment rather than treating launch as the finish line.
His trade-off vocabulary sounds exactly like the web scale interviewers we heard from earlier, and that essentially is the point. Rameshappa presses candidates on functionality versus performance and accuracy versus resource consumption, and he expects them to justify design decisions with data and adjust the design when another team’s feedback is valuable. At Phantom AI he shared how he struggled to find candidates who combined production experience with sensor selection, calibration integration, and corner case validation, which tells you how rare the full reasoning package is even among experienced engineers.
This means that what the interviewers are testing is not a property of a tech stack. It is engineering judgment, and it transfers from a recommendation pipeline to a multi-camera ADAS system without translation.
Trade-off reasoning still decides the level
Everything above rests on a foundation that has not moved, and Dhirendra Sinha, Software Engineering Manager at Google, described it last year in one of our conversations with him and Tejas Chopra. “It’s easy to choose between good and bad solutions,” Sinha told us, “but senior engineers often have to choose between two good options. I want to hear their reasoning.” He also carries a line from a chief architect at Yahoo that reframes how scale changes judgment, because when an engineer dismissed a corner case as one in a million, the architect replied, “One in a million happens every hour here.” Scale invalidates assumptions, and mostly every leader in this piece is testing whether a candidate’s assumptions survive contact with it.
Agarwal’s version of the same evaluation focuses on where a candidate chooses to go deep. When a candidate takes one area, distributed storage or authentication or performance engineering, and drives into real depth, he takes that as an engineer who “understands the gravity of things” rather than one collecting surface vocabulary. And he calibrates the questions a candidate asks against their level, because clarification questions are always welcome, but a flood of questions too basic for someone with a strong resume tells him the candidate has never actually thought about the system in front of them.
Tejas Chopra, Senior Engineer at Netflix, closes the loop between the old test and the new one with a single follow-up he has asked for years. When a candidate picks SQL over NoSQL or strong over eventual consistency, he asks what changes if the user base grows tenfold, and the AI era version of that question is exactly what some interviewers in technical rounds now ask about model cost and failure modes. The component changed, but the muscle is the same. For readers who want the underlying vocabulary these interviews keep invoking, consistency, availability, partition tolerance, and the read and write trade-offs that connect them, Sinha and Chopra’s practical deep-dive on distributed system attributes from their book System Design Guide for Software Professionals walks through all of it with worked examples.
What to do in your next loop
Ask for the acceptable failure mode before you design anything, because that single question outranks any diagram you will draw. Treat every AI box in your architecture as a component that will be wrong, and price its errors with a fallback, an evaluation plan, and a cost tier per request class. When a constraint changes mid session, say out loud which parts of your design survive and which parts die before you redraw anything. Say what you would monitor without being asked, and say I don’t know about the right things, because every interviewer quoted here treats honesty about limits as seniority rather than weakness.
The rehearsed candidate optimizes for the first answer, and the bar has moved to the third follow-up. That is the whole shift.
Contributors
Archit Agarwal, Principal Member of Technical Staff, Oracle. LinkedIn. Read his candidate-side advice in Why Senior Engineers Fail System Design Interviews.
Rohit Poduval, Senior Software Engineer, Amazon (Prime Video Trust & Safety). LinkedIn
Naga Chand Putta, Senior Software Engineer, MissionSquare Retirement. LinkedIn
Edward Tian, Founder, GPTZero. LinkedIn
Prakhar Chaube, Senior Software Engineer (SDE-3), InsurGrid. LinkedIn
Hareesha KoratikereRameshappa, Sr. Technical Product Manager, Phantom AI. LinkedIn
Sándor Dargó, Senior Software Engineer, Spotify. sandordargo.com
Dhirendra Sinha (Google) and Tejas Chopra (Netflix), authors of System Design Guide for Software Professionals (Packt). Read their free chapter.
Sources
Karat, “Engineering Interview Trends in 2026,” March 2026. https://karat.com/engineering-interview-trends-2026/
CoderPad, “State of Tech Hiring Report 2026,” March 2026. https://coderpad.io/blog/hiring-developers/new-research-the-2026-state-of-tech-hiring-what-ai-means-for-developers-and-hiring-teams/
Deep Engineering, “Why Senior Engineers Fail System Design Interviews,” May 2026. https://deepengineering.net/p/why-senior-engineers-fail-system-design-interviews
Deep Engineering #36, Archit Agarwal on System Design Trade-offs, February 2026. https://deepengineering.substack.com/p/deep-engineering-36-archit-agarwal