The coding test is still the thing most engineering teams default to when they need to filter candidates before the first conversation. It sits somewhere after the CV screen and before the live round, and the logic behind it holds up. A coding test for an interview is cheap to administer and it feels objective, which is most of the appeal. For a decade, it did the job well enough.

The format itself hasn't changed much. Teams still send a timed puzzle, or a short browser-based challenge, with a scoring rubric attached. What has changed is what the format ends up measuring.

What an interview coding challenge reliably picks up

Take a standard setup: 45 minutes, a self-contained problem, no external help allowed. The things a test like that picks up reliably are whether the candidate has practised that particular genre of problem recently, and whether they can type under surveillance without getting tangled up. Those are real skills. They just aren't the skills most engineering jobs are actually built around, and a candidate who scores well on them isn't necessarily going to be effective at the work that starts on day one.

The weaker readings are easier to spot. A senior engineer who's been shipping production code for ten years can score badly on a timed coding puzzle because they haven't touched that kind of problem in three years. The test reads their unfamiliarity as incompetence. The stronger readings are also misleading: a recent graduate who's been grinding job coding challenges on practice sites will often outperform an experienced engineer on the same test without being the better hire.

The question underneath the test

The reason teams added a coding test in the first place was to answer a simple question: can this person code? That was a harder question to answer in 2016 than it is now.

In 2026 the answer is usually sitting in plain sight. The candidate has a GitHub account, a portfolio, a repo full of side projects, or a previous employer whose work you can look at. If they don't have public code, the recruiter's screening call can surface that in two minutes. The gatekeeping function the coding test used to serve is being handled by cheaper signals long before the candidate sits down to take it.

The original question has also splintered. Can this person code? is not really the thing a hiring manager wants to know anymore. What they want to know looks more like: will this person be useful in the first quarter, on the work we actually do, with the tools we actually use? A coding test built to answer the first question doesn't do much for the second.

What a better coding challenge looks like

An interview coding challenge can still be useful. The shape has to change.

A good version looks less like a puzzle and more like a small slice of the work. It gives the candidate a realistic problem, a reasonable amount of time, and — crucially — access to the tools they'd use on the job. That last part matters more than most teams admit. If the candidate would reach for documentation, a search engine, and an AI collaborator on day one, asking them to pretend those tools don't exist on day zero tells you very little about how they'll perform.

The scoring has to change too. An automated rubric that counts passed test cases is easy to run and hard to argue with, but it rewards candidates who optimise for the rubric and penalises candidates who think carefully about the problem. A better signal is the artefact of the candidate's thinking: the assumptions they wrote down, the trade-offs they flagged, the questions they asked, the parts they chose not to build. Most of that is invisible in a pass/fail score. It's also the part a well-scoped take-home exercise is set up to catch.

At CriticCode we build the shape of coding challenge we wish every team ran. The candidate gets a realistic prompt, an AI collaborator to think with, and a handful of structured questions that catch the reasoning rather than the output. The submission that lands on the hiring manager's desk is a prep artefact for the follow-up conversation, not a score. It's the shape a coding test probably should have been all along.

The practical move

If you're running a traditional coding test today, the useful question to ask is: what am I actually learning from this that I couldn't learn elsewhere? The honest answer for most teams is "not much." The test persists because removing it feels risky. Replacing it with something that catches thinking, not composure, is the cheaper fix.