Interviewing with AI at Distyl

AI is how we work. Our engineers are forward-deployed inside some of the world’s most important institutions, using AI every day to build and ship the systems those organizations run on.

Our interviews reflect that. We encourage AI in most stages, but what matters is how you use it. We want to know how you validate outputs, how you iterate when something isn’t working, and whether you can steer AI rather than accept what it gives you. The candidates who stand out use AI thoughtfully, creatively, and with a clear understanding of what it’s doing and why.

Where AI Is Encouraged and Where It Isn’t

We encourage AI in some stages and deliberately exclude it from others. Here’s how AI fits into different parts of the process:

Take-home assessment. AI is fully encouraged, and you can use whatever tools you want. We’re interested in the quality of what you produce and, just as importantly, whether you can explain and defend it afterward. We will ask.

Select live coding screens. Some coding screens include an AI assistant for candidates to use. Depending on the screen, the AI assistant could take different forms, from a built-in ChatGPT-like experience to a tool like Claude Code or Codex. In every case, the AI assistant is configured to assist, not to solve the problem for you. We want to see how you interact with it, including what you prompt, how you evaluate what it gives you, and how you iterate when the output needs work.

Codebase review. You’ll review an unfamiliar codebase without AI assistance. This stage is about whether you can read, evaluate, and reason about code on your own. We want to see how you think without AI, not just with it.

When we ask for your opinion. Across both technical and non-technical roles, we’ll ask what you think about a tool, an approach, or a tradeoff. There’s no right answer, but we want to hear from you. Your perspective reveals how you’d operate in complex and high-stakes situations.

What Good AI Usage Looks Like

The best candidates use AI in ways that show deep understanding and creativity.

Good AI usage means you can explain the reasoning behind what you built with AI assistance. When we ask why your code is structured a certain way, or why you chose a particular approach, you have an answer that goes beyond “the model suggested it.” You understand the tradeoffs, you can identify where the output might fall short, and you can articulate what you’d change if the requirements shifted.

We’ve also seen candidates find creative ways to incorporate AI into how they prepare and work, and we value that kind of initiative. If you’ve experimented with AI in interesting ways, we want to hear about it. We also value transparency: if you used AI for something, tell us. Disclosing how you used AI is always a positive signal.

We don’t expect years of AI experience. What we’re looking for is the instinct to experiment, the honesty to say when something isn’t working, and the ability to learn quickly. A candidate who tries something ambitious with AI and is upfront about where it fell short, how they’d improve it, and what they were trying to accomplish stands out more than someone who plays it safe and produces something generic.

Pitfalls to Avoid

We see a few recurring patterns in candidates who struggle with AI in our process.

The Autopilot. The candidate is fluent with AI tools but treats them as a black box: prompt in, output out. They haven’t developed the habit of evaluating what AI gives them, refining it, and applying what they learned to the next iteration. Without that feedback loop, the candidate struggles to distinguish good output from bad output until someone else points it out.

The Default. The candidate lets AI replace their own thinking and perspective, without exercising judgment about whether AI is the right tool for that moment. This can show up in application responses, for example: answers that are clearly AI-generated, interchangeable, and could apply to any company. It can also show up during interviews, when we ask for an opinion and get a safe and generic answer instead of a real point of view. Knowing when to use AI and when to bring yourself is one of the most important skills we evaluate.

The Demo. The candidate produces polished-looking output that doesn’t hold up under scrutiny. The code runs and the structure looks reasonable, but the underlying quality isn’t there: patterns are sloppy, architectural decisions don’t make sense for the use case, or the solution introduces problems that someone else may need to clean up. At Distyl, our engineers own the outcome of what they build. When your code goes into production inside a client’s enterprise, problems don’t get handed off to another team—they come back to you. Output that looks good in a presentation but creates more work downstream isn’t good enough.

All three come down to the same gap: judgment, depth, and substance in how the candidate uses AI.

This Is the Work

Everything we’ve described above is a reflection of how we actually work.

When you’re embedded with a client, you own what you build and you’re there when it breaks. In that context, using AI demands more than efficiency or speed. It’s about judgment: knowing when AI accelerates the work, recognizing when it introduces risk, validating what it produces, and catching what it misses.

Our interview process is designed to find people who already think this way, or who are clearly on their way there. If you enjoy getting creative with AI, have opinions about what works and what doesn’t, and are honest about what you don’t know, you’ll do well here.

If you’re ready to use AI on work with real stakes and real impact, see our open roles here.