Build · Create · Ops & Automation
Work-sample interview question bank
A reusable, competency-mapped question bank where each question has a predetermined acceptable answer and red-flag list.
You receive: A JSON object: { role_title, competencies[] (the criteria being assessed), questions[] (each {id, prompt, competency (must be one of competencies), category enum: problem-solving|forward-looking|learning-agility|selling, expected_answer_points[], red_flags[]}), banned_questions_screened[] }.
Part of Lead Team
Example
A sample of what this play produces. Your result is generated for your inputs.
Role title
Founding Engineer, STUD platform
Competencies
- Agent orchestration and judge reliability
- TypeScript platform engineering
- Marketplace catalog and data modeling
- Product judgment under founder-stage constraints
Questions
- Id
- Q1
- Prompt
- STUD's acceptance check screens every deliverable before it lands, and one validator starts accepting artifacts that are structurally valid but obviously low quality. Walk me through how you would diagnose whether the defect is in the validator's rules, the play's contract, or the producer, using only logs and the committed reference.
- Competency
- Agent orchestration and judge reliability
- Category
- problem-solving
- Expected answer points
- Separates the enforced contract (what the validator checks) from quality (what a buyer would accept), and names that a green check is a floor
- Proposes reproducing the accepted artifact against the validator locally before touching code
- Suggests an independent audit against external truth, not just re-reading the validator
- Red flags
- Assumes a passing validator means the artifact is good
- Jumps to rewriting the validator without reproducing the failure
- Id
- Q2
- Prompt
- An AI agent running a play times out on 3 percent of runs, always on the same task family. You have the judge harness source and run transcripts. Describe your first hour.
- Competency
- Agent orchestration and judge reliability
- Category
- problem-solving
- Expected answer points
- Clusters the failing runs to isolate what the task family shares (payload size, tool calls, validator timeout)
- Checks the harness timeout budget against the observed distribution before changing agent behavior
- Defines a measurable exit criterion (timeout rate below a stated floor) for the fix
- Red flags
- Proposes raising the timeout globally as the first move
- No mention of measuring the failure distribution
- Id
- Q3
- Prompt
- Here is a real constraint from our codebase: a schema edit must ship with a generated migration or the deploy gate fails. Design the developer workflow that makes doing the right thing the default, and tell me where it can still silently break.
- Competency
- TypeScript platform engineering
- Category
- problem-solving
- Expected answer points
- Puts the drift check in the same gate developers already run locally, not a separate honor-system step
- Names a concrete silent-failure mode (for example a migration generated against a stale baseline, or a squashed journal mismatch)
- Treats the CI gate and the local gate as one script so they cannot diverge
- Red flags
- Relies on documentation or code review to catch missing migrations
- Cannot name any failure mode of their own design
- Id
- Q4
- Prompt
- Our catalog is 265 plays across 14 playbooks, seeded from a single source file and synced to the production database on deploy. If we grow to 2,000 plays, what breaks first in that design and what would you change ahead of the pain?
- Competency
- Marketplace catalog and data modeling
- Category
- forward-looking
- Expected answer points
- Identifies a concrete first bottleneck (seed-file merge conflicts, sync diff time, or review surface per change)
- Proposes an incremental step (sharded seed modules or per-playbook ownership) rather than a rewrite
- Keeps the property that the committed seed stays the source of truth for counts and content
- Red flags
- Proposes moving authoring into the database with no committed source of truth
- Answers only in generic scaling terms with no reference to the described design
- Id
- Q5
- Prompt
- Model our credits system: plans grant monthly credits, plays cost 10 to 40 credits, and one-time packs exist. Sketch the tables and the one invariant you would enforce at the database layer rather than in application code, and say why.
- Competency
- Marketplace catalog and data modeling
- Category
- problem-solving
- Expected answer points
- Proposes an append-only ledger of credit events rather than a mutable balance column
- Names a database-enforced invariant (ledger sums non-negative per account, or immutable rows) with the reasoning
- Considers how refunds or failed runs reverse an entry without editing history
- Red flags
- Stores a single mutable balance with no event history
- Puts money invariants only in application code because it is easier
- Id
- Q6
- Prompt
- You inherit a Next.js app where the same check runs in CI and locally via one shared script. A teammate proposes letting CI run a faster scoped subset. Argue both sides, then commit to a position for a two-person team.
- Competency
- TypeScript platform engineering
- Category
- selling
- Expected answer points
- States the real tradeoff: scoped CI is faster but green no longer means the full suite ran
- Commits to a position with a reason tied to team size and blast radius, not preference
- Proposes a compensating control if scoping is adopted (a scheduled full run or an invariant lane)
- Red flags
- Refuses to take a position
- Treats CI speed as free with no trust cost
- Id
- Q7
- Prompt
- Tell me about a technical belief you held a year ago that you have since reversed. What evidence moved you, and what did the reversal cost?
- Competency
- Product judgment under founder-stage constraints
- Category
- learning-agility
- Expected answer points
- Names a specific belief and the concrete evidence that changed it, not a vague growth story
- Describes a real cost paid (rework, a shipped mistake, an argument conceded)
- Shows the updated belief is held provisionally, with what would change it back
- Red flags
- Cannot name any reversed belief
- The example is a disguised strength with no real cost
- Id
- Q8
- Prompt
- STUD is pre-revenue with one founder-operator and a soft launch live. You get one engineering quarter. Pitch me the single bet you would make with it and the metric that proves you right or wrong.
- Competency
- Product judgment under founder-stage constraints
- Category
- selling
- Expected answer points
- Picks one bet and explicitly declines the others, with a stage-appropriate reason
- Defines a falsifiable metric and a timebox, not a vanity measure
- Connects the bet to the compounding-workspace thesis (results feeding later runs) rather than a generic feature
- Red flags
- Hedges across three bets to avoid being wrong
- Metric chosen cannot fail (no baseline, no threshold)
- Id
- Q9
- Prompt
- In eighteen months, what part of running AI agents against acceptance checks do you expect to be commoditized, and what should STUD therefore refuse to build in-house today?
- Competency
- Product judgment under founder-stage constraints
- Category
- forward-looking
- Expected answer points
- Makes a concrete commoditization call (model orchestration, sandboxing, or generic eval tooling) with reasoning
- Derives a build-versus-buy refusal from the call, not from taste
- Identifies what stays defensible (the workspace facts and accumulated results) and protects it
- Red flags
- Predicts everything commoditizes or nothing does
- No link between the prediction and a build decision
- Id
- Q10
- Prompt
- A play's validator and its buyer-facing description drift apart: the copy promises a check the validator never runs. The cheap fix is editing the copy; the right fix might be extending the validator. How do you decide, and how do you keep the whole catalog from drifting the same way?
- Competency
- Agent orchestration and judge reliability
- Category
- problem-solving
- Expected answer points
- Decides from the buyer's reliance: if buyers chose the play for the promised check, the validator grows; otherwise the copy shrinks
- Proposes a mechanical catalog-wide audit (copy claims versus enforced checks) rather than fixing one instance
- Names who owns keeping the two in sync going forward
- Red flags
- Always edits the copy because it is cheaper
- Treats the single instance as the whole problem
Banned questions screened
- What are your greatest strengths and weaknesses?
- What is your greatest weakness?
- Why are you the best candidate for this job?
- Where do you see yourself in five years?
- What is your dream job?
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.