Something shifted this week in the forums where senior engineers argue with each other, not on LinkedIn with thought leadership captions, but in the places where people actually say what they think. The old question came back around: do side projects still matter if you want to be taken seriously as a good engineer?
But the conversation took a sharper turn. If any candidate can lean on an AI agent to solve a technical interview exercise, what is that exercise actually measuring anymore?
The Question That Stopped Working
For years, the technical interview had one simple job: check whether a person could solve a problem alone, unaided, with nothing but a whiteboard or an empty editor. That made sense. In a world where writing code from scratch, recalling exact syntax, and not freezing in front of something unfamiliar were real signals of ability, measuring that was, in effect, measuring the engineer.
That world moved on without sending a memo. Today, anyone with access to a coding agent can produce a reasonable solution to a classic interview problem without fully understanding it. "Can you solve this alone?" is still the question in a lot of interview loops, though it measures less and less of what it claims to.
Why "No Help Allowed" Stopped Meaning Anything
The problem here is concrete. That same engineer, the moment they start the job, will have an AI agent next to them on every pull request, every bug, every new feature. Testing them without that tool measures a skill they won't actually use the way the exercise assumes.
It's a bit like judging a pilot on their ability to fly without instruments. It might say something about instincts and base knowledge, but it isn't the job they're going to do every day. The real job always included the tools available.
Before and Now, Two Different Questions
Before, the question that defined a good engineer was can you solve this alone? It measured memory, typing speed, fluency with the exact syntax of whatever language was on the whiteboard. A candidate who stumbled on a minor implementation detail could lose an offer over it, even with excellent design judgment.
That question lost the meaning it used to have. The one that should replace it sounds similar but measures something completely different: does this person make good decisions with the tools they have available? Answering it well requires watching how someone directs an agent, what they ask it for, what they correct, and above all, when they decide not to follow its suggestion.
Judgment, Not Memory, Is What Separates a Senior Engineer Now
An AI agent can write functional code in seconds. What it doesn't have is context. It doesn't know why that endpoint carries a strange exception left over from a migration two years ago, it wasn't in the room for the architecture decision made after a production incident, and it doesn't know which part of the system is untouchable and why.
A senior engineer has that context, or knows how to get it before accepting a suggestion. That's the skill separating them from someone who isn't there yet: the judgment to recognize when the agent's answer is right, when it needs adjusting, and when it needs to be thrown out entirely because it solves the wrong symptom. That ability to spot the error doesn't come from a good prompt, it comes from years of watching systems fail in specific, memorable ways.
An Example of the Kind of Mistake That Separates the Two
Take a simple case: the agent suggests adding an index to speed up a slow query. The suggestion compiles, passes the tests, and in the dev environment the query genuinely runs faster.
An engineer without enough context accepts it and moves on. A senior one pauses for a second first: they know that table takes constant writes in production, that a poorly chosen index can slow down every insert, and that the real problem isn't the query but how that view is being paginated.
The agent's suggestion wasn't badly written. It was badly aimed, the kind of thing you'd approve in a PR with a comment like "works, but something feels off." That feeling, knowing when something is technically fine but still wrong, is exactly what a technical interview should be looking for now.
Side Projects Didn't Lose Value, They Lost the Monopoly
Worth clarifying before going further. Personal projects still say something real about an engineer: initiative, curiosity, the ability to finish something nobody asked for or paid for. That hasn't changed.
What changed is that it stopped being the only valid signal. Not having personal repos to show used to raise real doubt about someone's actual commitment to the craft.
Today, an engineer can have zero side projects and still demonstrate, in how they direct an agent during an interview and catch where it goes wrong, exactly the kind of judgment that used to be visible only in whoever coded on weekends. For a long time, side projects were the most visible proof of that judgment. They're no longer the only way to show it.
What Changes for the People Designing the Process
For companies building interview processes, this means rethinking the technical exercise from the ground up. Giving candidates access to an agent during the interview, then watching when they trust its suggestion and when they push back on it, reveals more about their actual level than banning the tool and timing how long it takes someone to write a for loop from memory, like it's still 2015. The question worth asking when designing the process isn't how to stop candidates from using AI, but how to design an exercise where using it badly is just as visible as not using it at all.
Anyone with the right prompt can produce code now, and even the agent knows it (probably better than anyone). What separates a senior engineer from someone who isn't there yet was never who writes faster, but who notices first that what just got written is wrong.
