Build · Assess & Decide · Ops & Automation
Structured hiring decision scorecard
A structured scorecard where each interviewer's vote and rationale are recorded and the final verdict provably follows your decision rule (no after-the-fact rationalization).
You receive: A structured scorecard (JSON) that passes the completeness + decision-rule-consistency checks.
Part of Lead Team
Example
A sample of what this play produces. Your result is generated for your inputs.
no_hireDecision rule: any_strong_no_blocks
- Candidate
- Avery Kestrel (fictional example candidate)
- Role
- Founding operator, catalog quality and judge infrastructure
- Context
- STUD.com is pre-seed, pre-revenue, one founder-operator (Dan Schmitz) with concierge capacity of about 30 plays per week. The first hire has to raise that ceiling without lowering the acceptance-check bar: the catalog is 265 plays across 14 playbooks and every deliverable must pass its play's acceptance check before it lands. The decision rule is any_strong_no_blocks because at a two-person company one wrong hire is existential, so any interviewer's no_hire ends the loop, no averaging.
- Verdict note
- Rule applied: any_strong_no_blocks. One recorded no_hire (Marta Oyelaran) blocks, so the verdict is no_hire regardless of the 2 to 1 split. The scorecard records the verdict the rule forces, not the one the majority preferred, which is the point of fixing the rule before the loop starts.
Interviewers
| Name | Focus | Vote | Rationale |
|---|---|---|---|
| Dan Schmitz (founder) | Judgment on catalog quality and the acceptance-check bar | hire | Walked through three live plays and correctly identified where the validator floor is weaker than the published contract. Understands that a green check is a floor, not a quality measure, which is exactly the judgment the operator seat needs. Would raise weekly play throughput without lowering the bar. |
| Priya Nandakumar (advisor, fictional example) | Python judge harness and validator authoring | hire | Read the deterministic judge harness cold and explained the process-isolation boundary and why validators run as data. Wrote a small validator live with clean edge-case handling. Strong enough to own judge-side authoring within the first month. |
| Marta Oyelaran (advisor, fictional example) | Operating cadence and buyer-facing communication | no_hire | Sharp technically, but in the operating scenario the candidate proposed batching buyer results to weekly digests to protect focus time. At concierge stage the compounding loop depends on results landing and feeding the next run fast; deprioritizing that surface is a real mismatch for this specific seat, not a coachable gap on a two-person team. |
Work trial
- Task
- Author one new settling play end to end from a mined design: intake schema, validator as data, and a sample deliverable that passes the real judge, in one working session.
- Result
- pass
- Notes
- Play settled green on the first judge run; the intake left one required buyer decision hidden behind an advanced group, caught in review.
Red flags
- Prefers weekly batched buyer communication, which conflicts with the fast result-to-next-run loop the living system sells
- No prior experience being the only operator on call for a production marketplace
Opens soon
Cost50 credits
ProtectionSpent when the run starts · returned only if STUD is at fault
STUD opens runs for everyone soon, on every play at once.
Get early access to STUD the day it goes live.