Build · Create · Ops & Automation
Reference-check call script and scorecard
A structured reference-check script with a confidentiality preamble, probing questions, and a numeric endorsement scorecard.
You receive: A JSON object: { candidate_label, role_title, confidentiality_preamble_field, relationship_question_field, questions[] (each {prompt, probes_for enum: strengths-weaknesses|reliability|open-mindedness|collaboration|other, followup_field}), endorsement_capture {scale_min, scale_max, why_required bool}, scorecard_fields {summary, recommendation enum: strong-yes|yes|reservations|no} }.
Part of Lead Team
Example
A sample of what this play produces. Your result is generated for your inputs.
Candidate label
Candidate A (illustrative)
Role title
Founding Engineer
Confidentiality preamble field
Before we start: everything you share stays confidential. Nothing you say will be traceable to you, inside or outside STUD. Your answers inform one hiring decision for our Founding Engineer role and are never shared with the candidate in attributable form. If any question feels off limits, say so and we skip it.
Relationship question field
To ground the rest of the call: how do you know the candidate, in what roles did you work together, over what period, and how closely did you see their day-to-day work?
Questions
| Prompt | Probes for | Followup field |
|---|---|---|
| STUD ships a catalog of AI-run plays where every deliverable must pass an acceptance check before it counts. Tell me about a time the candidate owned a system where correctness was enforced by machinery rather than review. What did they build, and where did it fall short? | strengths-weaknesses | If you could add one skill to make them twice as effective in that kind of role, what would it be? |
| As the first engineering hire alongside a solo founder, there is no manager backstop. When the candidate committed to a date or an outcome, how often did reality match the commitment? Give a specific example either way. | reliability | What did they do when they realized they were going to miss? |
| Our product direction changes as the system learns from real runs, so positions get abandoned often. Describe a time the candidate was shown strong evidence against an approach they had championed. What did they actually do next? | open-mindedness | Did they change course fully, partially, or defend the original approach? |
| STUD is a two-person-scale company where the founder and the engineer share one backlog. Tell me about the candidate working with a non-engineering counterpart, a founder, designer, or ops lead. What friction showed up and how was it resolved? | collaboration | Would that counterpart choose to work with them again? How do you know? |
| What kind of work environment brings out this candidate's worst? Be concrete: pace, ambiguity, oversight level, team size. | strengths-weaknesses | How closely does a pre-revenue, one-founder company with weekly shipping match that description? |
| Everyone has a failure mode under pressure. What is theirs, and how did it show up when a deadline or an outage hit? | reliability | Did it get better over the time you knew them? |
| Is there anything I have not asked about that I should know before we make this hire? | other | If you are hesitating on anything, what is the closest you can come to saying it? |
Endorsement capture
- Scale min
- 1
- Scale max
- 10
- Why required
- true
Scorecard fields
- Summary
- Strong systems ownership and honest self-correction under evidence; watch the pressure failure mode named in question 6 and confirm it against the second reference before offer.
- Recommendation
- yes
Opens soon
STUD opens runs for everyone soon, on every play at once.
Get early access to STUD the day it goes live.