Interviews in the Age of AI: Build Together

Article

Interviews in the Age of AI: Build Together

January 13, 20263 min read

I started with a simple interview challenge and extended it into a public project:

But this post is not about the UI or the tech stack checklist.

It is about a bigger shift: how technical interviews should work in the age of AI.

The old interview format is dying

For years, interviews were built around isolation:

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

That format tested memory and stress tolerance more than engineering.

Today, every real team works with AI assistance, docs, search, and discussion.
So interviews should test how you operate in that reality.

What I want interviews to become

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

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

Then do the valuable part 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

This is where engineering happens.

Not “who can remember the exact API from memory”, but:

  • who asks good questions
  • who can structure ambiguity
  • who can collaborate under constraints
  • who can make safe, reversible decisions quickly

The AI-era skill is not coding faster

The AI-era skill is thinking better together.

AI can generate code fast.
It cannot own accountability, production risk, or product judgment.

So in an interview, I care about:

  • 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?

From one address book, many interview directions

The interesting part is that the same small base can branch into many real engineering discussions.

Starting from this address book, an interview can go into all kinds of directions, such as:

  • product thinking (what problem are we really solving?)
  • UX decisions (search behavior, empty states, mobile-first flows)
  • API design (contracts, versioning, error models)
  • data modeling (normalization, 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)

This is exactly why I like this format.
We can live code, add features, write specs together, challenge assumptions, and see how someone thinks in motion.

The interview I want to have

Give me a problem.
Let us build version one together.
Then ask: “Where should we take this next, and why?”

That conversation reveals far more than a perfect coding kata.

In the AI era, the strongest engineers are not the ones who code alone the fastest.
They are the ones who can think, build, and evolve systems with others.