Hiring Engineers For An Ai Native World

AI-Native Engineering Interviews at Cerebras Skip to main content

Flex and Cerebras are scaling American manufacturing of AI supercomputers in Silicon Valley. Learn more >>

Jul 09 2026 Hiring Engineers for an AI-Native World Sebastian Duerr Hagay Lupesko

Cerebras engineers use AI as part of their everyday work, so our technical interviews should reflect that reality. Across our engineering organization, we have adopted realistic, multi-step exercises in which candidates can use AI while interviewers evaluate problem framing, verification, judgment, communication, and ownership. The tools available to candidates have changed, but the standards for excellent engineering have not. AI coding agents, including Codex-Spark and faster Cerebras-powered coding systems from Cognition, are rapidly changing how software engineers work, giving strong engineers new ways to move faster on implementation, debugging, testing, and exploration. At Cerebras, we’ve seen significant productivity gains as we adopt AI in our engineering organization, and that has shaped how we’ve adapted our technical interview process. This blog post shares our learnings and insights as we adapted our technical interviews to incorporate AI use and skill evaluations. Software engineering has changed quickly Today, engineers routinely use AI to explore unfamiliar code, generate a first implementation, debug failures, write tests, compare design options, and automate repetitive work. At Cerebras, these tools are part of how we build. Yet the traditional technical interview often asks candidates to work in an artificial setting: no AI tools, little context, and an emphasis on recalling a familiar algorithm or an arcane language syntax under time pressure. That gap matters. An interview should help us understand how someone will perform on the job, not how well they can imitate a way of working that is disappearing from the job. Over the past several months, teams in the Cerebras engineering organization have been redesigning parts of our engineering interview process around a simple premise: If AI is part of the work, it should be part of how we evaluate the work. This does not mean asking less of candidates. In many ways, an AI-assisted interview lets us ask more. We can move beyond syntax recall and small coding puzzles toward realistic engineering tasks. We can see not only whether a candidate reaches an answer, but how they frame a problem, direct an AI tool, inspect its output, recover from mistakes, and make sound tradeoffs.

" Building an AI-native organization is not only about giving our teams new tools. It means developing the judgment to use those tools well. Our hiring process should help us identify engineers who can combine technical depth with that new kind of leverage. " Hagay Lupesko SVP of Engineering

Here is what changed and what we have learned so far. What Changed The Interview Looks More Like Engineering Instead of centering an interview on an isolated algorithm, we added exercises that resemble the work engineers encounter after joining a team. A candidate might explore a small repository, add a capability to an existing service, investigate an operational dataset, improve a developer tool, or turn an incomplete request into a working prototype. The environments and details vary by role, but effective exercises tend to share a few qualities: They require more than one step. They include enough ambiguity to require judgment. They reward planning, testing, and iteration.

We often begin with a concrete objective so that every candidate has a clear path into the problem. Then, we open the interview up: What would you improve? What assumptions would you revisit? What would have to change before this could run in production? This progression shows us different dimensions of engineering ability. The concrete task tests execution. The open-ended portion reveals product sense, prioritization, communication, and design judgment. The production discussion shows whether a candidate can see beyond a prototype to reliability, security, observability, scale, and maintainability. Candidates Are Expected to Use AI In designated AI-assisted coding rounds, candidates are told in advance that AI is allowed and expected. That clarity is important. We do not want a hidden test in which some candidates quietly use tools and others assume that they cannot. We are not scoring candidates on whether they use a particular prompting formula. We are evaluating how effectively candidates collaborate with a powerful but imperfect tool as part of the broader engineering task. We Evaluate AI Collaboration as a Skill In an AI-assisted interview, we are not only evaluating the final code. We are also evaluating how effectively a candidate works with AI itself. That includes how well they frame a request, provide useful context, break work into verifiable steps, recognize when an answer is incomplete or wrong, and decide when to rely on the tool versus when to challenge it. These are increasingly important engineering skills in their own right. We do not treat familiarity with a specific interface or prompting style as the goal. What matters is whether a candidate can use AI thoughtfully, verify its output, and stay accountable for the result. Some of the signals we look for are familiar to anyone who has worked with AI-generated code. Together, they help us evaluate whether a candidate can use AI productively and responsibly. Does the candidate understand the problem before delegating parts of it? Can they provide the tool with useful context and constraints? Do they inspect generated code rather than trusting it automatically? Can they explain, change, and debug the result? Do they test the behavior that matters, including edge cases?

The best candidates retain ownership of the solution. They use AI to increase their leverage, not to outsource their judgment.

" The strongest candidates do not treat the AI as chat bot. They use it to move faster, but they keep a clear mental model of the system, verify what changed, and stay accountable for the result. " Seb Duerr Member of Technical Staff

That distinction is central. Generating code is becoming easier. Deciding what should be built, recognizing when an answer is wrong, and turning a plausible prototype into dependable software remain difficult. What We’ve Learned Working Software Comes Earlier When candidates can use modern tools, they can often reach a working first...