The double bind, and why it is not your fault
A GitKraken survey of 554 developers and engineering leaders found that 96.4 per cent of organisations use AI coding tools. So the work on your CV was almost certainly produced with assistance, the work at the company you are interviewing with is almost certainly produced with assistance, and both of you know it. Yet the interview format — a person asking you to account for work you did — was designed for a world where the person typing and the person deciding were the same person.
Candidates therefore get caught between two failure modes. Describe the work accurately, say an agent produced the first draft of the retrieval layer, and you hand an interviewer with an unexamined bias a reason to discount everything that follows. Describe it in the old vocabulary, say "I built a retrieval layer", and you are either being imprecise about something that will resurface in the technical round or quietly signalling that you have not changed how you work since 2023. The discomfort is not a character flaw. It is a gap in the process.
The way out is not a clever form of words but a shift in what you make the subject of the sentence. What follows is that shift, an answer shape you can practise, five realistic questions with weak and strong versions of each, a plan for rounds where assistance is restricted or banned, and the CV changes that stop the conversation going wrong before it starts. It sits alongside our guides to live coding and AI-assisted rounds and the five question clusters that structure most AI engineering loops.
What the interviewer is actually screening for
When an interviewer probes your AI use, they are almost never running a purity test. Very few hiring managers in Bengaluru, Hyderabad, London or Manchester believe typing code by hand is a virtue in itself. What they are doing is far more specific, and once you see it the question stops feeling hostile.
They are testing whether you can defend decisions you did not personally type.
An engineer who delegated generation but owned the architecture, the constraints, the review and the verification is an asset: the delegation makes them faster without making them less accountable. An engineer who accepted output they cannot explain is a liability, because on the day production breaks at 2 a.m. nobody in the room understands the system. The interviewer is working out which of those two people you are, and the AI question is simply the fastest available probe.
Hiring managers across 2026 have converged on a related set of production signals: error handling, evaluation, deployment, structured thinking. Not tutorial completion, not framework name-dropping, not lines of code. The most reported differentiator is proof that you measured your work — a golden set, an LLM judge, a regression gate that fails the build. Those artefacts are what prove ownership of AI-assisted output. If you have never built one, our guide to an evals portfolio as proof of work is a better use of a fortnight than any amount of interview rehearsal.
The probe is often disguised. "How did you approach this?", "Talk me through your process", and "What was the hardest part?" are all the same question wearing different clothes. If you answer them with a narrative of features delivered rather than decisions made, you will have failed the screen without ever hearing the word "AI" in the room.
The core principle: own the judgement layer
Here is the reframe, and everything else in this guide is an application of it. Do not talk about tools. Talk about decisions and verification.
Generation has become cheap and abundant. Judgement has not. The scarce, hard-to-hire capability in an engineering organisation is now the layer above the code: deciding what should exist, choosing between approaches under real constraints, spotting the failure mode that is not in the happy path, and proving afterwards that the thing works. That layer cannot be delegated, and it is the layer you are being hired for.
So the grammatical subject of your sentences should be a decision, a constraint or a check — never a tool. "I used Claude Code to build the ingestion pipeline" puts the tool in the subject position and makes you the operator. "The ingestion had to survive malformed PDFs from three different vendors, so I split parsing from validation and put a golden set of forty known-bad files in CI — the agent wrote the parsers, I wrote the contract they had to satisfy" puts you in the subject position and reduces the tool to a detail, which is what it is.
The second version is not less honest; it discloses the assistance explicitly. It is simply more informative, and the extra information is all about you. That works because it is true: on any piece of work you did well you genuinely made the decisions, and the reason you rarely say so is that decisions feel obvious in hindsight in a way that shipped features do not.
Before any interview, write down three decisions per project that a competent engineer could reasonably have made differently, and what would have gone wrong with the alternative. If you cannot find three, you either did not own that project or you have not thought about it hard enough — and both are worth discovering at your desk rather than in the room.
The Judgement Trail: a five-beat answer shape
Improvising this under pressure is difficult, so use a fixed shape: five beats, in order, roughly ninety seconds end to end. Call it the Judgement Trail, because what it leaves behind is a visible track of decisions the interviewer can follow and interrogate.
| Beat | What it answers | What it sounds like |
|---|---|---|
| Context | What was genuinely hard here, and under what constraint? | "Support tickets in three languages, and the SLA was a first response inside four minutes." |
| Decision | What did you choose, and what did you reject? | "I ruled out fine-tuning because the label set changed monthly, and went with retrieval plus a small classifier." |
| Delegation | What did you hand to the assistant, and where did you draw the line? | "The agent generated the connectors and the test scaffolding. I wrote the routing logic and the prompt contract myself." |
| Verification | How did you know it worked, and what caught the mistakes? | "A hundred-and-twenty-case golden set, an LLM judge on tone, and a regression gate that blocked merges on a two-point drop." |
| Outcome | What changed for the business or the user? | "Manual triage time down about forty per cent, and the on-call rota stopped getting paged for misroutes." |
Two notes. Drop the Delegation beat only when the assistance was genuinely trivial — a Trail with a suspicious gap where the delegation should be is worse than no disclosure at all. And frame the last beat as an outcome, not a metric: "reduced manual review time by forty per cent" lands harder than "achieved 91 per cent F1 on the test set", because the first is a business result and the second only means something to people who already know your dataset. Keep the F1 in your pocket for when an engineer asks.
Rehearse the Judgement Trail out loud for your three strongest projects until each runs to about ninety seconds without notes. Out loud matters. The gap between a story you can think and a story you can say under mild social pressure is much larger than people expect, and interviews are conducted in the second mode.
Five questions, and how to answer them
These are the versions that actually get asked, drawn from AI engineering loops at Indian GCCs and UK product companies alike. For each: a weak answer, why it fails, and a rewrite. Read the weak ones carefully — most are not obviously bad, which is exactly why they cost people offers.
1. "Walk me through this project on your CV."
"So this was a document Q&A system for the legal team. I used LangChain and Claude, set up a vector store, chunked the documents, and built a Streamlit front end. It worked pretty well — people liked it."
Why it fails. Every sentence is a tool or a component, and the whole thing could describe a weekend tutorial. No constraint, no rejected alternative, no evidence beyond "people liked it". An interviewer hearing this has learned nothing about your judgement, so they will assume there was none.
"The legal team needed answers with citations they could defend to a client, so an unsourced answer was worse than no answer. That constraint drove everything. I rejected naive chunking because contract clauses lose meaning when they are split, so I chunked on clause boundaries and carried the parent section as metadata. The agent wrote the parsers and most of the ingestion; I wrote the citation contract and the eval harness, because those were the parts where being wrong was expensive. I built a set of ninety questions with known correct citations and gated deployment on citation accuracy rather than answer quality. Review time on a standard contract went from about two hours to twenty minutes, and in six months we have not had a fabricated citation reach a client."
2. "Did you use AI to write this take-home?"
"Only for boilerplate, really. The core logic is all mine — I just used it for autocomplete and to save time on the tests."
Why it fails. It is defensive, vague, and very likely an understatement the interviewer can test in four minutes by pointing at any file and asking why. "Only" and "just" are the words of someone who thinks they have done something wrong, and interviewers hear that tone before they hear the content. Minimising also sets a trap: you have implicitly claimed authorship of everything you called "core logic", so the first thing you cannot explain becomes a much bigger problem than it needed to be.
"Yes, substantially — the brief did not restrict it and it is how I work. I wrote the interface and the data model by hand because those are the decisions the rest of the code inherits, and had the agent generate the implementations and the test scaffolding against them. Then I reviewed everything as if it were a colleague's pull request; I rewrote the retry logic because the generated version retried on validation errors, which would have hammered the upstream API for no benefit. Happy to walk through any file you want, including that one."
3. "Honestly, how much of your code do you write yourself these days?"
"Maybe thirty per cent? The tools have got good enough that I mostly review and correct now."
Why it fails. The number is a trap whatever you pick. High, and you sound like you have not adopted the tooling your future team runs on. Low, and you have told a nervous hiring manager that most of your output comes from something they could licence directly. The percentage also carries no information about quality — a careful engineer at twenty per cent and a careless one at ninety are indistinguishable by it, which is precisely why it is the wrong metric.
"I have stopped tracking that, because typing is not the constrained resource any more — deciding what to build and proving it works is. What I would say is that the amount of code I read carefully has gone up, not down. On the ingestion rewrite last quarter I probably typed a fifth of what shipped, but I wrote every interface, I rejected the first design because it made backfills impossible, and I put the regression suite in front of it that has since caught two bad merges. If it is useful I can show you where I drew the line and why."
4. "Explain what this function does, and why you chose this approach."
"That one takes the raw events, groups them by session, and then applies the scoring. It is a fairly standard approach — it seemed like the cleanest way to do it."
Why it fails. The first half paraphrases code the interviewer can already read; the second half is the sound of someone who did not choose anything. "It seemed cleanest" is the tell that separates candidates who accepted generated output from those who commissioned it. This question is now a standard follow-up round precisely because it is the fastest way to find out whether you understand what you sent.
"It groups events into sessions before scoring, and the ordering matters: I score per session rather than per event because a single click means nothing and a sequence does. The obvious alternative was a streaming score with a decay window, which I rejected because we needed the score to be reproducible for the audit log, and a decay window is not reproducible if you replay events at a different wall-clock time. The failure mode I am watching is a session that never terminates — there is a two-hour cap in the config for that, and honestly the cap is a guess I would want to tune against real data."
5. "Tell me about a time an AI tool gave you a wrong answer."
"All the time — it hallucinates library functions that do not exist. You just have to check everything it produces."
Why it fails. It answers with a category rather than an incident, and the incident is the point. Everyone knows models invent APIs. "You just have to check everything" is a non-process: it describes vigilance rather than a system, and vigilance does not survive a deadline. The question is an open invitation to demonstrate the verification discipline the interviewer is screening for, and this answer declines it.
"The one that stuck with me was subtle rather than obvious. An agent refactored our chunking and quietly changed the overlap from tokens to characters. Everything compiled, all the unit tests passed, and retrieval quality dropped about eight points on documents with dense tables — which we only caught because the golden set had four table-heavy PDFs in it. The lesson was not 'check the output'; it was that unit tests do not protect a retrieval system, so behavioural evals have to run in CI on the same trigger. We moved them into the merge gate that week, and the gate has since caught two more regressions of the same shape."
The engineers who can tell this story well are the ones getting hired. Make yourself findable.
AI Tech Connect lists AI engineers, founders and researchers across India and the UK — and the people hiring browse it to find them. A profile is free, takes two minutes, and early ones carry a Founding Builder badge.
Become a Verified Builder →Live coding, take-homes and the round where the rules change
Written policy on AI assistance is still inconsistent, and it varies within a single company — a UK scale-up may allow assistance on the take-home and ban it in the live round, while a Bengaluru GCC does precisely the opposite. The most useful thing you can do is ask before the round, in writing. "Can you confirm whether AI assistance is permitted in Thursday's session, and if so which tools?" costs you nothing and reads as professional rather than pedantic. If the recruiter cannot answer, that is itself information.
| Policy | What they are testing | What you do |
|---|---|---|
| Assistance banned | Whether the fundamentals survive without the tooling | Practise cold on one language and its standard library. Narrate as you go — thinking aloud is most of the signal in this format. |
| Restricted (autocomplete yes, agents no) | Whether you can hold the whole problem in your head | Confirm the exact boundary before you start. Say out loud when you are about to use the permitted tool, so nothing looks concealed. |
| Assistance allowed | How you direct it, review it and know when to stop | Prompt out loud. Reject at least one suggestion visibly and say why. Never paste output you have not read in front of them. |
| Take-home, then defence | Whether you can explain code you may not have typed | Review your own submission as a pull request. Three sentences per module: what it does, what you rejected, how it fails. |
The allowed-assistance round is the one people underprepare for, because it looks easier and is not. When the tools are on the table, the interviewer is no longer watching whether you can produce the code — they are watching how you drive. Rejecting a suggestion out loud is worth more than three correct accepts, because it is the only visible proof that you are reading rather than accepting. So is stopping to run something. So is saying "that will work, but it allocates on every call and this is in the hot path, so let me change it."
The take-home defence preparation is mechanical and takes about twenty minutes. Read your submission as if a colleague had sent it, and for each module write down what it does, one alternative you rejected and why, and how it fails. If you cannot write those three sentences for a file, you do not understand it well enough to defend it — go and rewrite that part by hand. Our deeper treatment of these formats is in the LLM system design interview guide, which covers the round where nobody writes code at all and the whole hour is judgement.
If a take-home explicitly bans AI assistance and you used it anyway, say so before the next round and offer to redo the exercise under supervision. It may cost you the process. Concealing it costs you the process and your reputation in a hiring market where the senior AI community in London, Manchester, Bengaluru and Hyderabad is genuinely small and people talk.
What to put on your CV and profile so the conversation starts well
Most of this conversation is decided before anyone speaks. Recruiters spend under ten seconds on a CV, but engage roughly eighty per cent more with GitHub projects that have runnable code or a live demo — which tells you where the marginal hour of effort belongs. A README with a one-command setup and a short recorded walkthrough does more for you than another bullet point.
- Lead every project bullet with a decision or a constraint, not a stack. "Chose retrieval over fine-tuning for a monthly-changing label set; cut triage time about 40%" beats "Built RAG pipeline using LangChain, Pinecone and GPT-4o". The stack belongs in a separate skills line, not in the sentence that is supposed to be about your judgement.
- Make the verification visible. One line per project on how you knew it worked — golden set size, judge, regression gate, the metric that gated deploys. Hiring managers report this as the strongest differentiator, and almost nobody does it. If your repository has an
evals/directory with a real dataset in it, say so in the first three lines of the README. - State your AI-assisted workflow once, deliberately, as a strength. A short line in your summary — that you work with coding agents and own architecture, review and evaluation — sets the frame before anyone else can. It converts an awkward mid-interview discovery into a stated position, and it filters out teams whose policy would make you miserable anyway.
The same three rules apply to a Verified Builder profile, which has one advantage a CV does not: it is public, indexed, and browsed by people who are hiring rather than filtered by an ATS. If your projects show constraints, decisions and evidence, the first conversation starts several rungs up the ladder — you are no longer proving you can build, you are discussing what you decided. If you are moving internally rather than out, the same framing works with your own leadership, as we cover in moving into an AI role without leaving your employer.
"The candidates who make me nervous are not the ones using agents heavily. They are the ones who cannot tell me a single thing they decided. I will happily hire someone who generated eighty per cent of their code, if they can tell me what they rejected, what they measured and what they are still unsure about. The unsure part is often the strongest signal in the whole interview."
— PremKumar, Verified Builder · Chennai, IndiaRead the room: when the team's AI policy is the red flag
The assessment runs both ways, and an incoherent AI policy is one of the more reliable predictors of a difficult first year. You want a team that has thought about the question, not one that merely has an opinion about it. Ask these, and listen to how confidently they answer rather than what the answer is.
- "What is the written policy on coding agents, and who owns it?" A clear answer in either direction is fine. "It depends on the team lead" means there is no policy, which means it will be relitigated in every code review you take part in.
- "How does AI-assisted code get reviewed differently, if at all?" Good teams have adapted — smaller pull requests, stricter test requirements, a rule about explaining what you submit. Teams that have changed nothing are accumulating code nobody understands, and you will inherit it.
- "What did you ban, and why?" The reason matters far more than the ban. "Client data cannot leave our tenancy, so only the approved gateway" is a team with a threat model. "The CTO does not like it" is a team with a mood.
- "How do you evaluate whether it is actually helping?" If they are measuring anything at all — cycle time, defect rate, review load — you are talking to people who think in evidence. Our guide to rolling out coding agents across a team covers what a competent answer looks like from the inside.
- "Was the interview process changed for this, and how?" A team that has redesigned its loop has thought hard about what it is buying. A team using a 2022 take-home in 2026 will make the same lag mistake in its architecture decisions.
One asymmetry worth naming: an interviewer who reacts to disclosed AI assistance with visible disapproval has told you something important and inexpensive to learn. That is not a team where you will be allowed to work the way you work. Thank them, finish the process professionally, and weight the offer accordingly.
Anti-patterns that cost offers
Every one of these has been observed sinking an otherwise strong candidate. Read them as a checklist of things not to do rather than a list of things to worry about.
- Tool-first sentences. "I used X to build Y" makes you the operator of X. Invert it: the constraint or the decision goes first, always.
- Volunteering a percentage. There is no good number to give when asked how much code you write yourself. Reframe to decisions and verification.
- Minimising with "just" and "only". These words announce that you think you have done something wrong, and they invite the follow-up that catches you.
- Submitting code you have not read. The defence round exists to find this, and it finds it quickly. Twenty minutes of self-review is the highest-return preparation available.
- Apologising for the tooling. "I know it is cheating a bit, but" concedes a framing that is not true and that most interviewers do not hold.
- Over-claiming in the other direction. Pretending you hand-wrote something an agent produced is the one genuinely fatal error, because it is dishonesty rather than awkwardness, and it is trivially detectable.
- Treating evals as a nice-to-have. If you cannot describe how you knew something worked, no amount of narrative polish will fix the answer.
- Enthusiasm without a line. Talking excitedly about your agent setup while never mentioning anything you refused to delegate reads as absence of judgement, not fluency.
The market you are interviewing in (as of August 2026)
Three structural facts change how much preparation is rational and how you handle the end of the process.
Entry-level AI roles remain genuinely scarce — roughly 2.5 per cent of postings target zero to two years of experience, while the most common band is four to six years at around 12 per cent of postings. If you are early in your career, the implication is not to give up but to change what you are selling: a portfolio with real evaluation artefacts substitutes for the years you do not have, and substitutes better than another certificate. The route in from an adjacent discipline is usually faster than the route in from nothing, which is why we wrote up the data engineer to AI engineer switch in detail.
Processes are long: time-to-hire for AI roles averages eight to twelve weeks, so run several in parallel and treat no single loop as decisive. Around 70 per cent of accepted offers face a counter-offer from the current employer, so plan that conversation before you need it. When money comes up, ask for the band in the currency and structure you will actually be paid in — fixed plus variable in rupees for a GCC role in Bengaluru or Hyderabad, base plus equity in pounds for a London or Manchester scale-up — because a headline total that hides a large variable component is not comparable to one that does not.
Be careful with published salary figures. Reported averages for AI engineer roles vary by source and methodology, landing somewhere in the region of $206,000 to $231,000 depending on the dataset. Those figures are heavily US-weighted, they mix levels and locations, and they are close to useless as a benchmark for an Indian or UK offer. Cite the range rather than a single number if you cite anything at all, note that the methodology varies, and negotiate against the actual band for the actual role.
A one-week rehearsal drill
None of the above works as knowledge; it works as practice. Here is a week that will materially change how you sound, at roughly an hour a day.
- Day one — inventory. Pick your three strongest projects and write the five Judgement Trail beats for each in full sentences. Do not skip Verification because it is uncomfortable; if it is genuinely empty, note that, because you now know what to build next.
- Day two — find the rejections. Write down three decisions per project that could reasonably have gone the other way, and what would have broken. This is the hardest hour of the week and the one that changes the most.
- Day three — say it out loud. Record yourself delivering each Trail. Aim for ninety seconds. Listen back once and cut every sentence whose subject is a tool.
- Day four — self-review a submission. Take your most recent AI-assisted work and write the three sentences per module. Rewrite by hand any part you cannot explain.
- Day five — drill the five questions. Have someone ask them in random order and answer cold. Ask them to interrupt with "why did you choose that?" at least twice, because that follow-up is where real interviews go.
- Day six — fix the paperwork. Rewrite CV bullets to lead with constraints, add one verification line per project, and mirror the changes on your public profile so the search results match the story.
- Day seven — prepare your questions. Write your version of the five policy questions above and decide in advance what answers would make you walk away. Deciding that while calm is far easier than deciding it while holding an offer.
If the Verification beat came out thin on all three projects, that is the real finding of the week and it matters more than the rehearsal. Build one honest evaluation harness on one project — a golden set you actually curated, a judge you actually calibrated, a gate that actually blocks a merge — and you will have the answer to the hardest question in this guide for years. The ground under these interviews moves quickly, and our AI news feed tracks it; the tooling side of working this way is covered in running parallel coding agents with git worktrees.
The underlying point is simple enough to carry into any room. Nobody is hiring you to type. They are hiring you to decide, to review, and to be the person who can still explain the system when it breaks. Talk about that, disclose the rest plainly, and the double bind stops being a bind.