When TA professionals talk about time to hire, usually the most common calculation that comes to mind is a scenario like this:
- Over a given timeframe, we hired three people
- it took 30 days to hire Steve, 40 days for Susan, and 50 days for Mike
- Therefore, our average time to hire is 40 days
However, as we’ll explain in this doc, this is not how we calculate time to hire at Gem. Let’s call the method we just described as “only-hired”, since we’ve taken only the candidates that were hired. Instead, the way we actually calculate time to hire is what we call “All-candidate”. It involves:
- For each stage, calculate the average time in stage for all candidates that passed through that stage.
- Sum up the time in stage for each stage between app created and hired.
And importantly, these two methods of calculation can actually arrive at different numbers. To explain this difference visually, here’s an info-graphic:
But why?
So why do we calculate time to hire this way? A few reasons:
- More data points - There are way more candidates in the earlier stages of the pipeline, so we can leverage those to reduce variance in this metric.
- Candidate experience matters - One of the reasons you might care about time to hire is because it’s a good proxy for candidate experience. There are good reasons to care about candidate experience even for candidates you didn’t hire. It’s possible you’re having huge delays in your hiring pipeline that are causing people to drop out, and you wouldn’t want to be blinded by throwing out data from people that aren’t being hired.
Workarounds
Ok, but what if you really do want only-hired time to hire? The good news is, you can do this by adding an `app stats: hired` filter on your widget!
- But why?
- Workarounds