Use Eugene Yan and Jason Liu's hiring account to connect your projects to coding, data and evaluation questions. Confirm the actual stages, time limits and allowed tools with the recruiter. Practise coding on your own, and explaining assistant-written code where the employer allows it.
Have three stories ready and practise them out loud, at ninety seconds each:
- A time your numbers were wrong and you found out. The Chapter 3 leakage exercise is built for this.
- A time you chose the simpler option deliberately, with the numbers behind it.
- A time you shipped something someone else used.
Story structures, not results to borrow. Swap each scenario for work you actually did and numbers you can defend. Keep the task, mistake or tradeoff, evidence, change and outcome.
- Wrong numbers. "My delivery model used a final-status field that only arrived after the decision. I removed it, rebuilt decision-time features, and evaluated on a later period with mature labels. Here are the original and corrected scores, sample sizes and release test."
- Simpler on purpose. "I compared retrieval with fine-tuning on the same held-out questions. The paired comparison did not show a meaningful improvement at a cost we could support. I chose retrieval and documented the remaining errors and the evidence that would change my mind."
- Someone else used it. "A team used my triage tool for a defined pilot. I recorded eligible cases, usage and failures. I fixed one failure class and tested the change on a separate release set. Here is the measured scope of the pilot and the reproducible evaluation."
A result on 50 examples is a useful first signal, not a precise population guarantee. One extra pass moves the rate by two percentage points. Show paired disagreement counts or a suitable interval. Keep pilot adoption separate from evidence that your change caused a business improvement.