Build · Create · Ops & Automation
Candidate work-sample assignment spec
A ready-to-send work-sample assignment with a fixed time box, deliverable definition, and a weighted scoring rubric.
You receive: A JSON object: { role_title, scenario_field (the real problem framed), candidate_instructions_field, deliverable_definition_field, time_box_hours, rubric[] (each {criterion, weight_pct, level_descriptions {1,3,5}}), submission_format (enum: doc|repo|slides|spreadsheet), fairness_notes {paid bool, accommodations_field} }.
Part of Lead Team
Example
A sample of what this play produces. Your result is generated for your inputs.
Role title
Founding Engineer, Play Catalog
Scenario field
STUD is a living system for a venture: it knows the business, does the work, and learns from every result. The catalog today holds 265 plays across 14 playbooks, and every deliverable passes its play's acceptance check before it lands. The real engineering problem behind that number is authoring acceptance checks fast without letting quality drift: a play is only as trustworthy as the validator that settles it. Your scenario is the actual job: take one new play design, a 'meeting-notes action-item register' (a table of action items with owner, due date, and status), and build the machine acceptance check that would let it settle on the platform.
Candidate instructions field
Work alone, time-boxed to 4 hours total (be honest, the rubric does not reward overtime polish). In a fresh repository: (1) write a Python validator function validate(submission, params) that parses a JSON array of action-item rows and enforces at least 5 named checks you choose and justify (for example: required fields non-empty, owner present on every row, due dates ISO-formatted, status from a fixed enum, a minimum row count taken from params); (2) include 3 fixture submissions, one passing and two failing for different reasons, plus a small runner that prints each check's pass/fail; (3) write a README section, 300 words max, explaining which failure modes you chose NOT to check and why (the boundary matters as much as the checks). Use only the Python standard library. Every candidate receives this identical brief, the identical play design, and the identical rubric below, in advance.
Deliverable definition field
A public or shared Git repository containing: validator.py (the validate entry point), fixtures/ (1 passing, 2 distinct failing JSON submissions), run_checks.py (prints a per-check verdict table for each fixture), and README.md (setup in 3 commands or fewer, the checks you enforce, and the 300-word scope-boundary note). Done means run_checks.py runs from a clean clone with only the standard library and shows the passing fixture green on all checks and each failing fixture red on the intended check.
Time box hours
4
Rubric
- Criterion
- Validator correctness
- Weight pct
- 35
- Level descriptions
- 1
- Validator crashes on a fixture, or a failing fixture passes: the check does not actually enforce what it names.
- 3
- All fixtures settle as intended, but at least one check is looser than its name claims (for example a date check that accepts any string containing a dash).
- 5
- All fixtures settle as intended, each check enforces exactly what it names, and edge inputs (empty array, wrong types, missing keys) fail cleanly with a named check rather than an exception.
- Criterion
- Check design judgment
- Weight pct
- 25
- Level descriptions
- 1
- Checks are trivial restatements (JSON parses, array non-empty) with no connection to what makes an action-item register trustworthy.
- 3
- Checks cover the obvious field rules but the scope-boundary note is thin: it does not say what was deliberately left unchecked or why.
- 5
- Checks target the failure modes that would actually mislead a buyer (silent missing owners, fake enum values, count padding), and the boundary note names concrete unchecked failure modes with defensible reasons.
- Criterion
- Failing-fixture quality
- Weight pct
- 20
- Level descriptions
- 1
- The two failing fixtures fail for the same reason, or fail on parse rather than on a designed check.
- 3
- The failing fixtures exercise two different checks but are unrealistic (obviously mangled JSON rather than plausible near-miss work).
- 5
- Each failing fixture is a plausible near-miss deliverable that a rushed agent could actually produce, and each trips exactly the intended check while passing the others.
- Criterion
- Repo clarity and reproducibility
- Weight pct
- 20
- Level descriptions
- 1
- The runner does not work from a clean clone, or setup needs undocumented steps or non-standard-library dependencies.
- 3
- Runs from a clean clone but the output is hard to read: verdicts are not attributable to named checks per fixture.
- 5
- Clean clone to full verdict table in 3 commands or fewer, per-check named results per fixture, README accurate to the code as submitted.
Submission format
repo
Fairness notes
- Paid
- false
- Accommodations field
- The 4-hour time box may be split across up to 3 sittings within one week, and candidates may request an extended window or an alternative walkthrough format (a recorded screen narration instead of a live review) by replying to the assignment email; requests do not affect scoring. The assignment is unpaid because it is capped at 4 hours and the work product is a throwaway exercise on a fictional play design, not production work STUD ships; candidates keep their repository. Every candidate receives this identical brief and the full rubric in advance.
Opens soon
STUD opens runs for everyone soon, on every play at once.
Get early access to STUD the day it goes live.