Engineering Interviews and AI's Philosophical Split

A look beyond the policy changes

Something shifted in engineering hiring this year.

The surface story is simple: after two years of companies fighting AI use in interviews, some gave up and started allowing it. Canva, Shopify, parts of Meta. The takes write themselves—”AI is transforming interviews!” etc.

But the more interesting shift beyond the policy change is the philosophical split it revealed. Some teams still treat interviews as verification. Others are redesigning them as simulations of real work.

What Interviewers Are Actually Seeing

What I’m hearing from engineering managers who’ve run AI-enabled interview pilots: the gap between candidates widened, not narrowed.

The assumption was that AI would be an equalizer: Give everyone Copilot, and coding speed stops mattering. The opposite happened. Strong engineers used AI to move faster through the boring parts and spent more time on architecture and edge cases. Interviewers describe a specific pattern—when AI generates the shape of a solution, weaker candidates lose the thread of the reasoning. They can’t reconstruct the decisions the AI implicitly made.

Candidates who prompt AI for a complete solution, and then can’t answer “what does this line do?” That’s an instant no-hire in every AI-enabled format I’ve heard about. But candidates who use AI to scaffold boilerplate while making their own architectural decisions are demonstrating exactly what the job requires now.

The Divide Isn’t Big Tech vs. Startups

The popular framing is that Big Tech is fighting AI in the interview process while startups embrace it. There’s something to that—Google and Amazon are definitely making things harder by using more advanced LeetCode challenges and adding mechanisms to detect ‘AI cheating—but it misses the deeper split.

The real divide is between companies that see interviews as verification and companies that see interviews as simulation.

Verification mindset: “We need to confirm this person has skills X, Y, Z. AI makes that harder to verify, so we need better detection or harder problems.”

Simulation mindset: “We need to see how this person actually works. They’ll use AI on the job, so let’s see how they use it.”

I think the simulation camp has the stronger position, and it’s how I’ve run interviews for some time. It’s not that verification is impossible with AI—you can still test fundamentals with follow-up questions. It’s that verification was always the wrong frame. The best predictor of job performance is watching someone do the job, or something as close to it as possible given interview constraints.

The companies that figured this out first happened to be startups, probably because they had less institutional inertia. But I’d bet the approach spreads regardless of company size.

Changes in the Skill Stack

People keep asking what skills matter now. The skills that matter always mattered, but the weighting shifted.

Design and architecture went up. Not because they’re newly important (they always were), but because AI makes implementation cheaper. When generating code takes seconds, the bottleneck moves upstream to deciding what code to generate.

An engineer who can break down an ambiguous problem, identify the right abstractions, and make sound tradeoff decisions is worth more relative to someone who just types fast.

Code review went way up. Engineers are spending more time reading and evaluating code than writing it from scratch. The ability to look at plausible code and spot the subtle bug, the security hole, the scalability problem—that’s the skill that actually matters.

Communication went up. Partly because pair programming and collaborative formats are more common. But also because explaining your reasoning is the main way interviewers verify that you actually understand what you built.

Algorithm implementation speed went down. Not to zero—you still need fundamentals—but relative to 2021, the ability to bang out a red-black tree from memory matters less. AI does that part faster than you will. What matters is knowing when you need one and how it’ll behave at scale.

Here’s my hot take: LeetCode grinding is less valuable than it used to be. Still not zero—Big Tech still uses it, and you need enough algorithmic fluency to evaluate AI output—but the ROI on memorizing 200 problems dropped.

What Good Looks Like in an AI-Enabled Interview

In collecting examples of what differentiates strong candidates in these new formats, I’ve seen a few patterns emerge:

Strong candidates externalize their mental model early. Weak candidates wait for the AI to give them one. Given an ambiguous problem, strong candidates figure out what’s actually being asked. “Who’s the intended audience?” “What’s the latency budget?” AI can generate solutions for any interpretation, but it can’t always choose the right interpretation.

They reject bad AI suggestions. One interviewer talked about a candidate who prompted Cursor for a caching layer, looked at the output, said “this doesn’t handle invalidation correctly,” and rewrote it manually. That’s signal. Though in this case maybe they could have re-prompted with better instruction.

They narrate their process. Even in AI-enabled formats, thinking out loud matters. Interviewers want to see how you decompose problems, not just the final solution. Candidates who prompt in silence give no signal, even if the results work.

They know when not to use AI. For a quick string manipulation? Sure, let AI write it. For the core business logic that the whole system depends on? Maybe think through it yourself first. Judgment about when AI helps versus hurts is itself a skill.

The Take-Home Paradox

Take-homes changed more than any other format.

The obvious change is that most companies gave up banning AI, because they couldn’t enforce it. But the interesting change is what happened to the problems themselves.

Good take-homes now give you a broken codebase and ask you to fix it. Or a working codebase and ask you to extend it. Or a real dataset with messy edge cases. The common thread is that they all require understanding a system, not just generating one.

For example, some startups are sending candidates a full-stack chat app with intentional bugs—authentication edge cases, race conditions, that kind of thing. They don’t care if you use AI to help find them. They care if you can trace the logic, identify root causes, and fix them correctly.

The old-style “build something from scratch in 4 hours” take-home is dying, and probably should. It tested who had the most free time as much as who had the most skill.

What This Means If You’re Hiring

Make your AI policy explicit. I’ve seen enough stories about candidates agonizing over whether to use Copilot—or using it and feeling guilty—that ambiguity clearly hurts everyone. Just say what’s allowed.

More importantly: design problems that require judgment, not just output. Complex, ambiguous scenarios that resist single-prompt solutions. Debugging and extension tasks, not greenfield implementation. Trade-off discussions, not just “does it work.”

And train your interviewers on what to look for. The evaluation criteria genuinely changed. Someone who learned to interview candidates in 2019 (or before!) needs to update their mental models.

What This Means If You’re Interviewing

Learn to use AI tools fluidly—Cursor, Claude, ChatGPT, whatever—so that when you’re in an AI-enabled interview, you’re not fumbling with the interface.

But also, don’t neglect the fundamentals. The follow-up questions are where you prove you actually understand what happened. If you can’t explain the time complexity of your solution, or why you chose this data structure over that one, the AI-generated code won’t save you.

Prepare for both worlds. Some companies embrace AI. Some are hardening against it. You’ll encounter both, and the preparation is different. And remember, these different approaches aren’t new. Not long ago, managers argued about whether candidates should be allowed to Google during coding interviews. Today, that question feels almost quaint, like an early version of the same verification-versus-simulation split playing out today on a much larger scale with AI.

So practice narrating your thinking. We’re in an era where how you got there matters the most. That’s always been true in senior interviews. It’s becoming true everywhere.

The teams that adapt fastest won’t be the ones that simply embrace AI, but the ones that redesign their hiring to reflect how engineering actually works now.

---

Dan Pupius is a member of TheGP’s engineering team. Previously, he was the co-founder and CEO of Range, head of engineering at Medium, and a staff engineer at Google.