This is a TikTok MLE onsite behavioral round. The interviewer is testing whether you can think, build, measure, and collaborate at scale — and stay composed when challenged. Use concise, metric-focused stories. Below is a framework, four example MLE project walkthroughs (use them as *models* for your own experience, not scripts), and concrete plays for handling pushback, blunt feedback, and a forced language/style switch. ## 1) Per-project framework (60–90 seconds each) Structure each project as **STAR+M** (Situation, Task, Action, Result + Metrics) or **SPADE** (Situation, Problem, Approach, Data/Decisions, Effect), and always speak to: - **Problem & constraints:** one line on the product/business problem; then the strictest constraints (latency, QPS, cost, privacy, safety, fairness, reliability). - **Your ownership:** what *you* designed/decided/owned; use “I” for your actions, “we” for team outcomes. - **Architecture & key decisions:** 2–3 decisions, each with a *why* tied to a constraint. - **Alternatives & trade-offs:** name an alternative and why you rejected it, with numbers. - **Metrics/impact:** directional results plus guardrails; ranges/CIs if you don’t have exact figures. - **Hardest challenge:** root cause, fix, lesson. Ground results with concrete examples: +2.3% watch time, +0.9% CTR, −12 ms p95 latency, −31% policy violations at 0.4% false-positive rate, 99.95% SLA, 0 rollbacks. When you lack exact numbers, give orders of magnitude and explain how you’d measure them (A/B, CUPED variance reduction, sequential testing, confidence intervals). ## 2) Four sample MLE project walkthroughs (shape your real work to these) **Project A — Home-feed ranking (two-stage retrieval + re-ranking).** - *Goal/constraints:* lift feed engagement without exceeding a p95 ranking SLA (~50–80 ms) or hurting creator diversity; >100k QPS. - *Decisions:* two-tower retrieval + ANN index (e.g. ScaNN) to cut candidate generation from ~120 ms to ~15 ms; a listwise (softmax-over-slate) re-ranker for better ordering than pointwise; inverse-propensity weighting to de-bias position effects (weight w = 1/p for exposure probability p); INT8 quantization + dynamic batching to hold latency/cost. - *Alternatives:* XGBoost with engineered crosses (interpretable, but NDCG plateaued and sparse-ID scaling is hard) and Wide & Deep (lightweight, but underfits long-tail interactions). A prototype transformer ranker gave only +0.2% watch-time for +25 ms p95 and +22% compute — not justified under the SLA. - *Impact:* +2.3% watch time (95% CI ~+1.4%–+3.2%), +1.1% session length, +4% creator tail coverage, p95 −12–18 ms, ~−12% serving cost. - *Hardest challenge:* offline–online metric mismatch — fixed by blending NDCG@K with expected watch-time in the offline objective, lifting offline–online correlation r from 0.42 to 0.63 across ~20 historical experiments. **Project B — Real-time toxicity moderation for comments/Live.** - *Goal/constraints:* cut harmful messages ~25% with classifier p95/p99 in the single-digit-to-low-tens of ms, multilingual, false-positive rate ≤ 0.5%, CPU-only at edge PoPs. - *Decisions:* multilingual-BERT teacher distilled to a small student (TinyBERT / ~60M params) with INT8 quantization on ONNX Runtime; per-language/region temperature scaling and operating points to cap FPR; high-precision lexicon/regex fallback as a guardrail; weekly hard-negative mining and character-level augmentation for adversarial slang. - *Alternatives:* TF-IDF + logistic regression (<2 ms but poor recall on paraphrases/codewords); full mBERT in prod (best F1 but ~35–40 ms p95 on CPU — violates SLA at peak). - *Impact:* abusive-content incidence −28–31% at ~0.4% FP; p95 ~18 ms / p99 ~8–30 ms; ~99.95% SLA; precision on new slang cohorts 0.71 → 0.88; no rise in successful appeals. - *Hardest challenge:* evasive slang — closed the loop with user reports + moderator-confirmed hard negatives and adversarial augmentation. **Project C — Ads CTR calibration and revenue uplift.** - *Goal/constraints:* improve revenue and advertiser trust via better CTR calibration and pacing, keeping CPM volatility within ±5% and protecting small-budget advertisers (fairness). - *Decisions:* isotonic regression over Platt scaling for monotonicity, with cross-fitting to avoid leakage; class-weighted log-loss (L = −[y log p + (1−y) log(1−p)]) for rare positives; unified event schema + replay validation to kill logging skew. - *Impact:* +3.2% RPM, Expected Calibration Error −40%, overspend incidents −18%; ECE stable across traffic splits after the schema fix. - *Hardest challenge:* logging skew breaking online calibration — root-caused to event-schema drift; fixed with a single schema + replay checks. **Project D — Feature store to eliminate training–serving skew.** - *Goal/constraints:* point-in-time-correct training data, online fetch p99 < 10 ms, large backfills (100s of TB), privacy/retention compliance, high availability. - *Decisions:* a single feature definition (DSL/SQL+UDFs) compiled to both offline (Spark/Parquet, time-partitioned) and online (Flink + Redis) stores; as-of / point-in-time joins with event-time semantics to prevent look-ahead leakage (feature_time ≤ label_time − ε); data contracts, lineage, TTLs; staleness SLOs and drift dashboards. - *Alternatives:* per-team bespoke pipelines (fast at first, but cause skew bugs and duplicated work) and a managed vendor (faster to boot, but data-residency and custom-UDF limits, higher per-GB cost). - *Impact:* ~70% adoption across ~6 teams in two quarters; skew defects −60–80%; new-model time-to-prod from ~8 weeks to ~3; −25% feature-compute cost via reuse; online fetch p99 ~6 ms. - *Hardest challenge:* cross-org adoption — phased rollout, reference implementations, and SLO dashboards turned a skeptical senior reviewer into a sponsor. A/B sizing aside you can cite: for a proportion metric, per-arm n ≈ 16·p(1−p)/MDE². With baseline CTR p=0.05 and MDE=0.002 (0.2 pp), n ≈ 16·0.0475/0.000004 ≈ 190,000 users per arm. ## 3) “We wouldn’t do it that way” / “this performs poorly” — defend or revise Stay calm and data-first: 1. **Clarify objective and the strictest constraint:** “What’s the primary goal — latency, safety, or cost?” 2. **Separate invariants from negotiables:** “p95 ≤ 50 ms and the fairness floor are hard; the model class is flexible.” 3. **Compare options with numbers:** “ANN + re-rank gives recall@200 ≈ 0.92 at +15 ms; exact search gives recall 1.0 at +60 ms. Our budget leaves ~10–15 ms for re-ranking, so ANN fits.” 4. **Offer a hybrid or pivot:** “We could use exact search offline to curate candidates and ANN online, or fall back to exact only for cold-start users.” 5. **Decide and commit:** “Given today’s constraints I’d ship A; if the latency budget grows or recall becomes the bottleneck, I’d revisit B.” 6. **Invite critique:** “Which constraint am I misjudging?” ML-specific mini-example: if challenged on a listwise loss — “Listwise lifted offline NDCG ~1.4 and correlated better with online watch-time (r 0.42 → 0.63). If label quality or training cost makes it unstable, I’d switch to pairwise hinge loss, L = max(0, 1 − s_pos + s_neg), and recover most of the gain more robustly.” Pitfalls to avoid: over-defending past choices as universally right; ignoring unspoken constraints (privacy, abuse risk); hand-waving metrics. Always close with what you’d change in hindsight. ## 4) Blunt or dismissive feedback — in the moment and after *In the moment:* stay composed and extract the signal — “Which part won’t scale: storage, joins, or QPS? At what threshold does it fail?” Then propose a concrete test — “If we load-test at 2× peak (200k RPS) and hold a 95% cache hit rate, does that address it?” Time-box it — “Let’s do a back-of-envelope now; I’ll follow up with a micro-benchmark.” *Afterward:* add the missing proof (capacity plan, SLOs, the measurement you lacked); bake the critique into your design checklist (performance budget, privacy impact, rollback plan); close the loop with the reviewer and show a number. Adaptable story: in a feature-store design review a senior engineer said bluntly “this won’t scale past 2× traffic.” I asked for the bottleneck (point-in-time joins), ran a quick calc (at ~1B events/day a single shard risked saturation at 200k RPS reads), then sharded by user_id with consistent hashing, added Bloom filters and a tiered cache, and load-tested at 2.5× peak (250k RPS) hitting p95 read ~18 ms. The reviewer became a supporter, and I now include a capacity/SLO appendix in every design doc. ## 5) Adapting to a different language or style When an interviewer insists on a specific language or framing: - **Confirm the constraint:** “Java without external libraries? Functional or OO?” - **Bridge with pseudocode first** to confirm the logic, then implement. - **Use core primitives** (arrays, hash maps) and state time/space clearly — e.g. “iterative BFS to avoid recursion depth; memory O(V+E).” - **Narrate trade-offs in their terms** — if they want systems over math, move from loss functions to SLAs, back-pressure, failure domains, and rollback plans. - **Test aloud** with small cases and edge cases (empty input, large N, unicode, streaming). Example: switching Python → C++ — “I’ll implement a minimal vector search with std::vector and std::priority_queue, no external libs, and here are the cases I’ll run.” ## 6) Checklist to keep answers tight and credible - Always give numbers: effect size, ranges/CIs, or at least orders of magnitude. - State constraints explicitly: latency, cost, privacy, fairness, safety. - For experiments: define success **and** guardrail metrics; do a power analysis; avoid peeking / sequential p-hacking. - Mention safety/fairness (abuse risk, regional differences) when relevant. - “I” for your actions, “we” for team outcomes. - Close each project with a learning sentence: “We chose X over Y for A/B reasons; it delivered Z with guardrails intact. The hardest issue was H; we solved it by S, and next time I’d also try T.”

This is a structured behavioral round, not a coding problem, so it is graded on signal density and composure rather than a single right answer. Strong candidates: (1) walk each project as problem → ownership → architecture/decisions → alternatives & trade-offs → measurable impact → hardest challenge, in ~60–90 seconds; (2) defend trade-offs with data and clearly separate hard constraints from negotiables, offering a hybrid or principled pivot rather than digging in; (3) respond to blunt feedback by extracting the concrete bottleneck, proposing a test, and showing a follow-up fix with a metric; and (4) adapt to a forced language/style switch by confirming constraints, bridging via pseudocode, and narrating trade-offs in the interviewer’s terms. The MLE project examples (feed ranking, toxicity moderation, ads CTR calibration, feature store) are models to map your own experience onto, not facts to memorize.