Notes on hiring, work, and craft.

Ask ten engineering leaders how they hire, and you'll get ten variations of the same broken loop: a resume funnel, a phone screen, a technical screen, a take-home, an on-site, a debrief, an offer, a month of onboarding, and — often — a regret three months in. Each stage feels necessary, but the whole system works badly enough that the industry is permanently annoyed at it.

We think most of what's wrong with engineering hiring happens before anyone sits down for an interview. The problem isn't the questions people ask. It's that no one has actually evaluated anyone before the interview loop starts.

The information problem

When a hiring manager gets a resume, they have almost nothing to work with. A CV is a narrative written by the candidate, optimized for keywords, and polished by whoever owes them a favor. The signal-to-noise ratio is terrible. So the interview loop is doing two jobs at once: evaluating fit, and compensating for an absence of prior information.

Both sides hate this. Engineers hate being asked to prove they can center a div for the seventh time. Hiring managers hate running four hours of interviews to decide on a yes-or-no. The whole loop is an expensive way to recover information that should have existed upstream.

Our theory

We think the layer between companies and candidates should do the evaluation work once, then just matchmake. Imagine if, by the time a hiring manager saw a candidate, they already had:

• Verified work history
• Reviewable code samples with senior-engineer notes
• A scored assessment across code quality, system design, communication, and async habits
• Three case studies on the engineer's actual past work
• A stack fit score, computed against the role's real needs

What would the interview loop look like? Probably a single conversation to confirm fit, a working session to check chemistry, and a reference check. Maybe a week end-to-end instead of seven.

What breaks in practice

The obvious objection is: well, someone has to do the evaluation work, and now that someone is you. Doesn't that just shift the pain?

Yes, but the economics are dramatically better when it's done once and reused. An engineer in our pool goes through the assessment once; from then on, every match they get reflects it. A company hiring through us skips weeks of funnel work; we've done it for them. The total work across the system is a small fraction of what happens when everyone evaluates from scratch.

There's also a quality ceiling that's higher than individual hiring loops can reach. One team interviewing occasionally can't calibrate well. A platform running thousands of evaluations with the same rubric can. The scoring gets better every month.

What this means for us

Everything we build is downstream of this theory. The vetting process is strict because the whole model depends on the bar being real. The matching engine has to be honest — if we send four candidates, the engineering manager has to be able to trust that any of the four is hireable. Our Fellowship Program exists because the number of engineers who clear our bar is limited, and we wanted to build a pipeline for more.

It also explains what we don't do. We don't take recruiting fees per candidate — it distorts incentives. We don't spray-and-pray candidate submissions — volume hurts quality. We don't hide failed candidates on inactive lists — if someone isn't ready, we say so.

If you've read this far

You probably agree with some of this and disagree with other parts. Both are useful. If you're a hiring manager tired of your loop, let's talk. If you're an engineer who wants to never write another generic cover letter, apply to the pool. And if you're somewhere in between — building your own hiring process, or thinking about joining a team like ours — drop us a note.

We say publicly that about 1% of applicants clear our bar. People ask what that actually means. This post is an honest walkthrough of our vetting process — what we test, why, and what we've learned from running thousands of assessments.

Stage 1: The written application

The application itself is a filter. We ask about stack, seniority, recent projects, and what kind of work the engineer wants next. We also ask for a link to something they've built or contributed to. No cover letter.

About 40% of applicants don't finish the form. Of those who do, another 35% are screened out at this stage — usually because their claimed seniority doesn't match the rest of the application, or because the linked work doesn't exist or is clearly copied. This stage is rough but necessary. We respond within two business days either way.

Stage 2: The technical assessment

This is the part most people ask about. Our assessment is self-paced, takes about three focused hours, and has three parts:

• A coding exercise — not a puzzle, but something closer to real work. Build or extend a small feature against a provided codebase. We grade on correctness, readability, tests, and how you handle edge cases.
• A system design prompt — sketch the architecture for a realistic system. We grade on tradeoff reasoning, not the specific answer.
• A written response — a short paragraph about a past technical decision you regret. This sounds soft but it's one of the most predictive signals we have.

About 35% of the remaining applicants pass this stage. The coding exercise filters most of it. The written question filters for something harder to name — intellectual honesty, a willingness to look at past work critically.

Stage 3: The live interview

Anyone who clears the assessment gets a 60-minute live conversation with a senior engineer on our panel. We cover three things:

• A short code review of something they've written, so they can walk through tradeoffs out loud
• A system design conversation on a problem adjacent to their stack
• Behavioural questions — how they work async, how they handle disagreement, how they scope ambiguous problems

No whiteboard gotchas. No leetcode mediums. If you're a senior engineer, the interview should feel like a technical conversation with a peer — because that's what it is. About 65% of interviewees pass.

Stage 4: Reference check

Two references, one of whom has managed the candidate and one of whom has worked alongside them. We ask short, specific questions: "What's a project where they went above what was asked?" "What would you want to see them improve?" "Would you hire them again?" We weight the specifics, not the superlatives.

The numbers, end to end

If you start with 1,000 applicants:

• About 600 complete the written application
• About 390 make it past application review
• About 135 pass the technical assessment
• About 88 pass the live interview
• About 80 clear the reference check

Eight percent clear. So why do we say 1%? Because the 1% number is across inbound volume — which includes a long tail of people who start the form and abandon it, plus a meaningful number of duplicate or clearly-spam submissions. The 8% figure is the one engineers who actually apply should think about.

What we've learned

Three things, after running this at scale for a while.

Credentials don't predict what we'd guess. Engineers from unknown companies do as well as engineers from famous ones. Degree doesn't predict pass rate. Years of experience beyond three or four is only weakly predictive. The best single predictor is the written response about a regretted decision.

Communication is underweighted everywhere else. We've had technically brilliant engineers fail our bar because they couldn't explain their own code. We've had moderately-skilled engineers pass because they were unusually clear. In production work, over many months, the clear communicator out-ships the brilliant one almost every time.

Humility is rare and valuable. The single biggest differentiator between passing and failing isn't talent. It's whether the candidate can talk about their own mistakes without flinching. If you can, most teams want to hire you. If you can't, most teams eventually find out and regret the hire.

If you want to try

If any of this sounds like a bar you want to clear, the application form is here. If you don't pass, you get specific feedback and can reapply in six months. Many of our best engineers passed on their second attempt.

The pandemic-era debate about remote work has mostly settled into a tired equilibrium. Most companies have landed on "hybrid," which is usually a compromise no one actually loves. We think that's a mistake, and we think it's worth spelling out why.

Hybrid is the worst of both worlds

If you're in the office three days a week, you still need a desk, a commute, and the social choreography of in-person work. But you also don't get the thing in-office work is supposedly good at: spontaneous collaboration. That only works if everyone is in at the same time, which nobody organises reliably.

Meanwhile, the remote days get treated as "deep work" days — but you still have meetings scheduled across both kinds of days, so the deep work never quite materialises. Hybrid is mostly a cost centre that produces in-office overhead without in-office benefits.

Remote-first actually works — if you rebuild for it

The common mistake is to try to do in-office work remotely. You set up Zoom calls on the same schedule you used to hold meetings in the conference room, expect people to be online during the same hours, and complain when productivity dips.

Remote-first teams that actually work don't do this. They rebuild the basic unit of collaboration around writing, not speaking. A good remote-first team:

• Defaults to async. Every major decision is written down. Meetings are the fallback, not the default.
• Measures output, not hours. Nobody cares when you worked as long as the thing shipped.
• Writes things people can actually read later. Decision docs, postmortems, weekly updates — all durable, all searchable.
• Over-communicates status. Not surveillance — just a shared understanding of what's in flight.

When this is in place, remote-first is not just "as good as" in-office — it's better. You get a larger talent pool, a quieter working environment, fewer context-switching meetings, and permanent documentation of everything that matters.

What breaks

Two things reliably break in remote-first engineering teams.

Junior engineers learn more slowly. They miss the osmotic learning that happens next to senior engineers at the desk. The fix is deliberate: structured mentoring, scheduled one-on-ones, and real time budgeted by seniors to answer questions. It's more work than in-office, but the work is visible and measurable.

Relationships get thin. You can ship a lot of code with strangers. You can't really have a hard disagreement with them. Remote-first teams that work invest in occasional in-person time — ideally two to four times a year — to maintain the social bank account. Not to do work. Just to know each other.

The market view

Here's the thing that tips the argument for us. The best engineers in the world don't all live in your city. They never did. In-office requirements filter for geography, which has almost nothing to do with engineering quality. Remote-first lets you hire the actual best fit for the role. In a tight market for engineering talent, that matters more every year.

This is, not incidentally, the bet behind our whole business. We vet engineers globally because the talent is globally distributed, and we match them to companies that have figured out how to work with remote-first teams. Nearly everyone we place works remotely. Almost none of our customers regret it.

The bottom line

If you can run a remote-first engineering team well, you should. The talent pool is bigger, the working conditions are better, and the documentation you'll accumulate is valuable in its own right. If you can't run one well yet, don't fake it with hybrid — either commit to building the async muscles, or commit to being in-office. The worst outcome is the compromise in the middle.