The first thing we read in an application is the work the person sends us. That might be a repository, meaning a place where code and its history live, a description of a system they designed, or a write-up of a problem they solved.
The CV comes afterwards. We read it mostly to understand context.
This choice is deliberate. A CV is a poor instrument for the decision we are actually making. We need to understand how somebody thinks, explains, decides, and deals with the parts of engineering that do not fit neatly into a job title.
A CV gives useful context, then stops too early
A CV reliably tells you where somebody has worked, for how long, and what technologies were in use around them. Those are facts. They correlate with what we care about, weakly.
The harder questions sit outside the CV. We care how somebody thinks about a problem. We care what they do when the requirements are contradictory. We care whether they can explain a decision, and whether they know why they made the choices they made.
Those are the things that determine whether an engineer is useful on a small team building things that other people depend on.
There is also the well documented problem that CV screening rewards a particular kind of career. It favours careers that are continuous, at recognisable companies, with the expected titles in the expected order.
Plenty of excellent engineers do not have that career. The reasons range from geography to caring responsibilities to having spent three years on something that did not work out.
We ask to see work with enough context to understand it
What we ask for is simple: something you built, with enough context that we can understand what you were trying to do.
It does not have to be impressive in scope. Some of the best submissions we have read were small. One was a tool somebody wrote to solve an annoyance, with a clear explanation of the constraints and an honest note about what they would do differently.
Some of the least useful submissions were large open source contributions where the submitter had clearly not made the design decisions. Size did not help us understand their judgement.
For many people, there is nothing public to send. That is the normal situation for people who have spent their career on commercial work. In that case, we ask for a description instead.
We often ask people to tell us about the hardest bug they have shipped a fix for. That question works well because a good answer requires most of what the job requires. The person has to explain:
- a system
- a symptom
- an investigation
- a decision
That gives us something far more useful than a list of employers and tools.
We read for judgement, explanation, and failure thinking
We are reading for a small number of specific things. Cleverness is not the main signal.
We look for whether you can explain why
We want to understand why you built it that way, what you considered, and what you rejected. This is the single strongest signal in either direction.
A description of what was built is only the start. The useful part is the reasoning that sits behind it.
We look for whether you know where the work is weak
Every real system has parts the author is not happy with. Somebody who can name theirs is telling us they have a standard and can measure against it.
Somebody who presents work as uniformly good is either very early in their career or not looking carefully.
We look for whether you considered the failure cases
We want to see what happens when the network drops, when the input is malformed, and when two things happen at once.
The presence of that thinking is more predictive than any amount of elegance in the happy path.
We look for whether you can write clearly
Most of this job is explaining things to people who were not there. A clear paragraph is a strong signal, and it is one of the few that transfers across every kind of engineering work.
We ignore signals that do not tell us much
There are several things we are explicitly not reading for:
- Test coverage on a personal project.
- Commit message discipline in a repository nobody else works on.
- Whether the code is idiomatic for a style guide we happen to like.
- Whether the project is finished.
- Whether the technology is one we use.
We have hired people whose submitted work was in a language we have never shipped, because the thinking was evident and languages are learnable.
We have declined people with polished repositories who could not explain a single decision in them.
Reading work first is fairer to the people we want to find
Reading work first advantages people who are good at the job and disadvantages people who are good at presenting themselves. That is the direction we want.
It is notably fairer to people whose careers do not match the pattern CV screening tends to reward. That includes:
- people who did not go to a well-known university
- people who changed career later
- people whose employer’s name means nothing outside their country
- people who have been doing excellent work at an unglamorous company for six years
All of those people get filtered out early by CV screening, routinely. All of them are well represented among the best engineers we have worked with.
There is one respect in which this approach is less fair. It asks for time. Writing up a bug properly takes an hour or two, and somebody with a full-time job and caring responsibilities has less of that than somebody who does not.
We try to mitigate it by accepting a short answer. We are aware it does not fully solve the problem.
We discuss the work deeply enough to know whether it is yours
The obvious objection is that somebody could submit work that is not theirs, or work that was heavily assisted.
Yes, they can. It matters less than you would expect, because the next conversation is ninety minutes about the work with two engineers.
It is very difficult to discuss a system you did not build in any depth. The questions that surface it are ordinary questions, not gotchas:
- why this approach rather than that one
- what would you change if the volume were a hundred times larger
- what was the hardest part
Somebody who did the work answers those fluently and often with more nuance than the write-up contained.
Somebody who did not do the work gets vague quickly. Nobody has to be accused of anything, because the conversation simply does not go anywhere.
We hold ourselves to the same standard
We think an employer asking to see somebody’s work has an obligation to show theirs. That is why we publish how we work, our engineering commitments, and the arguments we have with ourselves in public.
Anybody applying can read what we actually think before deciding whether they want to be here.
That has a filtering effect in both directions, and we consider it a feature. Several people have told us they applied because of a specific position we had taken. At least two have told us they did not apply for the same reason, which seems like the process working.
AI does not change what we are assessing
Every hiring conversation now includes a version of this question: what if the submitted work was written with a model. We have thought about it more than most, because we build these systems for a living, and our position is probably not the expected one.
We do not mind. Using good tools well is part of the job, and an engineer who declines to use them in 2026 is making a strange choice.
What we are assessing is judgement. Judgement is visible regardless of what produced the first draft. The important questions remain the same:
- Why this structure.
- What did you reject.
- Where is it weak.
Those questions are answerable by somebody who directed the work and unanswerable by somebody who accepted an output.
What we do mind, and what is disqualifying, is presenting something as your own understanding when it is not. The tool is not the issue. The issue is that the job involves telling clients what a system does.
Somebody who is comfortable overstating their grasp of their own submission will be comfortable overstating it about a production system at two in the morning.
So we ask directly and without any edge to it: what did you use, and what did you change about what it gave you.
The second half of that question is where the interesting answers are, and nobody has ever been penalised for the first half.
A strong submission can be small and specific
Being concrete matters, because asking somebody to send us their work can feel unhelpfully vague to somebody staring at a blank form.
One of the strongest submissions we have received was about four hundred words. Somebody described a scheduled job at their employer that had been silently failing for months in a way that looked like success.
The failure looked like success because the job caught an exception, logged it at debug level, which is a low-visibility log setting, and returned normally.
They explained how they noticed, what they checked, why the obvious fix was insufficient, and what they changed about how the team writes background jobs as a result.
The submission had no code, no repository, and no impressive technology. It demonstrated investigation, a working mental model of a system, the instinct to fix the class of problem rather than the instance, and the ability to write it down clearly.
We would rather read that than a thousand line project any week.
The pattern in weak submissions is equally consistent, and it is not lack of skill. The writer describes what was built with no account of why, no alternatives, no constraints and no weaknesses. That leaves a reader with nothing to assess.
This takes senior engineering time, and we accept the cost
This approach is slower than screening CVs, considerably. An engineer reading a submission properly spends fifteen to thirty minutes on it.
At a hundred applications for a role, that is a meaningful amount of senior time. It is also time spent by people who have client work.
We accept that cost for two reasons. The first is that a bad hire on a team of this size is far more expensive than the reading.
The second is that the reading is not wasted even when the answer is no. The reason we can give a specific written response within two days is that somebody actually engaged with the work.
We would not claim this scales indefinitely. At a much larger volume something would have to change. We would rather solve that problem when we have it than adopt the filtering apparatus of a company ten times our size in advance.
Every application is read by an engineer
An engineer reads every application. A recruiter, a keyword filter, and a model do not do that reading.
Everyone gets an answer either way. If it is a no, you get a reason in writing within two days.
That last commitment is the one we would most like other companies to copy. Silence after an application is the industry’s most common discourtesy. It costs the candidate real anxiety, and the only thing it saves the employer is a few minutes of discomfort.
Our open roles are on the careers page, and how we work is on how we work.
