Interviewing in the age of AI | dein.frSkip to main contentInterviewing in the age of AI

code<br>Charles-Axel DeinMay 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",...