What happens before a name reaches your shortlist.

Step one

The calibration brief.

Before any sourcing starts, the brief fixes what "good" means for this role: the actual work, the stack, the seniority bar, the evaluation rubric if one exists, location or timezone constraints, and the engagement shape (contract trial, project team, or permanent search). A vague brief produces a vague shortlist, so this step is where most of the disagreement gets resolved before anyone's time is spent on a candidate.

Step two

Sourcing.

Outreach runs through two separate channels. One is four years of mentoring in a US and Canada engineering programme; the other is ongoing membership in senior engineering communities in India. Those reach different populations of engineers, so both get used rather than treated as interchangeable. Sourcing also draws on targeted outreach, public engineering work, and direct referrals — not resume-database keyword matching.

Step three

What gets verified, and how.

Three things are checked before a candidate reaches the technical review:

• Direct-hire history. Claimed employment is checked against public profiles, published work, and (where it exists) a listed employer or project history. Contract-only work is noted as such, not folded into full-time tenure.
• Availability. Hours per week and start window are confirmed in writing before the technical review, not assumed from a resume.
• Instruction-following. Tested directly in the written-spec exercise below, not inferred from interview conversation.

Step four

The written-spec exercise.

Coding evaluation and AI training work means following a written spec or rubric consistently under ambiguity. The exercise tests exactly that: the candidate is given a written task — typically a code review or a task-design brief — with explicit instructions, and is scored on whether their answer follows what was actually asked rather than what they assumed was meant. Candidates who produce strong but off-spec answers are noted as a risk, not scored as a pass.

Step five

The paid work sample.

Optional, and used before a larger commitment rather than instead of one. It is real work against the client's own rubric — usually a small queue of reviews or tasks, not a synthetic test — scoped to a fixed number of hours and paid regardless of outcome. It tests two things the earlier steps cannot: calibration against the client's specific bar, and throughput at something closer to real volume.

Redacted example

An example screening record.

The record below follows the shape the method above actually produces. The candidate is a composite built for illustration, not an actual placement — this practice does not have a placement track record yet, and this page does not claim one. What it shows is the method: what gets checked, what a written exercise reveals, and how a verdict gets written up.

Candidate 04 — role under review: Coding evaluator

Verdict: Advance to paid work sample.

Evidence reviewed

• Six years of direct, full-time backend and platform engineering, most recently at a mid-size fintech company (employer withheld). Tenure and role confirmed against a public profile and a published conference talk; not contract-only work.
• Repository-level code review: a real pull request (redacted) touching a payment retry path, roughly 400 lines changed.
• A 45-minute structured technical conversation covering the review above and two follow-up scenarios.
• Availability confirmed in writing: 35 hours a week, available for a minimum of three months.

The exercise given

Written spec: “Review the attached pull request. List every correctness or security risk you would block on, in priority order, and explain your reasoning for the top three.”

How they answered

Identified a retry race condition in the payment path as the top-priority risk and correctly traced its impact across a service boundary the diff itself did not touch — the strongest signal in the review, since it is not visible from the diff alone. The written explanation held up when read by a second reviewer with no context from the original conversation. One lower-priority issue, inconsistent error logging, was missed until prompted directly.

Strengths

• Found the retry race unprompted and explained the failure mode correctly.
• Traced impact across a service boundary rather than stopping at the local diff.
• Wrote a rationale that stood on its own for a reviewer without the original context.

Risks

• Missed one lower-priority issue (error logging) until prompted.
• Review pace on this single item was slower than the role needs at volume — untested whether that holds under a full queue.

Open questions

• How the candidate calibrates against a rubric they did not write themselves — not tested in this screen.
• Throughput at volume, since this was one review, not a queue.

Next evidence

A paid work sample scoped to a five-review queue against the client's own rubric, to test calibration and throughput before a hiring decision.