"Reverse a linked list on this whiteboard."
For twenty years, that question told you something. It proved a candidate understood data structures. It separated the CS graduates from the pretenders. It was a reasonable proxy for engineering skill.
It tells you almost nothing now.
What changed
AI writes linked list reversals in 3 seconds. It writes them correctly, with edge cases handled, in any language you want. The skill that mattered for two decades became a commodity overnight.
But here's what AI can't do: decide whether you need a linked list. Or a hash map. Or an event bus. Or a direct database call. Those are architecture decisions. They require understanding the domain, the trade-offs, and the consequences.
The developers who thrive now aren't the ones who memorized algorithms. They're the ones who make good decisions and let AI handle the implementation.
What to look for instead
1. Architecture thinking
Give a candidate a domain. Not a coding challenge, but a real business problem. Ask them to walk through how they'd structure the codebase so that AI can help build it.
Strong candidates will talk about:
- Domain boundaries: which parts of the system should be independent
- Data flow: how information moves between components
- Type contracts: how frontend and backend agree on data shapes
- Security model: where access control lives (application vs. database layer)
Weak candidates will jump straight to implementation details.
2. Documentation practice
Ask to see their repos. Do they have architecture docs? Documented conventions? A .claude/ directory or equivalent?
Developers who document their decisions get predictable AI output. Developers who don't get random patterns every time. The documentation habit is the clearest signal of AI-era readiness.
3. Quality automation
Ask about their testing and CI strategy. Not "do you write tests" (everyone says yes). Ask specifically:
- What runs before a commit? (Pre-commit hooks: formatting, linting)
- What runs before a push? (Type checking, unit tests)
- What blocks a merge? (Full CI: coverage floor, security scanning)
Developers with automated quality gates ship faster and more reliably. Without them, AI-generated code goes straight to production unchecked.
4. The delegation instinct
Ask what they delegate to AI and what they keep for themselves. The answer reveals everything.
| Good answer | Red flag |
|---|---|
| "I design the schema, AI generates the CRUD" | "I let AI design the database" |
| "I define the API contract, AI implements handlers" | "I just describe the feature and AI builds it" |
| "I review every generated test" | "AI writes the tests, I trust them" |
| "AI handles boilerplate, I handle business logic" | "I use Copilot for autocomplete mostly" |
The interview that works
Replace the whiteboard with a system design conversation. Give them a real scenario:
"We need an order management system for a food delivery platform. Multiple restaurants, real-time driver dispatch, payment splits between vendors. Walk me through how you'd architect this, knowing that you'll use AI to help build it."
Then listen. The best candidates will:
- Ask clarifying questions about the domain (not the tech stack)
- Identify bounded contexts and service boundaries
- Explain what they'd document before touching code
- Describe their quality automation strategy
- Articulate what AI handles vs. what requires human judgment
This tells you more in 30 minutes than a week of coding challenges ever could.
The hiring equation has flipped
The old equation: Speed = typing speed x knowledge of syntax
The new equation: Speed = quality of decisions x clarity of documentation x automated quality gates
When you hire for the old equation, you get developers who code fast and debug slow. When you hire for the new one, you get developers who think fast and ship reliably.
That's the difference between a developer and an AI Viber developer.