The technical screen, pre-answered.

01

“How do you know the model is right?”

I don't — and I won't pretend to. Whether the model is right is the ML team's work and their measurement to defend; the eval is their proof, not mine. What I own starts where the eval ends. Week one, I'm reading eval results before I open a design file, because the interface inherits every property the eval measures — and a few it doesn't. Then I design what gets measured into the surface itself: abstentions the user can see, overrides that get logged, a track record that accumulates in the open. One rule holds throughout: the screen never claims more certainty than the eval supports. The fastest way to lose an ML team is to design a surface their eval can't back.

Receipt → how I lead: eval design before interface design

02

“Your model reports 87% confidence. What does the user see?”

Never the 87. An unexplained 87% is a shrug with decimals — it reports the model's mood and hands the user all of the work. So the score resolves to a verb before it reaches the screen: act, review, or ignore. Every review carries the handful of signals that drove it, in language a person can test against their own judgment; every act carries an override. Where the bands sit is a product decision someone owns and revisits against real outcomes — the same 87 can mean act on a media plan and review on a deal memo, because the stakes set the verb, not the number. A naked number ends in a shrug. A score tied to a verb ends in an action.

Receipt → the Act / Review / Ignore rule

03

“Walk me through an abstention decision.”

On the PE screening tool, the state I fought hardest for was the model saying “I'm not sure about this one.” It shipped in the first release — I held the launch until it existed, alongside a cited source behind every number and a logged override. The threshold was a design argument as much as a statistical one. Pitch it too eager and the tool cries uncertainty on claims it could defend, and analysts learn to skim past the abstentions; too shy, and one fluent, wrong claim undoes the trust the tool has earned. The threshold has to fail toward humility — the cheaper mistake. And the effect ran the direction you'd hope: once analysts had watched the model decline to bluff, its confident answers started carrying weight. They went from ignoring the score to leading their deal memos with it.

Receipt → the FinTech case: 60% faster screening, abstention over hallucination

04

“Do you actually speak our language?”

Enough to argue in it. Retrieval grounding and provenance — every generated claim traces to a source the reader can open, or it doesn't ship. Per-claim confidence versus offline evals — different signals with different jobs: one belongs on the screen beside the claim, the other decides whether the screen is allowed to exist. Calibration and track record — does “80% sure” actually mean right 80% of the time, and does the history accumulate in the open instead of quietly resetting on retrain. Abstention thresholds — where the model stops answering, owned as a product decision, not left to a default. Overrides as training signal — the user's disagreement, logged, feeding the next cycle instead of vanishing into a support ticket. Capability boundaries — the honest “no,” stated in the interface before the first failure, not after the first complaint.

05

“What about latency and cost?”

They're design inputs, and I ask about both in week one. What's precomputed and what's generated on demand — because an explanation drawer is a latency budget decision, and a drawer that takes four seconds to open teaches people to stop opening it. When retrieval costs real money per call, the evidence may have to load behind the number instead of beside it — that's a trust tradeoff, and it should be made on purpose rather than discovered in the invoice. And the loading state is a promise: what the interface says while the model thinks sets what the person expects when it answers. I won't hand you case numbers here, because I don't have honest ones — these are the questions I bring, and the answers are always specific to your stack. That's part of what the first week is for.

06

“What did you own, versus the team?”

I keep this boundary sharp, because blurring it insults the people who did the work. The model's accuracy, its lift, its benchmarks — that's the ML and data science team's work and their measurement to defend. Mine is the layer where a right answer becomes an acted-on one: the evidence beside the number, the abstention state, the override that gets logged instead of lost, the score that resolves to a decision. I write it the same way about my O2 work — “the launch-era figures are O2's; the screens I owned are mine.” A candidate who claims the model's numbers as their own is telling you something. A candidate who can't say exactly which pixels were theirs is telling you more.

Receipt → the O2 case, scoped honestly

07

“Tell me about a time you were wrong.”

I fought hard for a recommendation card with three ranked options — give people choice, I argued. Engineering wanted one option, the top pick, nothing else. They won the meeting, and the next quarter's A/B test made it permanent: the single-option card converted 2.3× better, because three choices froze people at the exact moment we needed them to move. Every recommendation surface I've designed since starts from that loss. There's a second scar. I used to treat a human-in-the-loop checkpoint as a safety net by itself — it isn't, because people click through without reading. Now, on anything high-stakes, a confirmation sits between the click and the consequence.

Receipt → the Human-in-Loop pattern, scar included

08

“Can you ship code, or just Figma?”

The receipt is the page you're reading. This site is hand-built HTML, CSS, and JavaScript — view source, or read the repository. In production I ship the front-end of the features I design — buttons, forms, data displays, AI surfaces — in the PR, under my name, with senior engineers reviewing. React for prototypes and component scaffolds. I won't claim the backend or complex state architecture; that's someone else's craft, and I'd rather be reviewed by them than pretend at it. A designer who codes doesn't need the handoff meeting — the handoff is the pull request.

Receipt → the code behind this site ↗

09

“Why should we trust a designer with this at all?”

Because the failure mode you're hiring against isn't a wrong model — it's a right model nobody bets on. Your model is right; your users still won't act on it, and that half-second of doubt is the only thing I design. The trust layer — the exact pixels where a person decides the model deserves their click — is a design problem, and it's the whole job I'm asking you to hire me for. But don't take a page's word for it; take the standing offer from my FAQ. A 30-minute intro, then a paid 1-week trial on a real (not contrived) problem, then a 1-hour debrief, then a decision. The trial is mutual — I'm evaluating you too.