Interviewing in the Age of AI

Interviewing in the age of AI

code

Charles-Axel Dein

May 28, 2026

Given the speed at which AI models and tooling evolve, will engineers still write code – let alone review – in six months? And, if such a core skill disappears, should companies evolve their interviews?

While most companies have chosen the status quo (including the very companies leading this revolution11. According to Anthropic's own hiring guidelines, the take-home should be completed "without Claude unless we indicate otherwise".), some are embracing the new world and creating interviews where AI usage is allowed, encouraged, or even required. AI proficiency sometimes becomes the main subject of the interview.

In this article, I want to convince you that you should generally keep AI away from your interviews, and I will give you some concrete ways to adapt interviews to AI.

Two dimensions for good interviews: signal quality and cost to company

First dimension: signal quality. For a given set of skills, the best interview questions help you identify strong candidates, ignoring noise (e.g., aspects that are not critical for the role or easily teachable).

There are some sub-dimensions impacting signal quality:

Invulnerability to interview-specific preparation: if the interview's performance is primarily driven by the amount/effort of preparation that goes into it, you risk getting signals only about that trait.

Realism: while interviews should resemble day-to-day activities, it is not an end in itself. Case in point: the infamous "algorithm & data structure" interview has remarkably resisted throughout the years - despite being a skill that is rarely used directly on the job.

Equality: some candidates are better prepared for your interviews, because they have prior domain expertise, they paid for mentoring, they have more time, they found your interview questions online, or they know someone who went through the process recently. In an ideal world, the playing field is level for all candidates.

Difficulty: good interviews are usually difficult enough that the majority of candidates fail. Difficulty is achieved through multiple means. The best approach remains broad and ambiguous problems requiring multiple insights to solve.

Second dimension: cost to company. Interview questions require a significant time investment:

Designing a first draft and getting approval to experiment with it

Creating a scorecard across roles, levels, etc.

Testing it on some first internal and external candidates

Documenting and training interviewers

This investment has to be sustained across time, as questions and scorecards are continuously calibrated.

Cost to company has some sub-dimensions too:

Difficulty: creating questions is one thing, creating a difficult enough question is an even bigger challenge. Two irrelevant extremes would be an interview so easy everyone passes, or one so hard nobody does. Both extremes waste everyone's (the company's, the interviewer's, the candidate's) time.

Appeal to candidate: interview processes that require too much time from the candidate risk turning away good engineers and hurt conversion rates. The same goes with boring interview questions (especially for take-home). Questions say something about your engineering culture - bad questions can lower your chances to close.

Those two dimensions are not fully independent. Difficulty, for instance, impacts both: difficult interviews let strong candidates shine, but might result in false negatives.

Interviews do not have to be perfect. There will always be false negatives and false positives. There isn't much you can do to identify false negatives. Having a good onboarding process, together with clear first semester milestones, ensures that you quickly manage out false positives.

A typology of interviews

Take-home interviews

Take-home: the candidate is asked to submit a solution to (1) an ambiguous problem (e.g., some product specifications), (2) complying with a few technical constraints (e.g., a shortlist of programming languages).

Take-home challenges are often followed by a review interview during which the candidate presents their work and is asked to make some modifications on the spot.

Signal quality: high (before AI)

They provide very broad signals (e.g., design, coding, attention to details, testing).

Candidates having spent six hours or more on an exercise demonstrate motivation.

Cost to company: medium

Their assessment can be automated.

Since the artifact (usually, code) can be reviewed asynchronously, they're easier to coordinate and calibrate.

They might turn away candidates.

As we'll see, they're very vulnerable to AI and motivated individuals.

Live exercise interviews

Live exercise (e.g., algorithm & datastructure, live coding, system design, postmortem review, usually over one hour). The candidate is provided with a problem (e.g., "design Netflix's architecture", "write a rate-limiter") and solves it on the spot, in front of the interviewers.

Signal quality: medium

They're quite objective when designed and orchestrated properly.

The signals are more focused, though (they're usually focused on one topic)

Cost to company: medium

You need a lot of different questions to be less vulnerable to candidate preparation.

To reduce costs, some companies use automated services22. Something I am quite opposed to. But that's for another article..

Presentation interviews

Presentation (e.g., describe a project you drove, diagram an architecture, "tell us about a time when...") puts the candidate fully in control of selecting the problem and the answer.

Signal quality: low - the interview has more failure modes than other interview types:

The candidate has never worked on an interesting problem (e.g., they're too junior).

The candidate chooses an uninteresting problem.

The candidate overstate their impact or contribution33. "The most common hiring mistake is hiring good interviewers.", How to Hire, Henry Ward.

The candidate under-prepares the presentation.

The candidate is a strong communicator, but not a strong doer.

The interviewer does not assess correctly because they lack domain knowledge.

Cost to company: low

There isn't much to prepare from a calibration standpoint.

There are many strategies to prevent and mitigate lower signal quality, in particular, asking the candidate to reflect on their solution (e.g., "what would you do differently") or asking hypothetical questions (e.g., "what if we change requirement X?"). In that case, the question becomes closer to an uncalibrated live exercise.

This interview requires a lot more effort and expertise from the interviewer.

Not an interview type: "come work with us"

Actual work: come work for us for a week (paid). Used by companies such as Linear.

Signal quality: high

Cost to company: high

Most companies mix interview types

Most companies use a mix of those interview types. Live exercises dominate, though.

Interview type Signal quality Cost to company

Live exercise Medium Medium

Take-home High Medium

Presentation Low Low

Actual work High High

Unrelated to AI: you need to assume your questions will leak

It's only a matter of time before your questions leak. Websites such as Glassdoor list all your interview secrets. Candidates go through your interview process just so that they can sell them. You could bury your head in the sand and ignore this, but then your interview signals will get weaker over time, and the main driver for interview performance will become "did you bother searching for our interview process".

There are multiple tactics to address this.

Tactic: Control the preparation. Level the playing field by either including one presentation in your mix, or by providing precise interview guidance (e.g., "system design will focus on databases", "algorithms will be about graphs") 44. In The Hiring Post — Quarrelsome, Thomas Ptacek recommends starting the process with 30-45 minutes of director-level time before any screening begins..

Tactic: Have many different questions for a given interview type and regularly archive old questions. If candidates can't accurately predict the question, they'll have to broaden their preparation, which is exactly what you want. Evidently, this is not free.

Tactic: Make it harder to leak. For example: bring candidate onsite, use whiteboards, have the most vulnerable questions at the end of the process (less candidates, so lower probability to leak).

AI coding is threatening current interview models

Interview type Signal Cost Vulnerability to preparation/AI

Live exercise Medium Medium High

Take-home High Medium High

Presentation Low Low Low

Actual work High High Low

(1) Take-homes become too easy for candidates, and too costly for companies. In 2026, most submissions are probably AI-generated or at least AI-aided. It is only a matter of time before your currently-resisting challenge is solved by the next model release.

Consequently, most candidates will pass this first step. You'll have to spend a lot of time reviewing those. You could be tempted to have AI review take-home AI-generated submissions, but that would be absurd.

AI coding shifted the cost of those interviews from the interviewee to the interviewers. Taking inspiration from Brandolini's law:

The amount of energy needed to refute bad code is an order of magnitude bigger than that needed to produce it.

(2) If software engineers spend less time crafting code, it seems natural to deprioritize live-coding exercises. We don't ask candidates to write machine code – we use higher level languages. Wouldn't it make sense to adapt the tooling allowed during interview to match what engineers use day-to-day?

(3) Once a question leaks, AI is a powerful coach. It used to be quite time- and resource-intensive to (1) find the interview questions and (2) prepare them. Nowadays, candidates get the most powerful (and cheap!) help there is with AI.

How the classical school evaluation model resisted technology

Here it is useful to make a parallel with the academic model. Having only studied in France, I will use it as the main example. Most French high school and college exams look the same:

No material (courses, books, etc.) allowed.

No tools authorized (in particular, calculators are very rarely allowed).

Content not known in advance (everything studied so far is fair game).

Content can't be guessed (each exam is different, and used only once).

Problems are broad and ambiguous. For instance, the queen of French literary exams is the dissertation55. "The essay is the most personal and most elaborate form of the philosophy student's work.", Anatole de Monzie, Instructions ministérielles, 1925, which involves writing a 5-10 pages essay based on a one-sentence subject (e.g., "AI & software interviews"). This format exists since 1830. Scientific exams are roughly the same: three or four ambiguous problems to solve.

Those "live exercises" are complemented with other forms of evaluation (e.g., take-home, multiple-choice knowledge questions, group exercise, presentations) but they're the exception, not the rule.

Re-using our typology:

Signal quality: high

The preparation space is very broad and requires sustained effort.

Cost: very high

A new subject (and scoring guidance) has to be designed for each exam.

All candidates go through the same exercise at the same time (totally impractical for company interviews).

What's fascinating about this model is that it hasn't changed that much, even with leapfrog improvements in cognitive tooling ("copy-pasting", Internet, calculator, solvers, etc.). I think the reasons are the same as the ones I will describe below: education should focus on foundational skills, not tools du jour. This approach is consistent with an Aristotelian model focused on judgment (phronesis) rather than memory (mneme).

Why companies should limit AI usage during interview

A useful distin

[truncated for AI cost control]