Software Developers, Interviews and the LLM Problem
A developer I know spent eleven weeks on one application last autumn. Four technical stages, a take-home project she was told would take "about four hours" (it took fourteen), a system design session and a final chat with a VP who had clearly not read her CV. She got the job. She also calculated, afterwards, that she'd spent roughly 60 unpaid hours proving she could do work she'd already been doing for nine years.
Underneath all of it is a question nobody has agreed an answer to: are you allowed to use Claude or Codex in the interview, when you'll be using it every single day in the job?
The tooling changed faster than the hiring did
Every serious engineering team in Britain now assumes LLM assistance. GitHub Copilot, Cursor, Claude Code, whatever has shipped this quarter. Stack Overflow's developer survey has tracked this shift from curiosity to default in under three years, and the 2025 figures put AI tool usage above 80% amongst professional developers.
Hiring processes have not kept up. Plenty of firms still run a 45-minute live coding round where you're asked to reverse a linked list in a browser window with autocomplete switched off. It tests a skill that has roughly the same commercial value as neat handwriting.
The mismatch creates a genuinely awkward problem for candidates. Use the tools and you might be disqualified for cheating. Don't use them and you look slow next to someone who did.
What the inside of a hiring funnel actually looks like
There's a blog post doing the rounds, The Cost of Getting a Job Today, written by someone who has sat on the employer side of this. The honest bit is the arithmetic: the sheer volume of applications now arriving per role, and what that volume does to the humans doing the screening.
When a mid-level backend job pulls 900 applicants in a fortnight, nobody reads 900 CVs. They read 40. The other 860 are filtered by keyword matching, by an ATS, by a recruiter scanning for twelve seconds, or increasingly by an LLM summarising candidates for a hiring manager who has eleven other things on.
So we've arrived somewhere faintly absurd. Candidates use AI to write applications. Employers use AI to read them. Both sides then insist the other side stop.
The cost is being pushed onto the candidate
The current process transfers an enormous amount of unpaid labour from the employer to the applicant, and it's doing it at exactly the moment the UK tech market can least afford the friction.
The result is a hiring model that quietly favours people who can afford to be unemployed for six months, or who have the energy to do a 14-hour take-home after their actual job finishes at seven. That is not a meritocracy. It's an endurance test with a filtering bias nobody designed on purpose.
What good employers are doing instead
Some have worked it out. The better processes I've seen described in the past year share three features:
- Paid take-homes, or take-homes capped at genuinely two hours with a hard stop
- AI-permitted pairing sessions where the interviewer watches how you prompt, verify and reject model output
- A single technical round instead of four, with the decision made by people who were in the room
That middle one is the interesting development. If the job involves driving an LLM, then watching someone drive an LLM badly is extremely informative. The candidate who accepts the first suggestion without reading it reveals themselves in about ninety seconds. So does the one who can't explain why they rejected it.
How to handle the AI question in your own interviews
Ask, early, and ask directly. Something like: "Do you want me to work the way I normally work, which includes an assistant, or would you prefer I didn't?" This does two things. It removes the ambiguity, and it signals that you have a considered position on tooling rather than a guilty one.
If they say no tools, respect it completely. If they say yes, then your job is not to produce code fastest; it's to narrate your judgement out loud. Say why you're asking the model for a particular shape of solution. Say what you're checking for when it comes back. Say when it's wrong and how you spotted it.
On take-homes, use whatever you like, but understand you will be asked to defend every line in a follow-up call. The failure mode is not "used AI." The failure mode is submitting 400 lines you cannot explain.
Your CV is now being read by a machine first
Write for both audiences. Keep the structure boring and parseable: standard headings, no columns, no graphics, a plain chronological history with dates. Then make the content specific enough that a human stays interested past the first third.
Name the stack, name the scale, name the outcome. "Reduced p95 latency on the payments API from 800ms to 140ms, serving 2m daily requests" beats "worked on performance improvements" in every screening system ever built, machine or otherwise.
And put your AI tooling on there. In April 2026, a developer who doesn't mention how they work with LLMs reads as either out of touch or oddly coy. A line under skills covering the tools you use and what you use them for is now standard, not showing off.
The one thing to do this week
Record yourself solving a medium-difficulty problem with an LLM open, talking the whole way through. Fifteen minutes. Then watch it back with the sound on.
You will hear exactly what an interviewer hears: whether you're thinking or just typing. Most developers have never heard themselves do this, which is why so many of them go quiet in pairing sessions at precisely the moment the interviewer is deciding. Fix that, and you've fixed the only part of the modern technical interview that's genuinely within your control.
Sources
- Office for National Statistics, Vacancies and jobs in the UK (monthly labour market statistics), ons.gov.uk
- Stack Overflow, Developer Survey 2025, survey.stackoverflow.co
- CIPD, Resourcing and Talent Planning Report, cipd.org
- Weli, The Cost of Getting a Job Today, weli.dev/blog/the-cost-of-getting-a-job-today/
- BCS, The Chartered Institute for IT, commentary on AI and the UK technology workforce, bcs.org