The comment landed on the pull request early afternoon, around 9 in the morning his time; we worked a few time zones apart. Four paragraphs defending his implementation, well structured, calm, thorough, closing with a suggestion that we align on the approach going forward. I still disagreed with the implementation, but I respected the argument. It read like something a senior engineer would write.

The next morning, we had a live share screen session to present the solution. I gave him a small task on the spot: take a hardcoded value and move it to an environment variable. Housekeeping. Two minutes, maybe five if you have to go get a coffee.

He opened Copilot and started typing a prompt.

"What are you doing?" I said. "Come on - you don't need Copilot to add an env var to your own code."

So he did it by hand, and that's when I saw it. He struggled to navigate his own code - the code he'd defended in four paragraphs - hunting for the pydantic config like a visitor in someone else's repository. Then the second thing: environment variables come in as strings, this value needed to be a number, and he didn't know how to do that. Not "forgot the syntax" - didn't know that converting a string to a number in Python was a thing he was supposed to do, or how to look for it. This is a person whose CV said data science. Years of it, allegedly, in a language where int() is the kind of thing you learn the first week and never think about again.
Four fluent architecture paragraphs one afternoon, couldn't int(x) the next morning. The interview had been great, the CV impressive.

What the interview measured

We ran the process remotely, like everyone did by then. He answered everything. Machine learning, evaluation metrics and scores, RAG and vector databases, Docker, SQL and NoSQL, database indexes, REST APIs, HTTPS, encryption, authentication and authorization - the whole spread, handled with unusual composure. No wrong turns, no backtracking, no "I'm not sure, but here's my guess."

At the time, that looked like a strong signal. In hindsight it was the tell.

A technical interview is built as a ladder. The early questions confirm the basics. The later ones climb in difficulty on purpose, because the interviewer is trying to find the step where you slow down, start reasoning out loud, and eventually say "I don't know." That step is the measurement. It tells me your level, and it tells me something more valuable: what you do when you run out of level. Do you reason from first principles? Ask a clarifying question? Bluff?

A candidate who never reaches that step has, in theory, exceeded the ceiling of my interview. That happens. I've met engineers who genuinely out-climbed every question I had. But they have a texture to them - they get more engaged as the questions get harder, they argue with the premise, they tell you where your scenario is unrealistic. What they don't do is deliver each answer with the same even confidence, in the same structured cadence.

Even confidence across all difficulty levels isn't a sign of skill. Skill has a gradient. You can hear it in how someone answers a question at their comfort level versus one just past it. When the gradient is missing - when the question about B-tree page splits gets the same fluent treatment as the question about basic data types - either you're talking to one of the best engineers of your generation, or you're talking to a second screen.
I assumed the first. I shouldn't have.

This is why we moved the technical round back to face-to-face, and it has nothing to do with tradition or nostalgia. A live conversation in the same room is the last environment where I can observe the thing I'm actually hiring: a person, reasoning, unassisted, at their real level. I don't need them to perform under pressure, a candidate can think in silence as long as they want. I need to see where the ladder ends. Remote interviews stopped being able to show me that, because for a mediocre engineer with a state of the art LLM, the ladder no longer has a top.

Debating a proxy

The env var morning changed how I read his messages, but the answers kept coming. Every review comment I left came back with a rebuttal. Fast, fluent, three or four paragraphs, complete with tradeoffs. The tone never wavered and nothing was ever conceded. I'd respond, and within the hour another one would arrive, just as calm, just as structured, addressing my points one by one with a weird politeness.

Producing one of those rebuttals cost him a copy, a prompt and a paste. Verifying it cost me twenty minutes - reading the documentation he cited, checking whether the tradeoff he described applied to our case at all, writing a response precise enough not to spawn three new threads. Reviewing his work had quietly become the biggest line item in my calendar.

And underneath every exchange sat the thing I couldn't say. I was fairly sure - the pydantic morning had made me fairly sure - that the person I was debating didn't understand the position he was defending. But knowing it and saying it are different weight classes. Accuse someone of relaying a model's arguments and you'd better be right, and able to show it; otherwise you're the manager who calls his reports frauds whenever they push back. So I kept my cards down and answered the arguments on their merits. Disagreement is the job; I don't mind it. What drained me was writing rebuttals to a machine, routed through a person who couldn't evaluate either side of the debate.

The second task was small and deliberately unglamorous: a script, no interface, no users. What he delivered had a web UI and a login screen. The script itself - the part anyone had asked for - still didn't work properly. When I asked why he'd spent his time on extras nobody requested while the requested part had problems, the answer came back without a flicker of doubt: "Because making a login is easy."

I've been doing this long enough to flinch at that sentence.

Authentication is a hard problem - session handling, token expiry, credential storage, password resets, and so on. Whole companies exist because engineering teams decided never to build it themselves. But I understood where his confidence came from. A model scaffolds a login page in thirty seconds, and it runs, so to him a login was easy. AI has flattened the visible effort of hard problems and trivial ones down to the same short wait, and if visible effort is your only gauge of complexity, everything seems as easy. He wasn't lying to me. He couldn't tell the difference. Or, more likely, never could, and now had a tool that agreed with him.

That was the shape of those weeks: confident essays in the pull requests, confident shortcuts in the work, and me in the middle, debating an LLM.

Why do I need you?

The clearest version of the problem surfaced in the next task. I handed him a piece of work with clear requirements. A solution came back. Decent, tidy, obviously generated, and wrong in two places that mattered. I reviewed it, found both problems, and explained them, along with the direction of the fix. A corrected version came back shortly after. It was fine. On the project board, this looked like an engineer completing a ticket.

Walk the steps, though. The requirements were mine. The review that caught the flaws was mine. The direction for the fix was mine. The code was the model's. His contribution was moving text between me and the LLM - my task description into the prompt, my corrections into the prompt, the output into a pull request. At which of those steps did I need him?

I had, in effect, added a layer between myself and Claude. It contributed latency, demanded a salary, and it subtracted accountability - when the corrected solution worked, that was his ticket done; when the first one was broken, that was somehow my fault for not writing clear enough requirements. Which was, notably, the only kind of pushback he ever produced. While the work was in front of him he never questioned a requirement, never asked what should happen at an edge, never flagged that a spec was ambiguous - the annoying, valuable questions that mean someone has thought past the ticket. Questioning a spec requires understanding it. His objections only ever arrived afterward, in defense. Cut the layer out and I'd get the same code faster, minus the endless debates. Somewhere in that loop the sentence formed on its own: I had hired Claude, but slower and more expensive.

To be fair to the tool - and to be honest about my own workflow - the tool was never the problem. I use Claude daily. So does everyone on the team whose work I don't re-check. The difference sits entirely in what happens before and after the final output. When I get a generated solution, a list forms in my head of the places it's most likely wrong: the edge case it silently ignores, the API that doesn't behave the way the training data thinks it does, the requirement it quietly rewrote into an easier one. He did no such due diligence. He trusted the output until someone else pointed at the flaw, and he didn't seem to think that checking was part of his job. The model produced, I verified, he forwarded.

This is what AI has done to the profession, and it took a bad hire for me to see it clearly. The visible difference between a junior and a senior used to announce itself in the code. You could tell from the diff who had ten years and who had one. Now both hand you clean, confident, working-looking solutions by the afternoon. The difference that's left is invisible, and it only shows up when something is wrong. Knowing what to distrust is now the entire job.

Trust, once it's gone

The man in our daily standups did not match the man from the interview. The candidate had walked through database indexes and RAG pipelines with confidence. The employee, asked what he did yesterday, produced hesitations and generalities like "still working on it," or "had some issues with the setup", and couldn't summarize his own ticket in two clean sentences. For a while I explained the gap away as nerves, or language barriers, or mornings. But it had a pattern. A model can answer questions about B-trees. It can't answer what you did yesterday.

And yet - every couple of weeks there would be a call where he was fine. He'd explain a decision coherently, catch some small thing, make a reasonable point, and I'd leave the meeting thinking: maybe I've been unfair to this guy. Maybe the env var morning was one bad day, magnified by everything I'd stacked on top of it since. The relief was genuine, and it lasted on average until his next pull request. Then the cycle restarted. I came to recognize it as a carousel - disbelief, then belief, then disbelief again - and to notice how much I wanted the belief half to win. Believing meant the problem would dissolve on its own. Disbelieving meant months of documentation and meetings I could already picture.

Trust is what lets a manager sample. You skim most pull requests, spot-check now and then, take "done" at face value, because the track record covers the rest. With him I had stopped sampling. I read his diffs line by line, re-ran what he claimed passed, re-verified every "done". One person on suspicion costs more oversight than five people on trust.

The part I didn't expect is how unfairly suspicion generalizes. Some of his work was genuinely fine, a config change or a small fix, yet I caught myself second-guessing that too, hunting for the flaw in code that didn't have one. Trust doesn't fail per-task; it fails per-person. Once it failed, there was no setting in which I could take something from him at face value, and rebuilding that was, realistically, no longer on the table.

Which left one decision, and a process famous for taking its time.

Why you can't just fix it quickly

There's a version of this story where the env var morning is followed, a week later, by a handshake and a "see you never" letter. That version exists in no company I've worked at.

Unfortunately the location he worked in had no such thing as a probation period. What existed instead was process: documented feedback, improvement objectives, meetings with agendas and alignment with the people whose job is to make sure no employee is ever removed carelessly. The process isn't designed to reach the obvious conclusion quickly; it's designed to make sure the conclusion is fair.

He understood the process too. The closer it moved, the more friction appeared: time-off requests at delicate moments, sudden personal problems and grievances that had to be heard out, each one consuming a meeting, a week, a cycle of someone else's attention. I can't prove any single one of them was tactical. Collectively, they had excellent timing.

And here is the conflict I didn't expect to be having with myself. The department defending him is the same department that would defend me. I want to work at a company where nobody can be removed on one manager's bad week. But wanting the shield to exist and watching it held, week after week, over someone I knew by then to be functionally a scammer, is an internal conflict I never expected to have.

All the while, the meter ran: my review hours, the tasks quietly routed around him, the senior engineer pulled into second-checking, the teammates watching a colleague produce almost nothing and remain on the team.

What changed

I'm not new to interviewing. I've sat on the interviewers' side of the table well over a hundred times, and I started in an era when remote interviews didn't exist - every single one was a conference room, a handshake, and a conversation. When the industry migrated to video calls and take-home assignments, I migrated with it, because it was efficient and, for a while, it worked.

The take-home assignment is dead. I'll say it plainly because I know how much some teams have invested in theirs. A take-home used to measure how someone works without an audience: how they structure a project, what they test, where they take shortcuts. It now measures whether a candidate can operate a model for an evening, and the answer is always yes. Every submission comes back senior-looking - clean structure, docstrings, a test suite. The signal isn't weakened; it's gone.

What replaced it, for me, is the same process of interviewing I started with 8 years ago: a face-to-face discussion, no augmentation, no second screen - just the candidate's head and mine. And I've changed what I probe for. What I care about is depth and logic - not "what is a database index," but "here's a query that got slower after we added an index; walk me through what could have happened and how you'd go about fixing it." Then I follow the answer downward. Everyone's understanding thins somewhere; the depth where it thins is their level. How they behave at that depth - guessing, bluffing, or saying "I don't know, but here's how I'd find out" - tells me the rest.

That's the calibration I described at the start, and it's the part no tool has managed to fake in a live conversation. A model can hand someone an answer. It cannot hand them the second layer of the answer, or the third, or the ability to notice that my follow-up question quietly contradicted their previous claim.

So that's how I interview for now. Not the production of answers - answers have become the cheapest thing in the profession. I look for the person who looks at a confident, plausible, generated solution and knows where to poke it, how to identify the edge cases where it doesn't work. Everything else, the tools cover.

I'm Mihai Farcas, a software architect from Cluj-Napoca, Romania. Add me on LinkedIn. I make YouTube videos about software architecture and engineering careers. If you've lived through a hire like this one, I'd genuinely like to hear how it went. Also if you've changed your interviewing process because of AI, I'd be curious to know how.