Day-Of Tactics

The morning of

• Reread the JD once. For fraud-domain Staff roles, underline "deep domain understanding," "production code," "end-to-end ownership." For multimodal-AI Solutions-Engineering roles, underline "high-ambiguity," "iterative preprocessing," "prompt engineering."
• Reread your résumé. Refresh dates and team sizes.
• Reread 01-the-roles. Have the framing fresh.
• Pull up 15-interview-questions. Skim Section A (background framing).
• Have ~50 lines of representative production code on hand — a module, a feature transformation, a test. You'll likely be asked.
• Walk 15 minutes before the first session. Don't cram.
• Water, scratch paper, pen. Close every unrelated tab.

Structural moves

1. Restate the problem before answering

"Let me make sure I understand. You're asking…" Buys you 20 seconds and confirms the question.

2. State approach before doing the work

"I'd think about this in three steps — first X, then Y, then Z." Lets the interviewer redirect early.

3. Lead with domain questions on modeling prompts

Staff-DS-specific signal: when handed a modeling prompt, your first three questions should be about the domain, not the algorithm. "What does fraud actually look like in this data? Who labels it, and how fresh are labels? What's the cost asymmetry between FP and FN?" That's the senior move.

4. Commit to a recommendation

"My answer would be X. The case I'd revisit it: [specific condition]." Better than "it depends" with five options.

5. Talk through tradeoffs explicitly

"I could use a hash map at O(n) time / O(n) space, or sort at O(n log n) / O(1). I'd pick the hash map because n is large here." The reasoning is what's being scored.

6. Narrate when stuck

Silence is the enemy. Saying "I'm thinking about whether this is a leakage issue or a label-noise issue…" is itself a signal of systematic thinking.

Traps to watch

The "what would you do at scale" trap

Always be ready for it. "What I just described handles 1M rows. At 1B rows, I'd switch to [feature store / pre-aggregated SQL / batch over partitions]." Even if you're uncertain on the exact answer, name the dimension you'd worry about.

The "implement SMOTE" trap

If the imbalance question is "what would you do," reach for class weights and threshold tuning before SMOTE. SMOTE as a knee-jerk answer reads junior. Mention it as a fallback if the simpler approaches don't clear the bar.

The "just use AUC" trap

For staff-level fraud loops, AUC alone is insufficient. Always pair with PR-curve, lift at K%, and a calibration check. Naming all three is a small differentiator.

The "show me your code" round

For Staff-DS rounds especially. Be ready to walk through a ~50-line module. Discuss: types, small functions, error handling, the test you wrote alongside it.

The "you don't have fraud experience" pushback

Concede directly, pivot to adjacent. "I haven't worked in fraud. I have worked on [similar-shape problem] where the core was [similar pattern]. My plan would be to spend the first month shadowing the investigations team to build domain instinct."

Recovery patterns

You said something wrong

Correct immediately. "Actually, what I just said about X is wrong — the correct framing is Y. Let me redo that piece." Self-correction is a positive signal.

You're stuck on coding

State what you've tried, name the constraint, ask for a hint after 5 minutes silent. Verbalized stuck-ness is much better than silent stuck-ness.

You don't know an answer

Three-part response: name the gap precisely, name the adjacent thing you know, name how you'd find the real answer. Works much better than guessing.

The interviewer disagrees

Don't fold instantly. Ask one clarifying question. If you still disagree, defend politely; if their framing is better, update visibly. Both moves score.

Questions to ask them

Universal

• "What does failure in this role look like at 90 days? At a year?"
• "What's the modeling decision the team has gotten wrong most recently?"
• "What's the trajectory from this role to the next?"

For fraud-domain-flavored loops

• "How does the DS team partition work across Emerging Products, Application Fraud, and Identity?"
• "Where does the DS team feel under-resourced right now?"
• "How does DS work with engineering on real-time inference performance?"
• "What's a recent feature that moved a model meaningfully, and where did the idea come from?"

For Solutions-Engineering-flavored loops

• "Walk me through a recent POC end-to-end — input, iterations, output."
• "Where does the boundary sit between platform engineering and this role's work?"
• "Typical cycle time from customer asset to testable result?"
• "How do you handle a POC that's looking infeasible — kill or escalate?"

Closing statement

When prompted for final questions or "anything else?", have a 30-second close ready. Three beats:

1. One specific thing that confirmed your interest.
2. One specific thing you'd bring (not a résumé recap — a concrete commitment).
3. A clear ask: "What are the next steps and the timeline?"

After the loop

• Thank-you email within 24h. One paragraph. Reference something specific from one round.
• Self-debrief: which rounds were strong, which were rocky. Specific weaknesses feed the next study cycle.
• Don't pester the recruiter. Loops typically resolve in 3–7 business days.
• If "no": ask for substantive feedback. Most won't give much; the framing of the rejection sometimes tells you which round.
• If "yes": negotiate. Always. Even mid-level roles have room. Staff roles have substantial room.