Where the forty-four days actually go

The median May fill took 44 days, and the number gets blamed on sourcing by reflex. Walked stage by stage, nine days went to the first screen, twelve to the offer decision, and eleven to the candidate’s notice period. The fix is not more sourcing.

RuleDecompose time to fill by stage on the same clock the total uses. The stage that eats the days is the only one worth fixing.

Neversum stage medians and call it the median fill. Medians do not add; decompose one real requisition, or use means and say so.

◆ The median fill, decomposedone real requisition, posting to start.

REQ-2101, Sales, 44 days total	Days
Posting to first screen	9
Screen to first interview	8
Interviews to offer extended	12
Offer extended to accepted	4
Acceptance to start date	11
Posting to start	44

This is the median requisition from the time to fill page, walked stage by stage on the same posting-to-start clock, and its stages sum to its 44 exactly. The two widest rows are the offer decision and the notice period, neither of which is sourcing. Sample values are illustrative, never client data.

◆ Stage medians across the five fillsthe pattern, with the caveat stated.

Stage	Median days
Posting to first screen	8
Screen to first interview	7
Interviews to offer extended	13
Offer extended to accepted	4
Acceptance to start date	12

These are per-stage medians across May’s five fills, and they deliberately do not sum to the 44 median total: a median of sums is not the sum of medians. The pattern holds anyway: decision time and notice period, not sourcing, carry the days. One decline on the acceptance page already named process speed.

◆ The owned answerdurations from adjacent stage events.

Every duration is a difference between two dated events on the recruiting fact. No stage timestamps buried in process history, no backdated state fields: the same events the funnel counts, subtracted.

-- per-stage durations for every fill on one clock
SELECT r.req_id, e2.stage,
  JULIANDAY(e2.event_date) - JULIANDAY(e1.event_date) AS days_in_stage
FROM fct_recruiting_event e1
JOIN fct_recruiting_event e2
  ON e2.req_id = e1.req_id AND e2.seq = e1.seq + 1
JOIN dim_requisition r ON r.req_id = e1.req_id
WHERE r.filled_in = '2026-05'

Use case

Problem

Time to fill is disputed as one blended number: nobody can say which stage eats the days, and fixes get aimed at sourcing by default.

What we build

Stage-by-stage durations computed from adjacent dated events on one stated clock, with the median fill decomposed exactly and stage medians beside it.

What you get

The argument moved from whether the number is right to which stage to fix, with the decision and notice-period days visible instead of blamed on sourcing.

Sure the slow part is sourcing?

We build the stage decomposition that shows where the days actually go.

Talk to us

Terms on this page

stage velocity: Days spent between adjacent stages of a fill.
clock: The stated start and stop events a duration uses.
median fill: The requisition whose total sits in the middle of the fills.
notice period: The days between acceptance and start; the candidate’s, not yours.
decision time: Interview-to-offer days; usually the fixable stage.
median of sums: The honest total; not equal to the sum of stage medians.