I run technical interviews for research and engineering roles, which in the last couple of years has become a stranger job than it used to be. Candidates prepare with language models. Companies screen with them. Somewhere in the middle, both sides have quietly lost confidence in what the process is measuring.
This is not a tool roundup. It is an attempt to be specific about which parts of interview preparation a model makes genuinely better, which parts it makes actively worse, and what I can and cannot tell from the other side of the call.
What the "AI in hiring" statistics actually say
You will see a lot of confident numbers about how many companies use AI in hiring. Most trace back to online panel surveys of self-identified business leaders — for instance a ResumeBuilder.com survey reporting that around seven in ten companies expected to use AI somewhere in hiring in 2025. Treat that as a directional signal, not a measurement. These are opt-in samples, "AI somewhere in the process" covers everything from resume search ranking to a chatbot that schedules calls, and the respondent answering for "the company" is often one person guessing.
The honest summary is: some automated tooling is nearly everywhere, fully automated decision-making is much rarer than the headlines imply, and the variance between employers is enormous. Prepare for a human process, because that is still what most of it is.
Where a model genuinely helps
Getting your own stories out of your head. This is the highest-value use and almost nobody does it. Talk through a project out loud, transcribe it, then ask a model to identify what was actually difficult, what decision you made that someone else might not have, and where your account is vague. It is very good at spotting where you skipped the interesting part. Most engineers narrate the architecture and omit the judgement call, which is the only bit I care about.
Adversarial questioning on your own material. Paste in your resume, or a description of a project, and ask for the ten hardest questions someone could ask about it. This works because it is grounded in real content rather than generating generic questions. When I interview, my questions come almost entirely from following threads in what the candidate has claimed. A model can simulate that pattern reasonably well.
Filling in the thing you half-know. You listed a technology two jobs ago and you are rusty. A model will patiently quiz you on it at whatever depth you ask for, which no friend will do for an hour. Verify anything load-bearing against real documentation, because confident wrong answers on technical detail are still a live failure mode.
Background reading. Summarising a company's recent public activity, explaining a domain you are about to interview in, translating a job description written in one industry's dialect. Low risk, real time saved.
Speech habits, if that is your problem. Recording yourself and getting feedback on pace and filler words does work. But this is a polish problem, and polish is rarely why people fail. I have never declined a candidate for saying "um".
Where it makes you worse
Generated answers. Ask a model for a good answer to "tell me about a conflict with a colleague" and you will get a competent, structured, completely generic paragraph. Memorise it and you will deliver a competent, structured, completely generic paragraph — and I will follow up with "what did they say when you told them that?", and the whole thing will collapse, because there was never a real situation underneath it. Generated answers survive exactly one question. Every interview has more than one.
The STAR-ification of everything. A light structure helps rambling answers. But candidates who have drilled on frameworks start narrating in a strange, evenly-weighted monotone where the trivial parts get the same airtime as the crux. Real answers are lumpy: mostly setup, then a long time on the hard part. If your practice partner rewards uniformity, you will learn uniformity.
Confidence in the wrong things. A model will tell you an answer is strong. It has no idea. It cannot see that the interviewer's actual concern was whether you have ever owned something in production, and it will happily validate a polished response to a question you misread.
Over-preparation as avoidance. Two weeks of eight-hour preparation days is usually anxiety with a schedule attached. The returns on interview practice flatten quickly. Past a handful of real practice runs, the marginal hour is better spent sleeping.
The live-assistance problem
There is now a genre of tool that listens to your interview and feeds you answers in real time, marketed with varying degrees of euphemism. I will be direct about this, because candidates seem to think the risk is only of being caught by software.
It is obvious. Not always, but often, and in a very particular way: a pause before every answer, eyes tracking to a fixed point off-camera, and — the real tell — fluent, well-organised, slightly generic prose on a question you would expect someone to have to think about, followed by immediate collapse when asked why. Nobody talks about their own work in complete paragraphs.
What happens next is worse than failing the interview. When I suspect this, I do not accuse anyone; I just ask progressively more specific questions until the thing resolves one way or the other. The candidate usually does not know the interview has effectively ended. And where I have been reasonably sure, that is not a "no for this role" — it is a no permanently, and I have told colleagues at other companies. The asymmetry is brutal: the upside is one job you would then have to actually do, and the downside is your professional reputation with the small number of people who hire in your specialisation.
Take-homes are a greyer area and worth asking about directly. Many teams, mine included, now assume you will use a model on a take-home and care more about whether you understand what you submitted. Say what you used. Every reasonable employer will find that fine, and the ones who do not will have said so in the brief.
What I am actually assessing
It helps to know what the interview is for, because most preparation advice optimises for the wrong target.
I am trying to answer three questions. Can you do the technical work — which the coding or design portion samples, badly but not uselessly. Can you think in public — can you be uncertain out loud, take a suggestion, notice you are wrong, and change direction without either collapsing or digging in. And would working with you be productive for the eight other people already here.
The second one is where most of the signal is, and it is the one candidates prepare for least, because it cannot be rehearsed. When I give a hint, I am not being nice; I am measuring what you do with new information. When I ask "what would break first at ten times the load?", the answer matters less than whether you reason toward it or freeze. A candidate who says "I don't know, but here's how I'd find out" is in a stronger position than one who produces a fluent recitation, and this is exactly the axis on which heavily-scripted preparation hurts you.
So the most useful practice is not more questions. It is doing a genuinely hard problem with another person watching, badly, out loud, until that stops feeling like an emergency.
A prep approach that is proportionate
Spend an hour on the company and the role, enough to ask two real questions at the end. Spend two or three hours getting four or five of your own projects into a form where you can talk about the hard part without notes — use a model here, it is good at this. Do a couple of full practice runs with a person if you can find one, a model if you cannot. Refresh whatever technical material the role obviously demands. Sleep.
That is most of the available benefit. The rest is variance, and variance is not something preparation can remove — some interviews are badly run, some interviewers are having a bad day, and a rejection is much weaker evidence about you than it feels like at the time.
Tags
Taresh Sharan
support@sharaninitiatives.com