Frontend Interviews Should Measure Judgment, Not Memory, in the AI Era

I’ve had around ten frontend interviews lately, and too many of them felt like they were designed for a job that no longer exists.

React live-coding, LeetCode-style puzzles, and “please build this page from mocked API data” exercises all seem to assume the most important thing an engineer can prove is how fast they can type code from memory. That is a weak signal for senior frontend work, and in the AI era it is getting weaker.

The interview format is behind the job

For the past six months, I’ve been using agentic and AI-assisted coding so much that I rarely type code by hand anymore. Going back into interviews where AI was prohibited felt almost like regressing in time.

It wasn’t that I couldn’t do it. I’ve been writing React for more than ten years. It was that the exercise pushed me to focus on details that matter less and less to the actual work: variable names, trailing commas, formatting habits, and the mechanics of typing out components one by one.

That mismatch is the core problem. Engineers have spent decades arguing about tiny implementation details that don’t matter for most applications. The end user does not care whether the codebase is Next.js, React, PHP, or C++. They care whether their problem gets solved.

In that sense, senior engineers are becoming a little more like product owners. Or maybe the better way to say it is this: better engineers are already thinking like people who solve problems for other humans, not for machines.

A mocked API page is not a senior signal

One interview asked me to build a React page that showed a list of items from a mocked API. AI use was prohibited.

That kind of exercise can be useful in a very narrow sense, but it barely reflects how senior frontend work happens now. In practice, that task can be done incredibly fast with AI tooling. So what exactly is the interview measuring when it asks me to do it slowly, by hand, under observation?

What frustrated me most was that the format left no room to show actual strengths. I would have preferred something more interactive, where the interviewer pulls fundamentals out of me and coding stays in the background instead of becoming the whole point.

A senior frontend interview should make room for questions like:

• How do you decide what matters when the codebase, the product, and the org all pull in different directions?
• How do you trade off technical purity against business reality?
• How do you explain your choices to people who do not think in code?

Those are much closer to the work.

The three signals senior frontend hiring should measure

For senior frontend roles, I think interviews should focus on three things.

1. What do you decide to spend time on?

This is about how a senior engineer handles ambiguity.

When there’s platform work, feature work, alerts, user feedback, technical debt, and competing priorities, what guides your decision? Do you wait for someone else to tell you what matters, or do you build an opinion from data and organizational input?

A strong answer shows that the candidate can use signals from the company to align themselves with what’s actually breaking, what’s working, and what trends matter. A weaker answer stays trapped in short-term execution: I deployed my thing, what’s next, who do I ask for more work.

What matters here is not whether someone can recite a perfect prioritization framework. It’s whether they can form a view.

2. How do you handle politics and conflict?

“Political skill” sounds cynical, but I mean it in a practical way. Companies are full of humans, and humans disagree, misread each other, and attach emotion to decisions.

Good engineers don’t just solve technical problems. They help smooth rough edges. Sometimes that means convincing non-technical people. Sometimes it means handling technical tradeoffs that turn into interpersonal friction. Sometimes it means knowing how to move a decision forward when alignment is messy.

A strong interview prompt here would surface a situation that was difficult or almost impossible to solve because of the people involved. I’d want to hear what the candidate did, what they tried when the first approach failed, and what they learned.

A weak answer tends to blame others or external circumstances. That’s usually a sign the person is not reflecting on the level of influence they actually had.

3. Can you adapt when the company changes?

The pace of change is too high now to treat adaptability as a soft bonus.

Org changes, migrations, shifts in company culture, changes in technical direction—these are not edge cases. They’re part of the job. I want to know whether an engineer can keep adding value when things are uncertain, messy, or even when they disagree with the direction.

A strong answer shows that the candidate can bring order to chaos, contribute even without full conviction, and know when to push versus when to wait. A weak answer creates more chaos in a situation that is already stressful.

That’s not about loyalty. It’s about whether the person can keep moving with the company while still thinking clearly.

Take-home exercises ask too much and reveal too little

I don’t believe much in take-home exercises because the effort is asymmetric.

Candidates can spend hours on them. Interviewers often spend minutes reviewing them.

That imbalance bothers me. I want candidates and interviewers to be equally invested, regardless of market conditions. If you’re asking for serious time from someone, the process should show serious attention in return.

This is one reason I prefer more interactive interviews. They’re better at showing how someone thinks in real time, and they don’t force a candidate to do unpaid work just to prove they can care.

The company should be tested too

One thing that stood out across these interviews: almost nobody wanted to talk openly about AI-assisted coding, even though many companies are already using agentic tools internally.

That silence is part of the problem.

If a company is interviewing in 2026, it should be able to answer a basic question: how have your processes changed now that the work has changed? If the answer is “we haven’t adapted,” then the interview process is already out of date.

My view is simple:

• allow copilots or similar tools where that matches real work,
• ask explicit questions about AI-assisted workflows,
• and stop pretending old-school interview formats are neutral.

If the whole industry is adjusting, the hiring process should adjust too.

What better frontend interviews could ask instead

I’m not saying senior frontend interviews should have no coding at all. I’m saying coding should not be the center of gravity.

A better interview would ask questions like:

• What do you use to decide what deserves your time during the week?
• Tell me about a time technical tradeoffs turned into conflict. What did you do?
• How have you handled a major org change or migration when the direction wasn’t fully clear?
• How are you using AI tools in your workflow today?
• What would you want a company to say about its use of copilots or agentic coding tools?

For senior candidates, those questions produce much richer signal than asking them to recreate a small app from scratch while pretending their actual workflow doesn’t exist.

For junior roles, maybe the balance is different. Foundational coding skills may still deserve more weight there. But for senior frontend engineers, the interview should look much more like a conversation about judgment and operating style than a memory test.

The point is better signal, not better memorization

The real test of a frontend engineer now is not whether they can perform code from memory under pressure.

It’s whether they can make good decisions, navigate people, stay effective through change, and use the tools that actually exist in the job.

If interviews keep measuring the wrong thing, they will keep selecting for the wrong thing. And in the AI era, that gap is only going to get more expensive.