Hiring as a Facsimile of Real Work
Most interviews measure how well you can perform in a manufactured conversation rather than real work.
Often, as a candidate, you’re dropped into a one‑hour call with someone you’ve never met, asked to summon stories about your past, and hoping to leave a strong enough impression that a group of strangers are willing to bet on you. On the hiring side, you’re also improvising: trying to build a picture of someone’s judgement, temperament, and craft from a handful of highly unusual hours.
I’ve been on both sides of this – designing hiring loops and sitting inside other people’s. Most of the teams I speak to are sincere when they say they want their process to “show what it’s really like to work here”. It’s a good instinct: candidates want to know what they’re signing up for, and teams want to see how someone works in the job's real environment.
But the experience often feels like classic interview theatre. And theatre isn’t a particularly good way to assess the things most teams care about: judgement, collaboration, craft, and the ability to make sense of messy problems over time.
So here’s the question I want to write about: if the job mostly happens through documents, tickets, and pull requests, why is it so common that hiring doesn’t look like that?
What would it mean to treat hiring as a facsimile of real work – a better simulation of what working life will be like together?
Why interviews feel nothing like the job
A fairly standard process goes something like this: a recruiter screen, a quick call with somebody senior, and then two or three one‑hour calls with different people from the team. Each call is a fresh performance: you start again with your story and try to calibrate your answers to a new person’s concerns and style. You share no context beyond a job description and a LinkedIn profile.
The questions tend to have a familiar flavour:
“Can you tell me about a time when you…?”
“What’s your greatest strength… your biggest weakness… a moment you demonstrated…?”
These prompts come from a well‑intentioned place. The science says that past behaviour is the best predictor of future behaviour, so you ask people to replay their greatest hits. In practice, you’re asking them to do two conflicting things at once: recall specific situations from the past and, at the same time, narrate them in a way that reveals beliefs and thought processes. It’s cognitively heavy, especially under time pressure with strangers watching.
It also rewards a particular kind of person: someone who is good at telling neat stories about messy events. Someone who can sell you a pen – rather than the person who can design it, manufacture it, ship it, and keep it working.
For some roles and some cultures, that’s fine. If the work is mostly live meetings, quick alignment, and “talk it through on a call”, then a call‑heavy process is at least directionally aligned.
But for teams that deliberately choose async rhythms – who value preparation, written communication, clear handoffs and time to think – it’s an odd way to evaluate fit. You spend your actual working life reading documents, leaving comments, and thinking in the shower about a paragraph in a spec, but your hiring loop is dominated by live improvisation.
What work actually looks like in an async team
If I zoom out on a typical week in a remote, async product team, the rhythms look very different from a string of one‑off calls.
You see colleagues pruning the backlog and rewriting tickets so they actually make sense. You see engineers reading a PRD for a sizeable change, not quite getting it, asking a few questions, and later having an “oh, of course” moment while taking a walk. You see code reviews where someone admits they’re confused and turns that confusion into a learning experience for both sides.
Most of somebody’s personality and value shows up in their async writing persona: Slack messages with enough context that you don’t have to ask “wait, what are we talking about?”, comments that show curiosity and care rather than drive‑by criticism, and pull requests that tell a clear story instead of dumping a diff on your lap.
The work is less about one‑off performances and more about some recurring patterns:
- Continual collaboration on shared context. Over time, you build a mental map together and share trajectory.
- Time to sit with problems. People do their best thinking when they can come back to something twice: read, react, sleep, revise.
- Temperament that emerges in low-stakes moments. Enthusiasm, care, humility, patience, generosity - the little interactions that fill the week.
If this is what working life actually feels like, then a hiring process made entirely of isolated, high‑pressure calls is not a good proxy.
Simulating situations for real collaboration
Once you start from the reality of the work, a principle suggests itself:
If the job is mostly async collaboration,
…the hiring process should contain async collaboration.
Instead of treating interviews as a chance to rapidly psychoanalyse someone, you can treat them as a small shared project. Rather than simply grilling a candidate with clever questions, you simulate working together on something that looks and feels like the real problems.
That might mean sending a realistic PRD in advance and asking for comments. It might mean having a discovery‑style call where confusion is welcome, then giving both sides time apart to think and write, then coming back together to make decisions. It might mean having two people from the team on the call so that feedback reflects a team perspective, not just one person’s vibe.
Real work tends to move in cycles of explore together → think alone → come back together. A good hiring loop borrows that rhythm. It’s less about squeezing truth out of an hour‑long interrogation and more about noticing how it feels to move through a few small loops with someone: reading, commenting, discussing, following up.
Designing the details is hard, but the principle is simple.
The risks behind hiring anxiety
Part of the reason I think we cling so tightly to traditional interviews is that hiring is genuinely risky.
There are a few different risks tangled up together:
- A false positive: you hire the wrong person – someone who quietly corrodes the culture, or simply can’t do the work at the level you need.
- A false negative: you miss someone who would have been wonderful to work with because they were nervous, tired, or just not very good at the peculiar game of interviewing.
- A time and energy cost: you don’t want to waste candidates’ time (or your own), so you compress everything into a small number of calls and hope you can extract enough signal quickly.
Most processes try to manage these risks by packing as much psychological signal as possible into a small number of calls. We search for clever, abstract questions that promise to reveal hidden truths. We watch for tiny “red flags” in how someone tells a story, or how fast they answer, and treat those as decisive.
The problem is that this pushes everyone into performance mode. Candidates tell the neatest stories they can. Interviewers over‑index on first impressions. Quiet, thoughtful people who do their best work in writing get compressed into an hour of speaking and are judged on how that felt.
Traditional character questions and gut checks are not inherently bad. There is still something to be said for first impressions and storytelling (Life’s a Pitch spells this out). The issue is loading those interactions with the entire burden of assessing fit, as if a handful of hours could ever tell you everything about what it will be like to share a mission, backlog, and codebase with someone for years.
What this looks like in practice
Take‑home exercises and code samples are one attempt to make hiring more work‑shaped. Even when they’re imperfect, they do at least create shared context: you both arrive with something concrete to look at, discuss, and respond to.
But shared context isn’t the same thing as collaboration. The thing I’m reaching for is real work: a problem over time that gives both sides a chance to show their best.
Here’s one abstract shape of a loop I like:
- A small artefact, sent ahead of time. A short PRD, a bug report with logs, an architectural decision that needs revisiting.
- Async comments first. “Leave notes in the doc as if you were on the team.”
- A call that welcomes confusion. The goal isn’t to defend an answer; it’s to explore the problem together.
- A short written follow‑up. “Write down what you think we should do, and what you’re still unsure about.”
I'm working on a follow-up about the specific techniques I've used when building hiring loops. If you want to catch it when it lands, subscribe to my RSS feed.
None of this needs to be long. Out of courtesy you should make sure to share at least a little feedback with candidates on what you noticed at each step.
Many teams already include touch-points like this in their process. The key is to weave a number of these exercises into your loop as a coherent arc, and design them to reflect the collaboration qualities you actually value.
Make space for arcs of behaviour
The alternative I see is not to pretend first impressions don’t matter, or to delete interviews entirely. It is to demote them from the whole story to one part of the picture, and to put more weight on short arcs of behaviour that resemble the actual job.
Instead of deciding everything based on a few intense hours, you notice how someone shows up across a few small, work‑like interactions. How they engage with a shared document asynchronously. How they handle ambiguity and confusion in a discovery‑style conversation. How they write up decisions and respond to open questions.
You still pay attention to the feeling of the calls – how it is to talk to this person, whether they listen, whether there is basic ease. However you get to observe those signals in a number of contexts, rather than a single style of performance.
A hiring loop cannot perfectly replicate the job. No process can remove all the uncertainty; probation and real work together are still where you learn the most. But it can be a much better facsimile for what working life will be like together.
Build your hiring process around the collaboration you actually value, and you won’t have to rely on exchanging stories to picture what working together might be like — you can just see it.