Technical Hiring Process Design
Offers are being declined, or accepted by people who do not work out. We rebuild the pipeline, the interview loop and the first ninety days, and train your interviewers to run it without us.
- Who
- Founder holds the engineering leadership seat; the delivery team executes underneath it.
What you're seeing
- A funded headcount plan is not converting into hires.
- Usually means The budget is not the constraint and neither, usually, is the market. Something in the process between a good candidate appearing and an offer going out is losing them, and it is almost always measurable.
- Interviews run differently depending on who happens to be free.
- Usually means There is no loop, there is a rota. Two candidates who saw different interviewers cannot be compared, so the decision defaults to whoever advocates hardest afterwards.
- Offers are declined at a rate nobody has calculated.
- Usually means Either the process took long enough for a competing offer to land first, or something in it told the candidate what working here would be like. Both are visible in the timestamps.
- New engineers take a quarter to become useful.
- Usually means There is no ramp plan, so a new hire's first month is spent discovering what nobody wrote down. It costs about what a failed hire costs, with the difference that nobody counts it.
- Two engineers doing the same work are paid differently and neither knows why.
- Usually means There are no levels, so every offer was negotiated from scratch. It shows up as a hiring problem and leaves as a retention one.
Where offers get lost
Rarely at the offer. Usually four steps earlier, and usually somewhere with a timestamp on it.
A scheduling gap where a candidate waits nine days for a second interview, which is long enough for a competing process to finish. An exercise that quietly takes a weekend. A loop where three of the four interviewers ask about the same thing and nobody asks about what the role actually requires. A decision meeting where the argument is settled by whoever advocates hardest, because the interviews produced impressions rather than comparable evidence.
None of these look like problems from inside. Each one individually is defensible. Together they produce a funnel where the strongest candidates leave earliest, because the strongest candidates have the most alternatives and the least patience.
The first thing we do is put numbers on the stages: time in each, drop rate at each, and the gap between a candidate becoming available and the offer arriving. That usually locates the problem before anyone is interviewed about it.
What a loop has to do
Two things, and most loops do neither reliably.
Produce comparable evidence. Every candidate for a role sees the same stages, assessed against the same written expectations, by interviewers who have agreed what those expectations mean. This is the part that cannot be shortcut with a document — agreement comes from grading real submissions together and arguing about where you disagree.
Measure what the role needs. A loop assembled from whatever interviews the team already had tends to test general programming ability four times. If the role is mostly integration work against unreliable third parties, or mostly maintaining a system nobody else understands, the loop should say so, and one stage should be about that.
Everything else — the number of stages, the format, whether there is a take-home — follows from those two and from how much of a candidate’s time you can reasonably ask for.
The first ninety days are part of the loop
A hire who takes a quarter to become useful costs approximately what a failed hire costs. The difference is that the failed hire is visible and the slow ramp is absorbed.
So onboarding gets designed alongside the interview process rather than after it: what a new engineer should have shipped by day thirty, sixty and ninety, who owns unblocking them, and which parts of the system they are expected to be able to change unsupervised by the end. Where a ramp plan exists and is not met, that is early information about a hire, which is the other reason to have one.
Where this sits
This is the hiring track sold on its own. Where the underlying problem is that nobody is holding the technical leadership seat — and the hiring symptoms are downstream of that — the retainer is the right shape: Fractional CTO includes running the loop until your interviewers are calibrated to run it themselves.
Where hiring is one of several things being rebuilt at once ahead of a funding event, it is a track inside Delivery Implementation rather than a standalone engagement, sequenced early because senior hires take two to three quarters to arrive and become useful.
What this covers
Each of these is a capability with its own page, its own order of work and its own outputs.
| Capability | What it means |
|---|---|
| Hiring Pipeline Design | The path a candidate takes from first contact to signed offer, measured at every step. Most good candidates are lost to timing rather than to judgement. |
| Interview Loop Design | A loop where each stage measures something different and the stages combine into a decision. Structured, because unstructured interviews mostly measure how much the interviewer enjoyed the conversation. |
| Interviewer Calibration | Training your engineers to run the loop and agree on what they saw. A rubric only means something once the people applying it produce the same score for the same candidate. |
| Onboarding & Ramp-Up | A new engineer productive in weeks rather than a quarter. A plan with named outcomes at thirty, sixty and ninety days, and an environment that works on the first morning. |
| Career Ladders | Levels with observable criteria, a management track and an individual contributor track that genuinely reach the same seniority, and a mapping of your existing people onto it. |
| Performance Review Design | A review cycle that produces decisions people can act on, anchored to the ladder and calibrated across managers so a rating means the same thing in two teams. |
| Team Topology & Org Design | Team boundaries drawn around the system rather than around history. Who owns what, what each team can ship without waiting, and where the handoffs that cost you weeks are. |
How we decide
We do not source candidates
Costs It means we cannot fix a genuine top-of-funnel problem, and some companies have one.
Sourcing is a different business with a different cost structure, and doing both makes the diagnosis untrustworthy — a provider paid per placement has an interest in concluding the pipeline is the problem. What we fix is the process candidates move through, which is where good ones are usually lost.
Calibration happens against real submissions, with your engineers in the room
Costs It is slow, it takes senior engineers away from delivery for a day, and it surfaces disagreements people would rather not have in public.
A rubric written by one person and circulated is an artefact, not an agreement. Interviewers only converge by grading the same real work and arguing about the gap, and that argument is the deliverable. Skipping it produces a loop that looks structured and still measures who the interviewer liked.
Take-home exercises are capped hard, and the cap is enforced
Costs A capped exercise reveals less than an uncapped one, and some candidates will exceed it anyway.
An uncapped take-home does not measure engineering ability, it measures available evenings — which selects against people with caretaking responsibilities and second jobs, and correlates with nothing you are hiring for. Enforcing the cap means grading against what the cap allows, not against the best submission received.
Levels are settled before the loop is rebuilt
Costs It turns a hiring engagement into a compensation conversation the company was not planning to have.
You cannot make consistent offers without knowing what level you are hiring at, and you cannot retain the people you hire without a visible path between levels. Rebuilding a loop on top of undefined levels produces comparable interview signal feeding an incomparable offer.
Fixing the process, or buying around it
Four responses to open engineering roles that are not closing. They solve different problems and get sold interchangeably.
| Option | What it changes | What you keep afterwards | When it fits |
|---|---|---|---|
| Rebuilding your own process | The pipeline, the loop, calibration and the first ninety days | A process your team runs without help, and interviewers who agree | You are hiring continuously and the loop is the constraint |
| Recruiting agency | Top of funnel — more candidates arrive | Nothing structural; the fee recurs with each hire | Sourcing is genuinely the constraint and the loop already works |
| Embedded recruiter or RPO | Coordination and throughput, for the duration | Whatever they documented, which varies | Sustained volume across many roles at once |
| Executive search | Access to a small number of senior candidates | One hire | A leadership seat where the pool is small and closed |
Row two is the most common purchase and the most common mismatch. More candidates arriving into a loop that loses them produces more expensive losses, and the agency invoice does not tell you that.
Is this you?
- A funded headcount plan that is not converting into hires
- Interviews run differently depending on who happens to be free
- New engineers taking a quarter to become useful
- Companies wanting candidates sourced for them — that is a recruiting agency, and we are not one
- Teams hiring one person a year, where a process costs more than it returns
- Anyone looking to outsource the hiring decision itself
How we run it
Your interviewers, calibrated
An interview loop only produces comparable signal if the people running it agree on what good looks like. We calibrate against real submissions with your own engineers in the room, which is slower than writing a rubric and the only thing that makes a rubric mean anything.
Where this has run
Frequently Asked Questions
Sources
- Google re:Work — Structured interviewingrework.withgoogle.com
- Team Topologiesteamtopologies.com
- Melvin Conway — How Do Committees Invent?melconway.com
Page reviewed

