SkilsMVP
BootcampCapstone · Deliverable 4

Candidate Screen Scorecard & Shortlist

Builds on Topic 6.

What you'll produce

A recruiter-screen scorecard for one candidate from your Senior Backend Engineer search — the structured record of a 30-minute screening call — plus a 2–3 candidate shortlist summary you'd actually send to Dana, your hiring manager. The scorecard captures the questions you asked, the evidence you heard (not your gut reaction), a bias-aware rating against the must-haves you agreed on at intake, the logistics that kill deals if you miss them (salary expectations, notice period, work authorization, competing offers), and a clear advance / hold / reject recommendation with a reason. This is the artifact that proves you can screen fairly, consistently, and structurally — the core Topic 6 skill — and it's the single document a hiring manager judges your recruiting credibility on, because it's where vague resumes turn into a defensible "yes, interview this person" or "no, and here's why." Do this well and Dana trusts your shortlist enough to stop re-screening your candidates herself.

Instructions

  1. Anchor to your intake must-haves first. Before you write a single question, pull the must-haves from Deliverable 1 (the kickoff brief) and list them as your scoring dimensions — for Northwind that's roughly: production Python or Go at scale, distributed-systems depth, and payments/high-throughput/financial-correctness exposure. You score the role, not the person — this is what keeps you bias-aware and consistent across every candidate.
  2. Write 6–9 structured, open/behavioral questions mapped to those dimensions, in the order you'll ask them: warm-up + "why are you open to a move" → 2–3 technical-depth probes (open-ended, e.g. "walk me through a distributed system you owned") → motivation/what they want next → logistics. Reuse the same core questions for every candidate on this req so your comparison is fair.
  3. Capture evidence, not adjectives. For each answer, note what they actually said or did — a system they built, a number, a decision they made — and probe vague claims on the spot ("you said you 'led' the ledger rewrite — what was your specific part?"). "Smart, great communicator" is not evidence; "designed an idempotency layer that cut double-charges to near-zero across ~4M daily transactions" is.
  4. Surface logistics explicitly and early — do not let the call end without: salary expectations (a real number or range), notice period / earliest start, location/remote and work authorization, and whether they're interviewing elsewhere or weighing a competing offer. A perfect candidate who needs 40% over band, or starts in four months, is a different decision than one who fits — better to know now than after five interviews.
  5. Rate each dimension on a fixed scale (e.g. 1 = below bar · 2 = at bar · 3 = above bar / strong yes), and write a one-line justification per rating tied to the evidence. Add a bias check: re-read your notes and ask "would I rate this the same if they'd come from a different school / company / background?" Note anything you're inferring vs. anything they actually demonstrated.
  6. Make a single recommendation — advance, hold, or reject — and commit to a reason. "Advance" needs the strongest 1–2 signals; "reject" needs a job-relevant reason (not "felt off"); "hold" needs the specific thing that would move it. State the next step (e.g. "advance to Dana's technical screen").
  7. Write the shortlist summary for 2–3 candidates as Dana will read it: 3–5 lines each — name/current role, the one-line "why them," must-have coverage at a glance, salary expectation vs. band, status/risk (e.g. competing offer + timeline), and your ranked recommendation. End with one clear ask of the hiring manager ("can you review and pick who advances by Thursday?").

Worked example

(Req: Senior Backend Engineer, Northwind — ~120-person Series B payments-infra fintech, NYC hybrid. Must-haves from the Deliverable 1 kickoff with Dana (VP Eng): production Python or Go at meaningful scale; real distributed-systems ownership; payments / high-throughput / financial-correctness exposure. Band: $185K–$215K base + 0.15–0.30% equity (Dana's intake ceiling is 0.30%; you open below it). Target: signed offer within 8 weeks; role already open 1 month. Candidate below was sourced via the Deliverable 2 GitHub+LinkedIn Boolean string and replied to the Deliverable 3 outreach.)

Screen scorecard — Candidate A

  • Candidate: Marcus Reyes — Senior Software Engineer, Stripe (Payments Reliability team), NYC. 7 yrs experience (2 yrs Stripe, 3 yrs at a Series C lending startup, 2 yrs at a bank). Screen: 32 min, video, 2026-06-12.
  • Why open to a move (motivation): "Stripe's great but I'm engineer #200 on a system that's already built — I want to own something from zero again." Probed: what does 'own' mean to him — wants design authority and to set the patterns, not just ship tickets. This maps directly to the Northwind pitch (founding-era ledger product, greenfield). Genuine pull, not just "more money."
  • Q1 — Distributed system you owned (depth): Walked through Stripe's payout reconciliation pipeline — designed the idempotency + retry layer that brought duplicate-payout incidents from "a few a quarter" to zero in the last 14 months across a system doing ~6M payout events/day. Probed his specific part: he wrote the dedup keying scheme and the exactly-once consumer logic himself; named the failure mode (at-least-once delivery + non-idempotent writes) without prompting. Evidence, not claim. Strong signal.
  • Q2 — Python/Go at scale (must-have): Production Go for the payout service (3 yrs), Python before that for risk-scoring jobs. Comfortable in both; defaulted to Go for "anything latency- or concurrency-sensitive." Clear, specific. At/above bar.
  • Q3 — Financial correctness (must-have, payments): Unprompted, brought up double-entry ledger invariants and why he distrusts floats for money (uses integer minor units). This is exactly the failure domain Northwind's ledger product lives in. Above bar — rare to hear this in a recruiter screen.
  • Q4 — A hard tradeoff / something that didn't work: Shipped a cache that drifted from source-of-truth and caused a 2-hour reporting discrepancy; owned it, wrote the postmortem, added an invariant check. Accountable, learns from misses — not defensive.
  • Logistics:
    • Salary expectation: "Low 200s base" — said $205K when pushed for a number. Inside band ($185–215K). No flag.
    • Equity: Cares about it; understands Series B equity is a bet. Fine with our 0.15–0.30% range pending level — note Dana's ceiling is 0.30%, so flag to her that a strong-signal candidate like this may land near the top of band, not mid.
    • Notice / start: 3 weeks' notice, can start in ~1 month. Fits the 8-week timeline.
    • Location / work auth: NYC, hybrid 2–3 days works for him. US citizen — no sponsorship needed.
    • Competing offers: ⚠️ Yes — final-round at a later-stage fintech, expects a verbal there in ~10 days. This is a real clock; we cannot let our loop sit.
  • Ratings (1 = below bar · 2 = at bar · 3 = above bar):
    • Python/Go at scale — 3 (production Go on a 6M-events/day service)
    • Distributed-systems ownership — 3 (designed exactly-once layer himself, named failure modes)
    • Payments / financial correctness — 3 (ledger invariants, integer money, unprompted)
    • Motivation / fit for this role — 3 (wants greenfield ownership; pitch lands)
    • Communication — 2 (clear and structured; not a flag either way)
  • Bias check: Strong rating is grounded in what he built and the failure modes he named, not the Stripe brand — I'd score the same evidence the same from a no-name company. Did not down-rate the 2 years at a traditional bank; that's where his ledger/correctness instincts came from. Nothing here is inferred from background; it's demonstrated.
  • Recommendation: ADVANCE — top of pipeline. Two above-bar signals on the two hardest must-haves (distributed systems + financial correctness), in-band comp, fast start. Risk: competing offer with a ~10-day clock. Next step: advance straight to Dana's technical screen this week; do not let scheduling slip.

Shortlist summary — for Dana (VP Eng)

Req: Senior Backend Engineer · 3 candidates screened this week · band $185–215K base. My ranked recommendation below — can you pick who advances to your technical screen by Thursday? One has a competing-offer clock, so speed matters on #1.

  1. Marcus Reyes — Sr. SWE, Stripe (Payouts). Advance — #1. Designed an exactly-once/idempotency layer on a 6M-events/day payout system; brought up ledger invariants and integer money unprompted. All three must-haves above bar. Asks $205K (in band), US citizen, ~1-month start. ⚠️ Competing final-round offer, verbal expected ~10 days — we need to move this week.
  2. Priya Nadkarni — Staff Engineer, Plaid. Advance — #2. Deep distributed systems (owned their event-streaming backbone), strong Python, less direct payments/ledger exposure (data-infra, not money-movement) — the one soft spot vs. must-haves. Asks $215K (top of band), 6-week notice. No competing offer yet; lower urgency. Strong backup / co-finalist.
  3. Daniel Osei — Sr. Backend Engineer, mid-size logistics SaaS. Hold. Solid Go and clear distributed-systems fundamentals, but no payments/financial-correctness background and scale is an order of magnitude below ours. Asks $180K (under band). Worth keeping warm if the top two fall through, but not a technical-screen yes today. Hold reason: would advance if Dana decides payments domain is teachable for the right systems engineer — flagging that call to you.

Recommendation: advance Marcus immediately (clock), advance Priya in parallel as co-finalist, hold Daniel. Two strong in-loop candidates against a tight market is a healthy spot for a req that was stuck a month ago.

Rubric

Levels: Needs work (1) / Solid (2) / Excellent (3). Passing = every criterion at Solid or above.

  • Structured, role-anchored questions — 1: random or yes/no questions · 2: open questions covering the main areas · 3: open/behavioral questions mapped explicitly to the agreed intake must-haves, reusable across candidates for fair comparison.
  • Evidence over impressions — 1: adjectives and gut feel ("smart, great fit") · 2: notes what was said · 3: captures specific evidence (systems, numbers, decisions) and probes vague claims on the spot.
  • Logistics surfaced (incl. salary + competing offers) — 1: missing or only salary · 2: covers salary expectations and start date · 3: covers salary vs. band, notice/start, location/work-auth, and competing offers — flagging any deal-relevant clock or mismatch.
  • Bias-aware, job-relevant assessment — 1: rates on background/school/brand or "culture fit" gut feeling · 2: rates mostly on job-relevant criteria · 3: rates strictly on demonstrated job-relevant evidence, with an explicit bias check separating what was demonstrated from what's inferred.
  • Clear advance/hold/reject recommendation — 1: no call or unjustified · 2: a recommendation with some reasoning · 3: a committed call with a job-relevant reason, the key risk named, and a concrete next step.
  • Hiring-manager-ready shortlist — 1: raw notes dumped · 2: a readable 2–3 candidate summary · 3: ranked, scannable summaries (why-them, must-have coverage, salary vs. band, status/risk) ending in one clear ask of the hiring manager.
  • Coherence with prior deliverables — 1: disconnected from the search · 2: linked to the role · 3: traces cleanly from intake must-haves → sourced/outreached candidates → this fair, structured screen.