A mid-level candidate in a remote interview answers "What's the difference between switchMap and mergeMap?" with a flawless definition, after a three-second pause. Two questions later you ask which one they would use in a search bar, and why. Silence. The first question measured how fast they can consult an AI assistant; the second measured what you actually needed to know.
I've sat on both sides of the interview table, and one question keeps coming back to me: today, with an AI assistant in every editor, do the classic interview questions still make sense?
What has really changed
"Textbook" questions — definitions, differences between two concepts, lists of features — were always an approximation: the assumption was that someone who knows the theory can also apply it. That approximation was acceptable when remembering took effort. Today remembering costs nothing: any definition is one prompt away, during the interview and, above all, afterwards on the job.
And that's exactly the point: the developer you hire will work with AI. What matters is no longer what they know by heart, but three things AI won't do for them:
- Judgement: choosing between two correct solutions based on context.
- Verification: noticing when generated code is wrong, even if it compiles.
- Context: understanding the real problem before writing a single line.
Mid and senior: classic questions are no longer enough
For a mid or senior profile, isolated theory questions are almost useless: a good candidate passes them, but so does a mediocre one with a second screen. They shouldn't disappear entirely — they should be used as a starting point for digging deeper. Here are five formats that work.
1. Reviewing AI-generated code
Give the candidate a plausible snippet, the kind an assistant produces every day, and ask them to review it as they would a colleague's pull request:
// Product search bar
this.results$ = this.query$.pipe(
debounceTime(300),
mergeMap(q => this.api.search(q))
);The code works almost every time. A senior should spot that with mergeMap a slow response for "ang" can arrive after the one for "angular" and overwrite the correct results: you need switchMap, which cancels the previous request. Extra points if they ask what happens with an empty string or an HTTP error, which here would kill the stream for good.
The same exercise works on the backend:
async function getOrders(userIds) {
const result = [];
for (const id of userIds) {
result.push(await db.orders.find({ userId: id }));
}
return result;
}Here you're looking for the N sequential queries, the missing pagination and a proposal for a single query using $in. There's no definition to recite: either you see the problem or you don't.
2. Scenarios instead of definitions
Instead of "What is change detection?" ask: "A table with 5,000 rows gets slow when the user types in the filter. Here's the profiler: where do you start?". Instead of "What is Redis?": "We have an in-memory cache and we're going from one to three backend instances. What breaks?". The answers immediately show whether the candidate has solved similar problems or only read about them.
3. The story of a real problem
"Tell me about the hardest bug you fixed in production" is still one of the best questions, as long as you dig with follow-ups: how did you notice it? Which hypothesis did you rule out first? What did you change so it wouldn't happen again? A lived experience survives five levels of "why"; a rehearsed story collapses at the second.
4. Pair programming with AI allowed
Instead of banning tools, allow them and watch how they're used. A 30–40 minute task on a small real repository, with the AI assistant switched on. You're not grading the result but the process: does the candidate read the code before asking? Are their prompts precise or vague? Do they reject a wrong suggestion, or accept it because it compiles? Do they add a test?
5. Trade-offs and decisions
For a senior, what counts is the ability to decide under constraints: "We have two weeks and a team of three: do we rewrite the module or secure it with tests?". There's no right answer: there's reasoning that weighs risk, cost and reversibility, and that's exactly what you want to hear.
Juniors: how the interview should be run
With juniors the problem is the opposite. They have no experience to talk about, and a complex code review would penalise them unfairly. Yet for them the AI risk is higher: it's easy to produce working code without understanding it. The interview should therefore measure understanding and ability to learn, not the amount of knowledge.
A 60-minute structure I use and recommend:
| Time | Activity | What it assesses |
|---|---|---|
| 10 min | A personal or university project: what you did yourself, what you'd do differently | Self-awareness, honesty |
| 15 min | Read a short piece of code and predict its output, line by line | Real fundamentals |
| 20 min | Small task with AI allowed, then questions about every line written | Understanding, verification |
| 10 min | Documentation for an API they have never seen: use it for a simple case | Ability to learn |
| 5 min | The candidate's questions | Curiosity, interest |
An example of a reading exercise, ideal for a JavaScript junior:
for (var i = 0; i < 3; i++) {
setTimeout(() => console.log(i), 0);
}
// What does it print? And with let instead of var?It doesn't matter whether the junior knows the answer by heart (3 3 3, then 0 1 2): what matters is that, with some guidance, they get to explain why — variable scope and asynchronous execution. It's a classic question, but used to make them reason, not to check a memory.
In the AI part, the key question comes after the code: "What happens if the array is empty? And if you get null?". A junior who understood will reason about it, even if they get it wrong; one who just pasted the answer won't know where to start. Either way, you've learned something valuable.
Classic question → updated version
| Classic question | Updated version |
|---|---|
| What is a closure? | This code has a memory leak: where, and why? |
| SQL vs NoSQL? | For this use case, which do you pick and what do you lose? |
| What are the SOLID principles? | This class is hard to test: how would you restructure it? |
| What is lazy loading? | The initial bundle is 4 MB: what do you check first? |
| How does a JWT work? | A stolen token stays valid for 30 days: what do you change? |
What to drop (or nearly)
- Memorised definitions as the only test: they measure searching, not skill.
- 8-hour take-home assignments: an AI finishes them in half an hour, and they penalise people with less free time.
- Live coding without internet or tools: it assesses a situation that never happens on the job.
- Banning AI in the interview and expecting it from day one: it's inconsistent, and the best candidates notice.
In short
Classic questions aren't dead, but on their own they no longer measure what matters. Mid and senior roles call for code reviews, real scenarios and decisions under constraints, ideally with AI on the table to see how they manage it. Juniors call for code-reading exercises, "why" questions and a learning test: not how much they already know, but how quickly and honestly they learn. In a world where code is generated in seconds, real talent is knowing when that code is wrong. If you're preparing from the other side of the table, you'll find technical questions organised by level in the guide to 25 frontend/Angular interview questions.