Our pair programming interview isn’t the same as a lot of other companies. We’re not doing leetcode, it’s not just a “complete this problem and you pass”. It’s a real step in our process for evaluating how well candidates will fit in at Omnea. We're interested in how candidates approach:

  • breaking down problems
  • edge cases and their business implications
  • communicating their thought processes and collaboration
  • design decisions and trade-offs
  • balancing code quality with making pragmatic progress

Over the past year or two, how we write code at Omnea has changed dramatically with the rise of AI coding agents. In particular, at the end of 2025/start of 2026, coding agents like Claude Code had advanced to a level that a lot of changes were being fully written by AI with humans supervising, rather than humans writing with AI assistance.

We want our programming interview to reflect how we work, so a few months ago we started allowing candidates to use AI coding tools in this process. We’re open to any type of tools, from none at all, to autocompletes, to full coding agents. It’s been a really interesting experience seeing how different candidates approach this opportunity.

"What we’re looking for hasn’t changed, how we expect candidates to demonstrate it has."

We've seen candidates do really well without AI. We've also seen them do really well without writing a single line of code by hand. All on the same problem.Currently, we're completely open to people using either approach. For those that are using AI tooling all the time, we want the interview environment to feel comfortable and realistic.

What we're looking for

We're looking for people who don't outsource their thinking entirely, but use AI as an accelerator rather than as a crutch.

That isn’t to say that we don’t want candidates to really embrace AI; ideally they get to the same place they would have done without, but faster. A distinct planning phase has been best practice for coding agents for a while (and quickly became part of the tools like Claude Code). Iterating on a plan before starting is a good sign that the candidate is really thinking about the design. The best candidates have some idea of what they think the approach will look like before they start, but this might evolve as the interview progresses.

As well as considering the solution design, thinking about the functional aspects of the problem is important too — we’re all product engineers now. AI might help to identify some of the edge cases, but it’s all too keen to jump to a solution. We like to see people really explore this and think about the product.

Once AI is writing some code, it can churn out a lot very quickly! This was the thing that our interviewers called out most strongly, those moments when the pace suddenly accelerates. Like when we’re writing our production code, it’s important that we develop a shared understanding of what the code is doing. As models get better, it can get closer and closer to getting it right first time, but without reviewing the output we don’t necessarily know what trade-offs it’s making. Assuming it isn’t perfect, it’s good to see some degree of iteration - could be via further prompting or writing “artisanal code”, both show a real focus on quality.

AI is particularly good at coding when it has a verification loop. We’ve always appreciated TDD in our interviews to break down the problem; with AI, this becomes even more important. The quality of this verification loop helps us to understand how a candidate thinks about engineering for maintainability. It goes deeper than the binary “tests or no tests”, we try to get a sense of their experience considering the value of tests, like the level at which they choose to write tests.

What we've learned

One of the things that I’ve found really interesting is the different styles of prompts that people use. I’ve definitely learnt things and incorporated them into my own workflow! In an unfamiliar codebase, it’s great when candidates demonstrate how they can constrain the output and use the AI to implement their intentions. The candidates using it most effectively are really engaging it in conversation, iterating on a plan, iterating on the output, referencing earlier decisions.

Removing the time spent on any bits of boilerplate code really allows us to explore the whole problem more widely. When the candidate isn’t spending time on syntax, we have more time to discuss the trade-offs of different approaches, the implications of decisions, interesting edge cases. This also allows us to be more open to people who aren’t as familiar with TypeScript (and provides more competition to those who are!).

This parallels what a lot of people have been saying about AI coding in general: writing the code was never the hard bit. Allowing AI in our interviews has allowed us to spend less time evaluating code writing and more time on the interesting bits. It hasn’t changed what we value, just how we evaluate it.

We're a few months into trying AI in interviews, and still learning about it. Candidates are often a bit wary too, as many others still don't allow it. This definitely feels like the direction of travel, albeit trailing behind the real practice of engineering. It's a fast-moving space, which will influence how our interview process will evolve in future. As AI becomes more ubiquitous, we might expect or require candidates to use it. We may have to continue to expand the problem itself to keep challenging ever smarter models. But all of this will continue to be driven by us looking to get a signal on the skills and capabilities that we value.

If this sounds like the way you want to work, take a look at our open roles.