Final Loop

S — Real-time CV models (detection + segmentation) for live soccer — virtual ad replacement that ran during UEFA Euro 2024 and the Champions League. Model validation had become the deployment bottleneck.

T — I took on finding out exactly why — ship cadence depended on it.

A — Profiled the pipeline end to end instead of guessing; identified the key bottlenecks — [name the top one or two precisely] — fixed them [what you changed], measured before/after on identical workloads.

R — 5× faster validation → materially faster deployment cycles. [Ship cadence before vs. after if you have it.]

Probes: how did you profile · biggest single win · how did you prove results didn't change · what would the next 5× take

Bank questions this answers: Invent & Simplify #1 (complex problem, simple solution) · #3 (made something simpler for customers — the team) · #6 (novel decision, big impact) · Think Big #1 (saw a chance to do something bigger than the initial focus).

S — Production assistant app for marketplace sellers; the LLM market shifted monthly under it.

T — I led the integration layer. Goal: model choice = config, not an engineering project.

A — One interface over OpenAI/Google/Anthropic — normalized streaming, tool calls, errors; per-task routing with fallbacks; eval harness before any swap.

R — Swaps in hours; cost routed to cheapest capable model [real % or $ if you have it]; team shipped features provider-blind.

This is your presentation (Deck tab). Whoever hosts the presentation gets it there — don't also spend it as an LP answer in another session unless asked directly. As an LP story:

S — Two weeks before UEFA Euro 2024, a new billboard ad appeared featuring a fake soccer ball. Our production detection model fired on it. In a live virtual-ad-replacement pipeline a false ball detection is a visible artifact on air, to millions, with no retake.

T — Kill the false positives before kickoff without degrading anything else. I was tasked with building the fix.

A — We weighed retraining with the new ad in the data: too slow for two weeks, and no guarantee performance stayed consistent everywhere else. Chose a regional, class-aware threshold controller instead: raise the ball threshold only in the parts of the frame where that ad shows, only when it shows. Reversible, contained, testable. Then: talked to the operators first, the people running the broadcast system at the stadium, learned their controls (an MPC-style pad surface) and their reality: about 2 minutes of lead time before an ad rotates in, so tuning had to be live and manual. Changed the model's output layer from one merged detection class to per-class output. Added a controller layer at the input of the broadcast system: thresholds by class and by stadium region. Operators pre-define regions about 1 hour before the match from a priori knowledge of where problem ads appear, then raise the threshold live when the ad rotates in.

R — Zero false positives across every Euro match. Performance everywhere else stayed at expectation. Shipped inside the two-week window.

Retro — [Your line. Candidates: expose per-class output from day one; automate region proposals from the ad schedule; feed operator tunings back as training signal for the next retrain.]

Bank questions this answers: Bias for Action #1 (calculated risk, speed critical) · #2 (tight deadline, couldn't consider all options) · #5 (move forward vs gather more info) · Deliver Results #1 (tight deadline, what sacrifices) · #2 (unanticipated obstacle) · Invent & Simplify #1 (complex problem, simple solution) · #5 (usual approach wouldn't address) · Customer Obsession #3 / #5 (operators' real workflow).

Probes: why not just raise the threshold globally · how did you validate the controller before air · what if an operator missed the 2-min window · what did retraining actually cost in days

The shape that scores: respectful challenge + data + the decision went somewhere + you committed genuinely. The commit half matters as much as the backbone half — spend a third of the answer there.

Your candidate — a technical/architecture disagreement at mtl.ai: [which decision? what did you argue, with what data? which way did it go — and what did committing look like in your actual behavior?]

If it resolved in your favor, also have the version where it didn't (story 13 can be that one). Voice prompt #2 builds this with you.

The signal Amazon wants: you changed course because of what users actually needed, at some cost to your own plan.

Your candidate — building the assistant app for online marketplace sellers: [a moment seller feedback/behavior contradicted what you'd built or planned — what did you learn, what did you change, what did it cost you, how did sellers respond?]

Say the realization moment out loud ("we'd built X; watching sellers we realized Y"). That sentence IS the story.

Asked in nearly every loop — with five interviewers, possibly twice (have a second, thinner one ready). Scored on honesty and changed behavior, not the failure.

• Pick something real — a late project, a wrong technical bet, a model that underperformed in production. "I work too hard" is an anti-signal.
• Structure: what happened → my share, no blame-shifting → concrete lesson → what I do differently now, with an example of the new behavior working.
• 60 seconds. No wallowing, no spin.

S — Estimai generates construction bids from architectural plans. Finding structural elements — column icons — across multi-page plan sets was manual and error-prone.

T — Nobody owned it. I proposed a PoC and delivered it single-handedly.

A — The bet: don't rasterize and throw a vision model at pixels — the PDF already contains vector primitives. I extracted them and built detection + cross-page association directly on vector data: simpler, cheaper, more precise. Reversible if wrong — that's why I could move fast.

R — Working PoC [timeframe]; [what happened next — adopted? shaped direction?].

Probes: what did the vector bet trade away · accuracy measurement + failure modes · path to production

Your second Customer Obsession story — keep one per AE session (this one for George/Biever, #5 for Grimes, or however the day flows).

S — Construction estimators build bids under deadline from hundreds of plan pages. We were building AI document analysis for them.

A — [How did you get inside their actual workflow — watched them work? sat with a real estimator? what surprised you (what they actually count, what they ignore, where errors hurt)? what did you build differently because of it?]

R — [The feature/decision that came out of the field truth, and how estimators responded.]

For Biever especially: this is her life — a mission org's under-resourced staff and the tech people who do or don't understand them.

S — Jan 2026: I joined Explorai as an AI full-stack engineer — after years as an ML/R&D specialist. New stack, new codebase, a shipping SaaS product with real customers.

T — Contribute across the whole stack, fast — not just the ML corner I knew.

A — [How you ramped: what was new (frontend? infra? their framework choices)? your system for learning it — reading the codebase, pairing, shipping small first?]

R — Contributed across the full stack to a live product within 4 months, plus the solo PoC (#7) on top.

S — Seven years teaching calculus, linear algebra, stats, probability to thousands of students. [The driving problem: where were students failing with the existing materials?]

T/A — Rebuilt the materials around how students actually got stuck — [what you changed structurally, and how you knew it worked].

R — Adopted department-wide; outlived my tenure. [Pass rates / feedback if you have them.]

S — Executive council member, Teachers' Union + Science Program Committee — representing colleagues to the administration.

A — [One concrete position you argued against the administration or department: what was at stake, how you made the case, how it resolved — and if it went against you, how you carried the decision anyway.]

Second Backbone story (after #4) — five interviewers means the big LPs get asked more than once.

S — Since April 2026: grant-funded (Coefficient Giving) independent research on emergent misalignment in LLMs — with two co-authors, no institution behind us.

T — Produce publishable, rigorous results on a moving research frontier.

A — Co-authored "Innocuous-Seeming Data, Latent Ideology: Ideological Generalisation in Finetuned LLMs" — [your specific contribution: the experiments? the finetuning infra? the analysis? — say what YOUR hands did].

R — Accepted to two ICML 2026 workshops (AI4GOOD, Pluralistic Alignment); under review at NeurIPS 2026.

For Tapia/Bland: this is also a genAI-credibility story — you finetune and evaluate models yourself; "evals not vibes" is literally your day job.

S — Research with co-authors means methodology fights with people you respect and no boss to settle them.

A — [A real disagreement with Rob/co-authors — experimental design, analysis choice, framing: what you argued, what the data eventually said, and how you committed if it went the other way.]

Ideal if this is the one that went against you — pairs with #4 where you may have prevailed. Committing gracefully to a peer's call is a stronger signal than winning.

S — A published AI paper ("The Hot Mess of AI") built its argument on an incoherence metric I believed was flawed.

A — Rather than just disagreeing, I dug into the metric's construction and wrote a public critique — [the core flaw in one sentence a non-specialist gets; what your analysis showed; what you'd measure instead].

R — [Status: published where? any response?]

For George: this is his "going beyond vibes" blog post in story form — evaluating AI claims with rigor instead of accepting them.

S — Zero AWS experience when this process started in July. Passed the SA assessment in about a week by building my own study tooling.

A — Then I made it real: I run a production personal-assistant app (LLM agents, messaging channels, scheduling — one live user) on a bare VPS, and I'm migrating it to AWS right now, as infrastructure-as-code. Phase 0 shipped this week: CDK in Python — billing guardrails and cost alarms before the first dollar, CloudTrail, GitHub OIDC so CI gets roles instead of long-lived keys.

R — A real, phased strangler-fig migration plan — model supply to Bedrock, compute, storage, per-seam cutovers with rollbacks — written and being executed. Cost visibility landed before the first workload, which I've since learned is exactly the Well-Architected order.