Measuring quality of hire: beyond gut instinct to data-driven decisions

Some things survive the move between companies because their definitions do not depend on your internal weighting. Retention at a defined checkpoint. Ninety days, six months or twelve months. Time to fill and time to accept. Regrettable versus non-regrettable attrition. Time to productivity, but only if you define it first.^[4]

Time to fill and time to accept are efficiency measures rather than quality measures. That is exactly why so many organizations report them instead. They are the metrics you have, not necessarily the metrics you want.

Everything else is internal. Which is fine. Internal comparison over time is what you actually need.

Only 25 percent of recruiters say they are highly confident in their organisation’s ability to measure quality of hire effectively. The reasons are architectural.^[5]

Pre-hire evidence lives in the ATS: role criteria, interview evidence and interviewer judgements. Post-hire outcomes live in the HRIS and performance system: reviews, promotions and exits. Those systems often do not share a stable key, because candidate and employee records were created separately, by different people, at different times.^[6],[7]

So the question ‘did the people who scored well in structured interviews outperform the people who did not’ requires joining datasets that were never designed to be joined. In practice, someone exports two spreadsheets and matches on name, which works until you have two people called Jan and someone changed their surname.^[6],[7]

The lag is long. Cost per hire is final when an offer is signed. Quality of hire needs time to observe outcomes. Talent acquisition considers the hire complete at start date. The hiring manager owns performance but not the hiring decision. HR owns the systems. The metric sits in the gaps between all three.^[8]

The first problem is worth attacking. If accepted-candidate context and employee context remain connected through a controlled handoff, the join problem becomes smaller. The lag is a fact of nature. The silos are a design decision.

Time to productivity is the metric most worth having and it is often reported without a definition, which makes it a number rather than a measurement.

‘Fully productive’ cannot be defined centrally. It has to be defined per role family, by someone who knows the work, before the person starts. For a fintech, that might mean a backend engineer has shipped three changes independently, has handled an on-call event without escalating something they should have handled, and can explain the reconciliation flow to a colleague.

For a compliance analyst, it might mean clearing a defined volume of alerts at the team baseline, escalating one case correctly and one case that did not need escalating. For a client success specialist, it might mean handling standard account types unsupervised, with resolution quality within the team range.

Three properties make these useful: somebody can observe them, they do not require a performance-review cycle to determine, and they are written down before the person arrives rather than reconstructed afterwards.

One customer defines day 90 for a junior developer using three data points already visible in its systems. Pull-request first-pass rate: by month three, at least half of pull requests are approved. Blocker resolution: when escalating a problem, the developer can state clearly what they already tried. Sprint velocity: they meet their committed story points or ticket count for two consecutive sprints in the final month. Two, not one, because a single sprint is noise.

None of these requires a performance review to determine, and none depends on whether the manager likes the person. At day 90, the conversation is about facts in the systems rather than impressions. If someone is behind on month-one goals, you know in month one, while extra support is still cheap.

Write those definitions once per role family and you have converted a vague ambition into something you can put a date on. Do not write them and time to productivity remains an estimate at the end of the quarter.

Pick four indicators, not twelve. For most fintechs of 50 to 250 people: retention at 12 months, regrettable attrition, time to productivity against a written definition, and hiring-manager satisfaction at 90 days. That is enough to see a trend and few enough to collect.^[6],[7]

Weight them per role family and write the weights down. Retention can matter more for a compliance hire who needed six months of training than for a fixed-term project role. Engineering and sales do not share a definition of ramp. The weights make the number yours, and incomparable to anyone else’s. Both are fine.^[2],[3]

Capture the pre-hire side at the time, not retrospectively: interview judgement, role criteria and concerns raised. If you try to reconstruct why someone was hired eighteen months later, you will reconstruct a story rather than a record.^[6]

Ask the hiring manager at day 90, consistently: ‘Knowing what you know now, would you make this hire again?’ It is crude and subjective. It is also a fast signal you can collect while the longer outcome data arrives.^[6]

Compare yourself to yourself. Last year’s cohort against this year’s. The team that changed its interview process against the team that did not. That comparison is valid, actionable and available.

Quality of hire is a lagging measure. If you begin capturing the right data today, the first useful cohort comparison will not appear next quarter. Faster signals, including the day-90 manager question and time to productivity against written definitions, are worth collecting in the meantime.^[8]

If sponsorship depends on results within two quarters, fix data capture first. Run the fast indicators, then make the case for the full measurement once the pre-hire and post-hire records connect.

Pick someone hired eighteen months ago who has worked out extremely well. Find what you knew before you hired them: the role criteria, what interviewers said and why, the concerns raised and how they were resolved.

If you can produce that in ten minutes, you can measure quality of hire and the rest is arithmetic. If it takes an afternoon of searching, is in somebody’s notebook, or the interviewer has left, quality of hire is not currently available to you. The problem is upstream of the measurement.