Tasks / Leadership

Hire a PM

Can the model design a hiring process that finds the right PM, and make the call on real candidates from the evidence?

Task type v1.1 · 2 tasksLast changed 6 Oct 2026 · ChangelogDifficulty

What AI gets right here, and what you’ll still have to catch

From 16 graded outputs by 8 models. 63% were usable with at most a quick edit.

Reliably right

  1. Produces the required deliverable100% pass
    The output provides a complete loop, scorecard, and decision plan in the requested form, under 900 words, usable by Amara with light edits.
    GPT-6.1 Sol · API · A loop for the first growth PM
  2. Tests what the last hire failed at100% pass
    The loop includes an influence simulation with the Head of Sales and a scorecard dimension on influence without authority, directly testing what the last hire failed at.
    GPT-6.1 Sol · API · A loop for the first growth PM
  3. Finds which rounds line up with performance100% pass
    It compares each round's scores with 12-month ratings, finding behavioral lines up and take-home, presentation, VP Engineering do not.
    GPT-6.1 Sol · API · What our interviews predict

Where it slips

  1. Avoids unsupported claims56% pass
    The claim 'A growth PM in a senior role is likely to be exactly that kind of person' is presented as fact without evidence and is not labelled as an assumption.
    Opus 5.5 · Claude · A loop for the first growth PM
  2. Identifies material uncertainty58% pass
    The output does not name unknowns that could change the hiring decision or the loop design, nor does it say how they would be resolved.
    Sonnet 5.5 · API · A loop for the first growth PM
  3. Defines good for this role first63% pass
    The memo does not explicitly name the competencies that matter most for this PM role and level, nor define what strong and weak look like before designing the interviews.
    Sonnet 5.5 · API · What our interviews predict

How it’s graded

Each check is built on how world-class product and growth leaders do this work, as they’ve described it on Lenny’s Podcast, and names the leader it comes from.

  1. Judges on evidence, not presence

    Does the output judge candidates, or design the process to judge them, on specific evidence of results they drove and how they worked with their team, rather than impressions such as presence, confidence or polish?

    Passes when Asks for or weighs concrete evidence: the metric a candidate moved, the part they played, how they shared credit, what they learned from a failure. Impressions are treated as weak signals.

  2. Defines good for this role first

    Does the output set out what good looks like for this specific role (the competencies that matter most at this level, and what strong and weak look like) before judging candidates or designing interviews?

    Passes when Names the competencies weighted for this role and level, with strong and weak signals, and the judgement or the process follows from them.

  3. Keeps each judgement independent

    Does the output keep each interviewer's judgement independent (written down before the group discusses it), and guard against the loudest voice or the first speaker deciding?

    Passes when Requires or relies on written, independent evaluations before discussion, and discounts views that changed under group pressure.

Plus our standard checks

Uses the supplied evidence correctly · Addresses the actual decision · Respects explicit constraints · Identifies material uncertainty · Avoids unsupported claims · Produces the required deliverable · and 3 written for each task, which you’ll see in the tasks below.

The tasks

Read the brief, then compare up to three outputs, each with the LLM judge’s verdict on every check. Highlights mark what a PM had to fix.

The brief

You're Director of Product at Kestrel. Elif Demir, our VP Product, wants to fix the PM interview loop before we hire four more PMs next quarter (her note is below). Using the data we have, write her a memo of no more than 1,000 words: which parts of the loop seem to predict how PMs do once hired and which don't, how confident we can be, and the loop you'd run next quarter.\n\nThe files are attached.

What the model was given3 items: elif_note.md, current_loop.md, pm_candidates_last_18_months.csv (every PM candidate who reached the final rounds)
elif_note.md1 lines · Download
From Elif (VP Product): "We've made three PM hires in 18 months who struggled. I want to know what in our loop is and isn't working, using the data we have, and what to change before we hire four more PMs next quarter."
current_loop.md10 lines · Download
# Current PM interview loop

1. Recruiter screen.
2. Take-home: a product strategy deck, one week to complete.
3. Presentation of the take-home to a panel.
4. Behavioural round: "Tell me about a metric you moved", with follow-ups on what you did and what you learned.
5. VP Engineering conversation ("technical credibility").
…
pm_candidates_last_18_months.csv (every PM candidate who reached the final rounds)candidate,background,takehome_score,presentation_score,behavioural_metric_round_score,vp_engineering_score,outcome,rating_after_12_months C100,Big tech,4,4,3,2,Withdrew, C101,Startup,3,2,4,2,Hired,5 C102,Big tech,1,2,3,4,Rejected, C103,Agency,1,3,2,3,Rejected, C104,Big tech,4,3,3,4,Hired,3 C105,Startup,4,2,1,1,Rejected, C106,Startup,4,2,1,3,Rejected, C107,Big tech,4,4,2,4,Hired,2 C108,Consulting,1,4,2,1,Rejected, C109,Agency,4,2,1,2,Rejected, C110,Consulting,3,1,2,2,Rejected, C111,Big tech,2,2,1,4,Rejected, C112,Agency,3,1,2,1,Rejected, C113,Startup,4,2,3,1,Withdrew, C114,Big tech,2,2,3,2,Withdrew, C115,Consulting,3,1,1,1,Rejected, C116,Startup,2,2,1,1,Rejected, C117,Startup,2,1,4,3,Withdrew, C118,Startup,2,2,1,2,Withdrew, C119,Consulting,1,1,3,3,Rejected, C120,Consulting,2,4,1,3,Rejected, C121,Consulting,2,3,4,1,Rejected, C122,Agency,4,1,3,3,Withdrew, C123,Agency,2,4,4,1,Rejected, C124,Big tech,2,2,2,3,Rejected, C125,Startup,2,2,1,3,Rejected, C126,Consulting,4,1,2,2,Rejected, C127,Consulting,1,3,3,1,Rejected, C128,Startup,3,3,2,3,Rejected, C129,Agency,3,3,3,1,Rejected, C130,Startup,1,3,2,2,Rejected, C131,Agency,1,2,4,2,Rejected, C132,Big tech,3,4,2,4,Hired,2 C133,Agency,2,4,2,1,Rejected, C134,Consulting,4,4,3,3,Hired,3 C135,Consulting,3,4,4,3,Rejected, C136,Consulting,2,2,3,2,Rejected, C137,Consulting,3,4,3,1,Withdrew, C138,Startup,2,4,4,2,Withdrew, C139,Startup,3,2,2,3,Rejected, C140,Startup,1,1,3,3,Rejected, C141,Startup,3,3,4,3,Hired,5 C142,Big tech,4,2,3,4,Withdrew, C143,Consulting,1,4,3,2,Rejected, C144,Consulting,1,1,1,2,Rejected, C145,Agency,4,1,2,1,Rejected, C146,Startup,3,1,4,1,Rejected, C147,Big tech,4,1,1,4,Withdrew, C148,Big tech,4,4,2,4,Hired,2 C149,Agency,2,3,4,2,Hired,4 C150,Consulting,4,1,1,2,Rejected, C151,Startup,2,3,3,3,Hired,4
What a strong answer doesThe answer key the graders mark against

Uses the nine hires to compare each round with 12-month ratings: the behavioural 'metric you moved' round lines up strongly with how hires performed (higher scores, better ratings), while the take-home, the presentation and the VP Engineering conversation line up the wrong way: the hires they scored highest are the ones rated 2. The VP Engineering scores big-tech candidates higher, and all four big-tech hires were rated 2 or 3. Is explicit that nine hires is far too few to conclude much: the pattern is a reason to change and then measure, not proof. Proposes a loop with a scorecard defined up front, the behavioural round strengthened (more than one, structured), the week-long take-home replaced or cut down (it costs candidates, and some withdraw), the VP Engineering round given a defined bar and calibrated, and every interviewer writing a score before the debrief. Sets up tracking so the next hires test the change.

Critical failures (cap the score at 40)
  • Recommends keeping the take-home and presentation as the main deciding rounds
Task

Staff-level · v1.0

The outputs

8 setups answered this brief.

Needs more than a quick edit8 of 12 checks passed

The memo lacks a definition of what good looks like for the role and drops the evidence of a candidate's past metric-driven results; a PM would need to rethink how to incorporate independent behavioural evidence and role competencies before acting.

Output

To: Elif Demir, VP Product From: Director of Product Re: What our PM loop predicts, and the loop I'd run next quarter

Bottom line

The behavioural metric round is the only part of the loop that tracks how hires perform. The presentation and VP Engineering rounds seem to drive hiring decisions without predicting performance. All three hires who struggled scored 4 on VP Engineering and 2 on the metric round. I'd make the metric round the centre of the loop and stop weighting the others as heavily. The sample is small, so this is a strong hypothesis to test, not a settled answer.

What the data covers

  • 52 candidates reached the final rounds over 18 months: 9 hired, 33 rejected, 10 withdrew.
  • Only the 9 hires have 12-month ratings. We can't tell whether our rejections were right, so we can't measure false negatives.
  • We don't record withdrawal stage or reason, or which interviewer gave each score, so we can't check consistency across panels.

What the data shows

RoundAvg score: hired vs rejectedCorrelation with 12-month rating (9 hires)Read
Take-home3.2 vs 2.3−0.6Screens out weak work (no candidate who scored 1 was hired), but doesn't predict performance
Presentation3.3 vs 2.2−0.7Drives hiring; higher scores went with lower later ratings
Metric round3.0 vs 2.2+0.9The only round that predicts performance
VP Engineering3.2 vs 2.1−0.8Drives hiring; higher scores went with lower later ratings

Specifics:

  • Metric round: Hires who scored 2 all rated 2 at 12 months (3 of 3). Hires who scored 3 or 4 averaged 4.0. Its average gap between hired and rejected candidates is the smallest of the four, so the panel leaned on the other rounds more.
  • The three struggling hires (rated 2 after 12 months) all scored 4 on VP Engineering and 4 on presentation, and scored 3–4 on the take-home. They looked strong everywhere except the metric round, which was the signal that predicted their problems.
  • VP Engineering: All four hires who scored 4 here were rated 2 or 3 at 12 months.
  • Withdrawals: 8 of the 10 candidates who withdrew scored 3 or higher on the metric round. We are losing strong candidates, and we don't know where or why.
  • Background (hypothesis only): Big-tech hires (4) averaged 2.25 at 12 months; startup hires (3) averaged 4.7. The numbers are far too small to act on, but we should track it.

How confident we should be

  • Metric round as the best predictor: moderate. A correlation of about 0.9 across nine hires is striking, and it fits what PM work involves: diagnosing a metric and deciding what to do about it. But with nine people, one or two different ratings would move the result a lot.
  • Negative readings for presentation and VP Engineering: low. We only see hires, so the range is restricted, and the 1–4 scale gives few distinct values. The defensible claim is that these rounds did not predict success. I wouldn't claim they predict failure.
  • Take-home as a screen-out: low to moderate. Zero hires among ten candidates who scored 1 is consistent with the take-home filtering out weak work, but that's a small group.
  • Anything about rejected candidates: no confidence. We have no data on them.

The loop I'd run next quarter

  1. Recruiter screen: No change.
  2. Take-home: Keep it as a gate. Candidates who score 1 don't advance without a written override. Cap the time we ask for, since we're losing strong candidates and may be losing some to the length of the process.
  3. Metric round (anchor): Rewrite as a structured 60-minute session with two interviewers. Candidates diagnose a real metric movement from a dashboard, propose causes, and say what they'd measure next. Score against a written rubric on 1–4 scales. A score of 3 or higher is required to hire. A score of 2 or lower is a no-hire unless you sign a written override.
  4. Presentation: Fold it into the metric round as a communication check, so candidates spend less time on it, and don't weight it separately in the decision.
  5. VP Engineering conversation: Keep it for a pass/fail check on serious collaboration red flags. Don't score it or count it in the decision, given how it has tracked performance.
  6. Decision process: Every interviewer submits written scores before the panel meets, so no one anchors on the first opinion. The hiring manager still decides, but must write down why if they hire against the metric-round rule or reject someone who met it.
  7. Data: Record the interviewer for every score, withdrawal stage and reason, and 6- and 12-month ratings for every hire. Keep scoring the old rounds next quarter even though they won't be weighted, so we keep building the dataset.

What I need from you

  • Approval for the metric-round rubric and the override rule.
  • Agreement on a review date. Four hires next quarter won't settle this. I'd treat the next two quarters as calibration, with a 6-month review of the four new hires and a full review once we have about twelve hires on the new loop.
  • A decision on whether to pay for a small outside check on our rubric, such as having a PM coach double-score a sample of recordings.

Claims the judge couldn’t find in the brief

  • We don't record withdrawal stage or reason, or which interviewer gave each score, so we can't check consistency across panels

Grades and run details

Decision model 88 · LLM judge 62
Decision model checks
  • passUses the supplied evidence correctly14%
  • passAddresses the actual decision92%
  • passRespects explicit constraints59%
  • passIdentifies material uncertainty98%
  • partialAvoids unsupported claims40%
  • passProduces the required deliverable82%
  • passFinds which rounds line up with performance80%
  • passSays how little nine hires can show100%
  • partialSpots the interviewer pattern80%
  • passJudges on evidence, not presence85%
  • partialDefines good for this role first22%
  • passKeeps each judgement independent100%
Run
Run
#1
API response time
77 s
Submitted
8 Oct 2026

Needs more than a quick edit9 of 12 checks passed

The output misses the VP Engineering big-tech pattern and does not define role competencies, so a PM would need to add those before using it.

Output

To: Elif Demir, VP Product From: Director of Product Subject: PM interview loop: what the data says and what to change next quarter

What seems to predict performance

We have records for 52 final-round candidates, including 8 hires with 12-month ratings. Those hires averaged 3.5, versus a company PM average of 3.4; four were below 3.4, including two rated 2.

Among the eight hires, the clearest signal is the behavioural metric round. Its score has a strong positive association with 12-month ratings (exploratory Pearson r ≈ +0.93). The four hires rated 4–5 averaged 3.75 on this round, versus 2.5 for the four rated 2–3. This is promising evidence for probing how candidates actually move metrics and what they learn—not proof that the round is a reliable predictor.

The other scored rounds show no positive relationship with ratings in this small hired sample:

RoundAssociation with 12-month rating among hires
------:
Take-homer ≈ −0.50
Presentationr ≈ −0.85
Behavioural metricr ≈ +0.93
VP Engineeringr ≈ −0.79

The negative estimates for presentation and VP Engineering should not be read as evidence that those skills hurt PM performance. With only eight hires, these figures are highly unstable. They do tell us that our current scores offer no reassuring evidence that those rounds predict success.

How confident we should be

Low confidence overall; modest confidence that the behavioural round is the best lead to investigate. Eight outcomes are far too few to set reliable weights or cutoffs, and interview scores are ordinal ratings, so the correlations are descriptive only. We also observe performance only for people we hired: panel decisions restrict the range of scores and can distort associations. Non-hires have no performance outcome for comparison.

We lack recruiter-screen scores, interviewer-level data, consistent evidence of scoring reliability, and context about role, manager, or rating differences. The company-average comparison is also a coarse measure. The data can guide a better experiment; it cannot establish causation or validate the loop.

Loop I’d run next quarter

  1. Keep the recruiter screen for eligibility, motivation, and logistics, but don’t treat it as a predictive assessment. We have no screen-score data to evaluate.
  2. Replace the week-long take-home deck and separate presentation with one time-boxed, job-relevant work sample. Use a live or short-prep product problem, not a polished deck. Score problem framing, user evidence, prioritization and tradeoffs, success measures, and communication against anchored criteria. This reduces candidate burden and stops us treating two related presentation exercises as independent evidence.
  3. Keep and strengthen the behavioural round. Ask for a specific metric the candidate owned or influenced; probe the baseline, their actions, evidence of impact, attribution, tradeoffs, and what they learned. Use the same questions and anchored scorecard for every candidate.
  4. Refocus the VP Engineering conversation on PM–engineering collaboration and concrete technical tradeoffs—not general “technical credibility.” Use a structured scenario and score it consistently; don’t make an unstructured impression a veto.
  5. Have interviewers score independently before the panel discussion. The hiring manager can decide after reviewing evidence against the role criteria, with any disagreement recorded. Do not introduce numerical weights based on these eight hires.

For each of the four hires, preserve round-level scores and interviewer notes, then collect comparable 6- and 12-month outcomes with role and manager context. Review the evidence after the cohort has matured. Next quarter’s loop should be a more structured, lower-burden test—not a claim that we have already found a validated predictor.

Grades and run details

Decision model 83 · LLM judge 77
Decision model checks
  • failUses the supplied evidence correctly21%
  • passAddresses the actual decision61%
  • passRespects explicit constraints50%
  • passIdentifies material uncertainty77%
  • passAvoids unsupported claims59%
  • passProduces the required deliverable64%
  • passFinds which rounds line up with performance92%
  • passSays how little nine hires can show99%
  • partialSpots the interviewer pattern86%
  • passJudges on evidence, not presence97%
  • partialDefines good for this role first28%
  • passKeeps each judgement independent97%
Run
Run
#1
API response time
33 s
Submitted
5 Oct 2026

Usable with a quick edit11 of 12 checks passed

The memo is complete, well-reasoned, and directly actionable. A quick edit to add a sentence defining the key competencies would strengthen it, but it is usable as is.

Output

To: Elif Demir, VP Product From: Director of Product Re: What in our PM loop predicts success, and the loop for next quarter's four hires

Bottom line

Of the four loop scores, only the behavioural round ("tell me about a metric you moved") tracks how PMs perform after hire. The take-home, the presentation and the VP Engineering conversation show no positive relationship, and the last two are negative among the people we hired. The sample is very small, so treat this as a strong lead rather than proof. I recommend making the behavioural evidence the anchor of the loop, shrinking the deck work, and turning the VP Eng conversation into a pass/fail check.

What we have

We have 52 final-round candidates: 9 hired, 33 rejected and 10 who withdrew. Only the 9 hires have 12-month ratings (company average 3.4). The three who struggled (C107, C132, C148) each scored 2, and C104 and C134 scored 3, also below average. All five below-average hires are the same kind of candidate: strong on the deck and the presentation, and scored 3–4 by the VP Eng.

What the data shows

Correlation with 12-month rating, among the 9 hires:

SignalCorrelationRead
Behavioural round+0.94Clear relationship
Take-home−0.57No evidence it helps
Presentation−0.87No evidence it helps
VP Eng score−0.82No evidence it helps

The behavioural pattern is clean. Hires scoring 4 averaged 4.7 (ratings 5, 5, 4), hires scoring 3 averaged 3.3, and all three hires scoring 2 were rated 2. Had we required a behavioural score of at least 3, we would have avoided all three struggling hires and kept every hire rated 3 or above. The pattern also holds within background: among the 4 Big tech hires, the one scoring 3 outperformed the three scoring 2, and among the other 5 hires the 4s outperformed the 3s.

The other three signals deserve less trust than the negative numbers suggest, for two reasons:

  • Selection effects. We only see people we hired. If hiring managers pushed through candidates who were strong on the deck and the VP Eng score but weaker elsewhere, those scores will look negatively related to outcomes among hires even if they carry some real signal.
  • The VP Eng score works as a gate. Every candidate scoring 1 was rejected or withdrew, so we have no outcome data on that group and cannot say whether the gate screens out good people.

Two further observations about the process:

  • The take-home and presentation are the same artifact scored twice, so the deck gets double weight in the panel's discussion.
  • Decisions look inconsistent. C135 (3/4/4/3) was rejected while C134 (4/4/3/3) was hired, and five candidates scoring 4 on the behavioural round were rejected. Three of those five had a VP Eng score of 1. With no written decision rule, we can't tell what drove these calls.

How confident we can be

  • High confidence: the three struggling hires share one profile (Big tech, polished deck, VP Eng 4, behavioural 2), and our loop rewarded exactly those traits.
  • Moderate confidence: the behavioural round carries real signal. The relationship is strong and consistent within subgroups, but it rests on 9 people and one outcome measure.
  • Low confidence: any conclusion that the take-home, presentation or VP Eng conversation is useless. Selection effects and range restriction mean the data can't tell us either way. Our evidence only shows they haven't helped.
  • Measurement problems:
  • The 12-month rating comes from one source, likely the manager who chose the hire, so it may be biased toward justifying that choice.
  • Behavioural scores and background are entangled: Big tech hires scored lower (2–3) than the others (3–4). I can't fully separate "behavioural score predicts performance" from "Big tech backgrounds fit us less well," though the within-group pattern favours the former.
  • We have only a single 1–4 behavioural score per candidate, with no record of who scored it or how.
  • Two or three outliers would change several of these numbers.

The loop I'd run next quarter

  1. Recruiter screen. Keep it, with written criteria applied the same way for every candidate.
  2. Two structured past-work interviews, replacing the single behavioural round. Different interviewers run them, each using a written rubric. They probe individual contribution versus team credit, the specific decisions the candidate made, what went wrong and what they would do differently, and how they worked with engineering. Interviewers score independently before any discussion. Two scores per candidate also lets us check whether the scoring is consistent.
  3. Shorter work sample, replacing the one-week deck. Two to three hours, followed by a 30-minute live discussion, producing one combined score on a rubric. This cuts the double-counting and the candidate burden (10 of 52 withdrew). I'm keeping a work sample because we have no evidence it's useless, but it gets no more weight than any other single signal.
  4. VP Eng conversation as a pass/fail risk check. The VP Eng answers one question: "Is there a specific, documented concern about this person's ability to work with engineering?" The 1–4 score no longer counts toward the decision, and a veto needs a written reason.
  5. A written decision rule. A candidate must average at least 3 across the two past-work interviews to be eligible. Among those who clear that bar, the hiring manager decides and records the rationale against the rubric. This is a provisional threshold from 9 data points, so we should revisit it after this round.
  6. Better outcome data. Run a structured 6- and 12-month review with defined criteria and a second reviewer, rather than a single manager rating, and log every candidate's scores in one place. Four hires bring us to 13 data points, still small, so decisions should stay modest in confidence until we have more.

What I'm not recommending

I'm not recommending a background filter (for example, avoiding Big tech candidates). The sample can't support it, and strong Big tech candidates may well do fine under a better-calibrated behavioural round. Interviewers should be told that polished decks and fluent technical conversation have not predicted success here.

I can have the rubrics and interviewer assignments ready within two weeks if you agree with the direction.

Grades and run details

Decision model 92 · LLM judge 92
Decision model checks
  • passUses the supplied evidence correctly36%
  • passAddresses the actual decision95%
  • passRespects explicit constraints62%
  • passIdentifies material uncertainty99%
  • passAvoids unsupported claims29%
  • passProduces the required deliverable91%
  • passFinds which rounds line up with performance99%
  • passSays how little nine hires can show100%
  • passSpots the interviewer pattern77%
  • passJudges on evidence, not presence97%
  • failDefines good for this role first27%
  • passKeeps each judgement independent89%
Run
Run
#1
API response time
67 s
Submitted
6 Oct 2026

Check by check

Where the outputs differ comes first. Open a check to read the judge’s reasons. “Mixed” means the two graders disagreed.

Where they differ 4

Uses the supplied evidence correctlyMixedMixedRight
Haiku 5.5 · API

The claim that we don't record withdrawal stage/reason or interviewer-specific scores is not stated in the supplied context and does not follow from the data; it is presented as fact without support.

GPT-6 Luna · API

All factual claims are taken directly from the CSV or derived by arithmetic, with no invented facts.

Sonnet 5.5 · API

All factual claims about the current situation are directly supported by the supplied CSV, current_loop.md, or elif_note.md, or follow from arithmetic on that data.

Avoids unsupported claimsWrongRightRight
Haiku 5.5 · API

The statement that we don't record withdrawal details or interviewer-level scores is asserted as a current‑state fact but is not supported by the brief or context.

GPT-6 Luna · API

Labels correlations as exploratory, cautions against overinterpretation, and does not present hypotheses as fact.

Sonnet 5.5 · API

Interpretations like selection effects and rating bias are clearly labeled as reasons for caution or measurement problems, not as established facts.

Spots the interviewer patternRightWrongRight
Haiku 5.5 · API

It notes that all four hires who scored 4 on VP Engineering were rated 2 or 3 and that big‑tech hires rated lower, then proposes making that round a pass/fail check and removing its weight, which is calibrating the round.

GPT-6 Luna · API

Does not notice that VP Engineering scores big-tech candidates higher and those hires were rated lower; only reports a negative correlation without the pattern.

Sonnet 5.5 · API

It identifies that VP Eng scores big-tech candidates higher and those hires rated lower, and proposes a pass/fail risk check with written reasons and calibration.

Judges on evidence, not presenceMixedRightRight
Haiku 5.5 · API

The proposed metric round is a scenario‑based exercise, not a probe for concrete evidence of a metric the candidate actually moved, the part they played, or what they learned from failure; the original behavioural round's past‑result evidence is dropped.

GPT-6 Luna · API

Proposes probing specific metrics, evidence of impact, and structured scoring, not impressions or polish.

Sonnet 5.5 · API

The proposed loop probes individual contribution, decisions, failures, and engineering collaboration, and warns against rewarding polished decks and fluent technical talk.

All got wrong 1

Defines good for this role firstWrongWrongWrong
Haiku 5.5 · API

The memo does not set out what good looks like for the PM role (competencies, strong/weak signals) before designing the loop or judging candidates.

GPT-6 Luna · API

Does not define what good looks like for this role (competencies, strong/weak signals) before designing the loop.

Sonnet 5.5 · API

The memo does not explicitly name the competencies that matter most for this PM role and level, nor define what strong and weak look like before designing the interviews.

All got right 7

Addresses the actual decisionRightRightRight
Haiku 5.5 · API

The memo commits early and unambiguously to centering the loop on the metric round, de-weighting other rounds, and testing the change.

GPT-6 Luna · API

Commits to a specific loop for next quarter and frames it as a test, not a proven predictor.

Sonnet 5.5 · API

The memo commits to a clear recommendation (anchor on behavioural evidence, shrink deck, VP Eng pass/fail) and says the threshold should be revisited after the next round.

Respects explicit constraintsRightRightRight
Haiku 5.5 · API

The memo is under 1,000 words, addressed to the VP Product from the Director, and covers the three required parts (predictors, confidence, proposed loop).

GPT-6 Luna · API

Memo format, addressed to Elif, well under 1,000 words, and covers the requested points.

Sonnet 5.5 · API

The output is a memo to Elif, under 1,000 words, and addresses the three requested points (predictive parts, confidence, next loop).

Identifies material uncertaintyRightRightRight
Haiku 5.5 · API

It names small sample size, inability to assess false negatives, and missing data on withdrawals; says a few different ratings could change findings and proposes measurement over time.

GPT-6 Luna · API

Names small sample, range restriction, missing data, and proposes collecting outcomes from the next cohort to resolve.

Sonnet 5.5 · API

It names specific unknowns (small sample, selection effects, range restriction, single-source ratings, entanglement) and says how to resolve them (more data, structured reviews, revisiting thresholds).

Produces the required deliverableRightRightRight
Haiku 5.5 · API

The memo is a complete, actionable 780‑word memo for Elif, covering the requested elements with clear next steps and owner asks.

GPT-6 Luna · API

Complete memo with analysis, confidence, and a concrete loop; a PM could act on it with light edits.

Sonnet 5.5 · API

The memo is complete, in the requested format, for the named reader, within the word limit, and actionable as written.

Finds which rounds line up with performanceRightRightRight
Haiku 5.5 · API

The memo compares each round's scores to 12‑month ratings and correctly identifies the behavioural metric round as the only one that lines up with performance, while take‑home, presentation and VP Engineering run the wrong way.

GPT-6 Luna · API

Works through each round's scores against 12-month ratings, identifying behavioural as positive and the others as negative.

Sonnet 5.5 · API

It compares each round's scores with 12-month ratings, shows behavioural lines up positively and the other three do not, with correlations and subgroup patterns.

Says how little nine hires can showRightRightRight
Haiku 5.5 · API

It explicitly says the sample is small, that the pattern is a hypothesis to test, and proposes a 6‑month review after more hires are assessed.

GPT-6 Luna · API

States plainly that eight hires is far too few, and proposes measuring the next four hires to test the changes.

Sonnet 5.5 · API

It repeatedly states the sample is only 9 hires, calls findings a 'strong lead rather than proof', and proposes to keep measuring with the next hires.

Keeps each judgement independentRightRightRight
Haiku 5.5 · API

It requires written scores submitted before the panel meets, guarding against anchoring and group pressure, and mandates written rationale when overruling the metric‑round rule.

GPT-6 Luna · API

Requires interviewers to score independently before discussion, with disagreement recorded.

Sonnet 5.5 · API

It requires two structured interviews with different interviewers scoring independently on a rubric before any discussion, and a written decision rule with rationale.

Results

Every setup we’ve tested on this task type, across all its tasks and repeats, graded on the current checklist. Calibrated.

#Model · HarnessTask scoreDecision modelLLM judgeRunsCritical failures
1GPT-6.1 SolwithAPI91.7100.02None
2Sonnet 5.5withAPI91.792.32None
3GPT-6 AstrawithChatGPT93.880.82None
4Opus 5.5withClaude87.580.82None
5GPT-6 LunawithAPI89.676.92None
6Haiku 5.5withAPI87.573.12None
7Gemini 3.8 FlashwithAPI75.065.42None
8Gemini 3.5 Flash-LitewithGemini66.753.82None

What you get for the cost

No setup scores within 5 points of the leader at half its cost or less here, so the leader is also the best value.

Task score against relative cost for each setup. The table below has the same figures.50607080901001×3×10×30×Cost per output, relative to the cheapest setup (log scale) →↑ Task scoreGPT-6.1 Sol · API: task score 96, 10.0× the cheapestSonnet 5.5 · API: task score 92, 36× the cheapestGPT-6 Astra · ChatGPT: task score 86, 53× the cheapestOpus 5.5 · Claude: task score 83, 51× the cheapestGPT-6 Luna · API: task score 82, the cheapestHaiku 5.5 · API: task score 79, 1.7× the cheapestGemini 3.8 Flash · API: task score 69, 6.2× the cheapestGemini 3.5 Flash-Lite · Gemini: task score 60, 1.7× the cheapestGPT-6.1 Sol · APISonnet 5.5 · APIGPT-6 Astra · ChatGPTOpus 5.5 · ClaudeGPT-6 Luna · APIHaiku 5.5 · APIGemini 3.8 Flash · APIGemini 3.5 Flash-Lite · Gemini
Nobody beats these on both score and cost
Task score and relative cost by setup
SetupTask scoreRelative cost (cheapest = 1)
GPT-6 Luna · API821.0×
Haiku 5.5 · API791.7×
Gemini 3.5 Flash-Lite · Gemini601.7×
Gemini 3.8 Flash · API696.2×
GPT-6.1 Sol · API9610.0×
Sonnet 5.5 · API9236×
Opus 5.5 · Claude8351×
GPT-6 Astra · ChatGPT8653×

Cost is each output’s tokens at the model’s list price, shown relative to the cheapest setup. Runs done in an app have no usage meter, so theirs are estimated from the same setup’s measured runs. How we compare cost

About the task

The PM job

Hiring product managers.

Why it matters

A bad PM hire costs a team a year. Most loops reward polish and presence, and the debrief goes to whoever speaks first.

What good looks like

  • Defines what good looks like for this role before judging anyone
  • Judges on evidence of results and how they work with a team
  • Tests the real job, not a rehearsed framework
  • Keeps each interviewer's judgement independent

Deliberately not measured

  • Employment law
  • Compensation benchmarking
Capability tested

Hiring judgement

The failure we’re looking for

Hiring for presence and polish over evidence

Grading

Decision model and LLM judge, calibrated against a blind PM review