Back to blogAbstract line art of a narrow keyhole shape on the left and a wide branching set of paths on the right, suggesting a narrow filter set against a much larger space of real work.

essay / / 3 min read / Redomic Labs

A linked-list question cannot screen an AI-native engineer

The standard technical screen tests a skill from 2016. The engineers worth hiring in 2026 work in a way that screen was never built to see, and it will happily reject the best of them.

  • hiring
  • ai-native
  • evaluation
  • engineering

The technical interview has a default, and the default is roughly twenty years old. Reverse a linked list, balance a tree, find the cycle. These questions endured because they were cheap to ask and easy to grade, and for a long time they correlated well enough with the work. The problem is not that they are hard. The problem is that they measure a skill that is no longer the one separating a strong engineer from a weak one.

When an accelerator will fund a founder on nothing more than how well they think with AI, it is worth asking why the engineers those founders go on to hire are still filtered on how well they can implement a data structure from memory. The signal moved. Most screens did not.

What the work actually looks like now

An AI-native engineer spends less of the day typing the implementation and more of it deciding what to build, directing a model toward it, and checking that what came back is correct. The valuable skills are architecture under ambiguity, prompting with intent, reading generated code critically, and knowing when the output is quietly wrong. None of these show up in a whiteboard question about pointers. A candidate can be excellent at the modern job and mediocre at the 2016 test, and the test will happily reject them.

  • Framing a vague problem into something a model can be pointed at, rather than starting from a clean spec someone else wrote.
  • Directing a model well: the prompt, the context, the constraints, the follow-up when the first attempt is close but wrong.
  • Reading generated code with suspicion, and being able to say how they know it is correct.
  • Judgement about where to let the model run and where a human has to stay in the loop.

We have measured the gap. Across more than five hundred DevMesh assessments run in a single day, years of experience carried no signal on how a candidate scored, and the most consistent failure was not writing tests for code a model had produced.

Assess the job, not its shadow

The fix is not a harder linked-list question. It is to put the candidate in front of a task that resembles the actual work and watch how they move through it. Let them use the tools they would use on the job. Judge the result and the reasoning behind it, not whether they reproduced an algorithm they will never write by hand again. A screen should be a small, honest sample of the real thing, and the real thing changed.

You cannot hire for how engineers work today by testing how they worked a decade ago. The screen has to move when the work does.

Redomic Labs

This is the same shift we keep coming back to. AI-native is not AI-added. It changes what the work is, which changes what competence looks like, which has to change how you measure it. Keeping the old test is not a neutral choice. It is a decision to keep screening for a job that fewer and fewer people are actually doing.