A·H
← The archive Dispatch

Article · Field notes

Interviews in the Age of AI: Build Together

13 Jan 2026 3 min read

Interviews in the Age of AI: Build Together

I started with a small interview challenge and turned it into a public project:

I don’t really care about the stack here. What bugs me is that interviews still test for a world that no longer exists.

What the classic format misses

For years, technical interviews looked like this:

  • no internet
  • no docs
  • no helper tools
  • one person, one editor, one timer

I never loved it. It rewards memory and composure under pressure, and tells you almost nothing about how someone actually works on a team.

In real life we use docs, search, AI tools, and each other. Interviews should reflect that.

Build something together first

Start with a shared build. For example, a T3-based address book:

  • fetch data
  • search
  • filter
  • sort
  • render responsive cards

Then do the part that matters, together:

  1. Live code a new requirement
  2. Write a mini spec on the fly
  3. Debate technical trade-offs
  4. Sketch algorithm choices
  5. Decide what to postpone and why

The kind of engineering I want to see in an interview has very little to do with who remembers API trivia, and a lot to do with the things that are harder to fake:

  • who asks sharp questions
  • who can structure ambiguity
  • who collaborates under constraints
  • who can make safe, reversible decisions quickly

The skill AI actually changes

AI can produce code fast. What it can’t do is own accountability, production risk, or product judgment. So the skill that matters more now is thinking clearly with other people, under real constraints.

In an interview I pay attention to this:

🎯Can we turn an idea into a clear spec?
🛡️Can we split work into safe increments?
🔍Can we identify failure modes early?
📢Can we explain trade-offs to non-engineers?
🔄Can we adapt when assumptions break?

One small project, many directions

One small base project opens up real discussions.

From the same address book, I can explore with a candidate:

  • product thinking (what problem are we actually solving?)
  • UX decisions (search behaviour, empty states, mobile-first flows)
  • API design (contracts, versioning, error models)
  • data modelling (normalisation, indexing, trade-offs)
  • algorithm choices (sort/filter strategy, performance implications)
  • testing strategy (unit vs integration vs end-to-end)
  • reliability (timeouts, retries, graceful degradation)
  • security and auth boundaries
  • observability (logs, traces, metrics, alerting)
  • team collaboration (specs, RFCs, code review style, rollout planning)

That’s why I like this format. We can build, discuss, challenge assumptions, and see how someone thinks while the situation changes.

The interview I want to have

Give me a real problem. Let’s build version one together. Then ask: “where do we take this next, and why?”

I learn more from that conversation than from any perfect kata.

These days I trust engineers who can think, ship, and keep evolving systems alongside other people.