Rethinking the Technical Interview for the AI Era

A note from Kate Huang, International CTO and Head of Engineering at Arta Finance, an AI-native wealth management platform for individuals and institutions.

Engineering work is changing quickly. The best engineers use AI to understand complex systems, accelerate execution and extend what they can build, while knowing when to challenge what it produces. Our technical interview needed to evolve with the job.

So we added to it. Candidates still go through our existing coding round, testing the fundamentals without AI. But we now pair that with a second round designed around how engineers actually work today. Candidates work within a realistic, non-trivial codebase, using an AI coding assistant throughout. This lets us see how they navigate complexity, exercise judgment and recognise the limits of the tool, not just how quickly they can produce code.

The response from candidates has been encouraging. Several have told us the process feels much closer to the way they actually work, and we’ve had enough questions about it that we thought it was worth sharing what we changed and why.

Where the old format falls short

For years, the standard engineering interview looked roughly the same everywhere, including here: give someone a hypothetical problem, have them write code from scratch and see how they reason through it.

We still run that round. It tests important capabilities, and it's how we confirm a candidate can reason and code well on their own before AI enters the picture. But on its own, it no longer tests everything the job requires.

Most of our team writes code alongside an AI assistant every day, using it to understand unfamiliar code, scaffold changes, catch mistakes and move more quickly through routine work. The value of the engineer increasingly lies in knowing what to delegate, what to interrogate and when not to trust the answer.

But there is a more fundamental difference too. Most engineering work starts with a system someone else built: understanding how it works, deciding what should change and improving it without breaking what is already there. A candidate designing a hypothetical system and writing isolated code in a blank editor doesn't show us that. 

So we added another round to close that gap.

The new approach

In this round, candidates work inside a mock project designed to resemble the complexity of a real system, with interdependent features, technical debt and the kinds of imperfections engineers encounter in production. Rather than designing a system from scratch, they have to understand an existing one, make sound architectural decisions and use AI to improve it.

Here is roughly what it looks like in practice:

Format. This is the second of two onsite technical rounds, running 60 to 90 minutes, with the candidate using an AI coding assistant throughout. Candidates get a short window to orient themselves in the repository before the interviewer joins, and then we work through the problem together.

The task. Candidates are given new business requirements that require meaningful changes to the existing system. They need to understand how it works, think through the architectural implications and decide where to focus their time.

We expect them to use AI to explore the codebase and implement part of their approach, while explaining how they would validate their work and manage the risks introduced by their changes.

What we are actually evaluating

This is not a test of whether someone can prompt an AI model. Most people can learn the mechanics quickly.

What matters is how an engineer works when AI is part of the process: where they rely on it, where they challenge it, and where they apply their own judgment.

We look at how they reason through a system that doesn't have one right answer and defend their choices based on the trade-offs. We look at whether they use AI to move faster through the parts they understand, while keeping their attention on the decisions that require real judgment. And we look at whether they recognise when the tool produces something plausible but wrong.

AI accelerates the work, but a strong engineer still owns the result.

The interviewer's role changes too. With senior candidates, they act more like a product manager, providing business context without helping with technical navigation. Junior candidates get more support with the architecture and setup. We expect the degree of independent navigation to increase with seniority.

Why we are sharing this

The way engineering teams create value is changing, and hiring needs to change with it. The fundamentals still matter. But we also need to understand how engineers navigate systems they did not build, where they apply their judgment and how they use AI without handing over accountability.

The process itself will keep evolving. It already has. In the short time since we introduced this round, the models candidates use have improved enough that parts of the exercise became easier than we intended. We have raised the bar more than once.

That is exactly the point. As the work changes, our definition of excellence needs to change with it.

If you are rethinking your own technical interviews, take what is useful, adapt it and share what you learn. We are still learning too.