I ask a candidate with seven-plus years of .NET on his resume a simple question: what is the difference between a thread and a task? For a Python engineer, it would be how the GIL works; for React, what causes a component to re-render. There is a pause. His eyes drift slightly off camera, pupils shrink, and two seconds later I get a well-structured, textbook answer that sounds nothing like the person who was just telling me about his last project.

I run a talent network of senior engineers across Europe and Latin America, and the initial screening call is mine. I do it personally, before any candidate reaches my technical screeners or a client. On more than half of those calls, the candidate is using AI when they should not be. Not for a coding exercise, where I would welcome it. But for fundamental questions about the language they claim to be an expert in.

And these are not juniors. We place senior engineers only, because our whole model depends on it: engagements are long term, engineers set their own rates, and we add a small margin on top. That math only works with people who can run on their own. A bad placement would cause headaches that would more than erase the margin, so seniority is not a preference for us, it is the business. And still, I have watched people with twenty years on their resume read me a model’s answers to fundamental questions.

This is not a rant against AI in engineering. My clients run AI-first workflows, and every engineer we place works with these tools daily. My position is simple: the first call happens without AI, so I can see how much they actually know. Use AI to produce code faster.

Do not use AI to simulate the deep knowledge you are being hired to bring, because that knowledge is the product.

If you need a model to explain threads versus tasks, one of two things is true. Either the years on the resume did not happen, or they happened without the understanding they were supposed to build. Neither is an engineer who I would want on my team.

The initial screen exists to answer exactly one question: is this candidate good enough to spend my technical screener’s time on? For you, the reader, swap in your own cost: every candidate who gets past the first call is about to consume hours from your engineering team, the most expensive and least available people you have. That is what the twenty to thirty minutes of conversation protects, and it samples exactly one thing: internalized fluency, the layer of understanding that years of real work deposit and that no prompt can retrieve on your behalf.

That layer is not academic. It is what an engineer reaches for when production is down, the logs make no sense, and the model’s confident suggestion is wrong. Coding speed is increasingly a commodity; AI has seen to that. Judgment about why is what a senior developer actually sells. A candidate who outsources the why on a thirty-minute call is showing you what they will outsource on the job.

AI amplifies whatever type of engineer you have. A good engineer will produce more value. A bad one will create a lot more damage than before.

A bad engineer can do far more damage today than he could three years ago, because the volume of code he ships is no longer limited by his own hands. That is the real reason the fundamentals check has to come first. Test AI use later in your process but the first interview should be a short call with one job: making sure the fundamentals actually exist. You are not vetting whether someone can operate the tools. You are vetting whether they are safe to amplify.

So how do you spot who is using AI to answer fundamental questions? No single tell is proof, and I am not interested in proving motive. But usually you will see some, if not most, of the ones listed below.

I open every call with small talk on purpose. The weather, where they live, how their week is going. It reads as warmth, and it is, but it is also calibration: two or three minutes of casual conversation shows me how this specific person talks when nothing is at stake. Their pace, their sentence shape, where their eyes rest. Every tell below is measured against that baseline, not against some universal standard.

1. 01 - Asking you to repeat the question

   “Sorry, can you say that again? It cut out.” Then a two or three second pause, then a fluent answer. Once is nerves or a real glitch. Consistently asking to repeat or complimenting you “Oh, that’s a good question” is buying time while the tool transcribes and generates.

2. 02 - Reading eyes, not thinking eyes

   People genuinely do look away when they think, so drift alone means nothing. Thinking eyes wander and defocus. Reading eyes fix on a near point and track, and the pupils narrow as they focus on the screen. When the eyes leave me only for technical questions, never during the small talk, the baseline has already made the comparison for me.

3. 03 - Sitting unusually close to the camera

   The face fills the frame. There is a practical reason: text on a second window has to be close enough to read, so the reader leans in and stays in.

4. 04 - Answers with an essay’s skeleton

   The technical answer arrives with a perfect structure: “there are three key differences,” numbered points, a tidy summary sentence.

5. 05 - Fluency inversion

   Flawless on general theory, vague on their own resume. Ask what broke on the project they listed and watch the confidence evaporate. The model knows the language. It does not know their life.

6. 06 - Perfectly balanced answers to pick-a-side questions

   Ask which of two tools they would choose for a job: EF Core or Dapper in .NET, FastAPI or Django in Python, Redux or plain context in React. A real senior picks a side fast, with a story attached: “Dapper, because EF Core burned us on a migration once.” Years of production work leave people with preferences, even grudges. An AI-assisted answer does the opposite: a polite summary of both options’ pros and cons that commits to nothing, because the model has no history with either. A perfectly balanced answer to a “which would you pick” question means nobody with real experience is talking.

7. 07 - The loop-back

   Ask a question, then a follow-up on a different point, then go back to the first question. Someone who answered from their own head repeats themselves effortlessly. An assisted candidate falls apart: the tool is now showing the answer to the second question, the first answer was never theirs, and there is too much to juggle live.

8. 08 - Unsure followed by a precise answer

   The candidate will at first say “I don’t know” or “Not sure” or give you the wrong answer but then a few seconds later give a very precise right answer. For example, you ask if you can await inside a lock. They start with “I think so,” pause, then suddenly flip to a precise no, you’d get a compilation error, without being able to explain why.

One process note: I say the rules out loud at the top of the call. No AI on this call, cameras on, and it’s okay if you don’t know everything, just say I don’t know. Real seniors take that offer and name their gaps, and that raises my confidence rather than lowering it. Saying it out loud also removes all ambiguity about what happens afterward.

Coding speed is now a commodity. Deep knowledge is what the developer brings, and it is the one thing the screening call exists to find. If you run screening calls yourself, the adjustment is small. Open with a couple of minutes of small talk and treat it as your baseline. Say the ground rules out loud, including that not knowing is fine.

What you really want to find out is if all the tools disappeared tomorrow, would you still trust this person to solve hard engineering problems?

If the answer is yes, AI will make them even better. If the answer is no, AI only hides the problem long enough for it to become someone else’s.