Google Is Now Testing Engineers on Their AI Skills — Not Just Their Code

The interview room just changed. Google has begun piloting a new software engineering interview format that explicitly allows — and expects — candidates to use AI assistants like Gemini during the evaluation. This isn't a concession to modern habits. It is a deliberate signal about what Google now considers a core engineering competency.

The shift is significant not because Google is the first to permit AI tools in assessment contexts, but because of what the permission implies. When a company that employs some of the world's most senior engineers restructures its hiring process around AI fluency, it is making a public statement about what the job actually is.

What Changed, and Why It Matters

The traditional software engineering interview — whiteboard algorithms, LeetCode-style problems, a blank editor and a ticking clock — was built around a specific theory of what engineers do: recall syntax, implement data structures from memory, demonstrate that the brain alone can solve constrained problems under pressure.

That theory has always had critics. What it measures and what the job requires have never been identical. But it persisted because it scaled, it was defensible, and it filtered effectively for the kind of thinking that engineers actually use.

What it never measured was how well a candidate could work with a collaborator who generates code at machine speed, needs constant verification, and requires the human to know which output to trust.

Google's new format begins to measure exactly that. Candidates are expected to use AI assistants as part of their workflow — not to cheat, but because that is now the workflow. The evaluation has shifted from "can you produce the solution" to "can you produce the right solution, and do you know when the AI is leading you somewhere wrong."

The Numbers Behind the Decision

Google has reported that roughly 75% of new code written internally is now AI-generated. That figure has been cited by executives and in public disclosures, and it is consistent with what engineers at comparable organizations are reporting anecdotally.

If three-quarters of the code touching production is coming from a model rather than directly from a human's keystrokes, then the critical skills have quietly reordered themselves. Prompt engineering, output validation, architectural judgment, and the ability to debug generated code have become more important than raw implementation speed. The engineers who are most valuable are not necessarily the fastest coders — they are the ones who can oversee a large volume of generated code and catch what the model gets wrong.

An interview process that still tests only the old skills is selecting for the wrong things.

The Shift from Coding to Orchestrating

What Google is formalizing has a shape that practitioners have been describing for a couple of years now: a move from assembly to architecture, from syntax to systems thinking.

The question used to be "Can you code?" Now it is closer to "Can you orchestrate?" — can you direct AI agents toward the right outcome, validate what they produce, and take responsibility for a system you didn't write line by line?

This is not a lower bar. In many ways it is a harder one. Knowing that a solution is correct requires deeper understanding than producing one. Debugging code you didn't write requires you to hold a model of what the code should do and compare it against what it actually does, without the scaffolding of having written it yourself. And deciding when not to use AI — when the generated output introduces subtle risk, when a problem requires a kind of reasoning that models currently handle poorly — demands exactly the judgment that experience develops.

The candidates who will do well in Google's new format are not the ones who rely on AI to answer questions for them. They are the ones who treat AI as a capable but fallible collaborator that needs direction and verification.

An Industry Signal

Google's move is unlikely to stay contained to Google. When a company of that scale and technical prestige changes how it evaluates engineers, the rest of the industry pays attention. Hiring managers at other firms are watching the format. Bootcamps and universities are already reconsidering what skills they emphasize. The definition of "engineering fluency" is being revised in real time.

For engineers currently in the workforce, the message is also clear. The tools have changed the job description, and the job description is now changing the hiring criteria. The engineers who built their identity around typing fast, remembering APIs, and implementing algorithms from scratch are not being made obsolete — but they are being asked to extend their skill set in a direction that some will find uncomfortable.

The ones who adapt earliest, who learn to treat AI as a collaborator rather than a shortcut or a threat, are the ones who will find the new interviews — and the new jobs — easiest to navigate.

A calculator didn't replace mathematicians. It changed what mathematicians spent their time on. The same logic is playing out in software engineering, one interview format at a time.