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.
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.
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 version much earlier in the interview. That is not the end of the evaluation but where a more interesting evaluation can begin.
Once the basic implementation exists, the conversation can move to questions that better reflect real engineering:
- Is this solving the right user problem?
- Which parts should be tested first?
- How does the design behave under load?
- Where are the security or privacy risks?
- What would make the system easier for the next engineer?
This has impacted how we think about difficulty. A good AI-era interview question should not be difficult because it requires an obscure trick. Instead, it requires a sequence of sound decisions.
Verification Is a First-Class Skill
More often than not, AI tools produce convincing output that is subtly wrong. As a result, verification has become one of the strongest signals in an interview. Strong candidates run the code early. They read error messages. They inspect the data before choosing a representation. They ask for tests, but also evaluate whether those tests are meaningful. They notice when generated code changes an interface, ignores a constraint, handles only the happy path, or adds complexity that the problem does not need.
This is not a new engineering skill. Code review, testing, debugging, and skepticism have always mattered. AI simply makes their importance more visible.
The candidate who catches and corrects a polished-looking mistake often gives us a stronger signal than the candidate who produces a large amount of code without demonstrating that they understand it.
Interview Design Matters More Than Tool Choice
Adding an AI assistant to a traditional interview does not automatically make the interview better. If a problem can be completed by pasting the prompt into a tool and accepting the first response, the problem is probably not measuring what we care about.
The exercise itself must create room for engineering judgment. That can come from incomplete requirements, an unfamiliar repository, noisy data, operational constraints, competing priorities, or a request that changes after the first version works.
The interviewer also needs to be prepared. Evaluating AI-assisted work requires more than counting completed test cases. Interviewers need a shared rubric, examples of strong and weak collaboration patterns, and calibration on what should differ by experience level.
For an early-career candidate, a well-scoped task and the ability to learn quickly may be the right signal. For a senior candidate, we expect stronger problem framing, clearer tradeoffs, and more attention to long-term system behavior. AI gives candidates another way to demonstrate their level.
The Human Owns the Work
Our standards for engineering judgment have not changed.
Candidates still need to reason clearly, communicate their approach, understand the code they submit, and respond constructively when something fails. Fundamentals still matter because they are what allow an engineer to evaluate a generated answer. System design and behavioral interviews continue to examine dimensions that a coding assistant cannot substitute for: leadership, collaboration, ownership, technical depth, and the ability to make decisions in context.
The interviewer remains essential as well. AI can help summarize activity or suggest areas to probe, but hiring is a consequential human decision. Interviewers are responsible for understanding the evidence, asking follow-up questions, and applying the rubric consistently.
Most importantly, the goal is unchanged: identify people who can do excellent work with the team.
Using AI in Interviews
There is a temptation to frame AI in hiring as a question of permission: should candidates be allowed to use it or not? We think the more useful question is: what capabilities will distinguish excellent engineers in an AI-native organization?
Our answer includes many capabilities that have always mattered: curiosity, rigor, taste, communication, and ownership. It also includes the ability to use AI effectively and responsibly. Engineers need to know when to accelerate, when to slow down, when to delegate, and when to distrust the answer in front of them.
As we've rolled out these changes, we've seen encouraging signs that we're hiring candidates who raise the bar on our AI-native engineering capabilities, introduce new workflows, while also strengthening the judgment, verification, and ownership we value across the organization.
As AI continues to change software engineering, we believe that our process for evaluating candidates will continue evolving to ensure our engineering organization is built to maximize our ability to leverage this shift. AI may write more of the first draft, but the engineer is still accountable for what ships.