Morning starts with a review of overnight training runs — loss curves, eval metrics, and GPU utilization in Weights & Biases or MLflow — plus any on-call pages from the serving fleet: inference latency alarms, drift alerts, data-pipeline failures. Standup flags blockers across the two main work streams most mid-level ML engineers juggle: training-infra work (for example, a LoRA fine-tune for a product feature running on Ray/Kubernetes) and serving-infra work (rolling out a Triton deployment with INT8 quantization behind a canary). Afternoons fragment. A typical day mixes pairing with a data scientist on eval methodology for a new ranking model, reviewing a PR to the Feast feature store, writing a design doc for a RAG pipeline upgrade (swap vector DB, add rerank stage), and debugging training-serving skew surfaced when offline AUC looked great but online CTR came in flat. Weekly cadence adds model review, architecture review with senior MLEs, and a stakeholder readout tying ML metrics to business KPIs. Staff+ MLEs write less code and resolve more ambiguity — setting platform direction, evaluating build-vs-buy for ML tooling, and advising leadership on model-risk tradeoffs.

Model-centric, not data-centric

Andrew Ng's publicly argued reframing: "Companies should focus on developing systematic engineering practices for improving data in ways that are reliable, efficient, and systematic — move from a model-centric approach to a data-centric approach." Production ML engineers spend 60–80% of their time on data. Resume anti-pattern: endless "improved accuracy by X%" bullets with no mention of dataset construction, labeling quality control, or data-quality systems. Resume signal: make the data work visible — labeling pipelines, feature store design, data-validation jobs, drift detection.

Ignoring serving latency and tail latency

A model scoring 99% accuracy that takes 5 seconds under load is a failed system. Named across MLOps production post-mortems: p95 looks fine while p99 (the tail) cascades across downstream services. Resume signal: explicit latency numbers (p50/p95/p99), throughput (QPS), and the optimization lever used — dynamic batching, INT8/FP16 quantization, distillation, caching, or moving to Triton/vLLM. Hiring managers read this as production maturity.

Training-serving skew / offline-online gap

The silent #1 production ML failure: separate code paths (or subtle distribution differences) between training and serving features, so the model ships with validated offline AUC and then underperforms in production. Resume signal: mention of a feature store with parity testing, shadow/canary deploys, or explicit training-serving parity validation shows you've operated a production ML system — not just tuned notebooks.

ML metrics without business metrics

Chip Huyen: "Most businesses don't care about ML metrics unless they can move business metrics. If an ML system is built for a business, it must be motivated by business objectives." Resume anti-pattern: "AUC 0.87 on test set" standalone. Hireable version: "AUC 0.87 on test set — translated to +12% retention in A/B test, $3.4M monthly revenue lift." Every ML bullet should link both sides of the ledger: an ML metric and the business metric it moved.

1Model accuracy without business context

Writing '95% accuracy on test set' in isolation tells a hiring manager nothing. What did that accuracy unlock — revenue, retention, manual hours saved, calls deflected? Per Chip Huyen, businesses don't care about ML metrics unless they move business metrics. Every ML bullet should include both sides of the ledger.

2No production deployment experience

Resumes that read like a series of Jupyter notebook experiments signal 'can train, cannot ship.' Include specifics on serving infrastructure (Triton, TorchServe, Ray Serve, SageMaker endpoints), latency SLOs (p50/p95/p99), throughput (QPS), scaling strategy, and on-call ownership. Deployment is the step most hiring managers are actually screening for.

3Algorithm list instead of applied choices

Enumerating 'Linear Regression, Logistic, RF, SVM, XGBoost, CNN, RNN, LSTM, Transformer, GAN, VAE…' reads like a textbook TOC. Hiring managers want to see what you chose in which situation and why. Tie each algorithm to the problem it solved in production and the tradeoff you made.

4Ignoring data and feature-engineering work

Production MLEs spend 60–80% of their time on data. Resumes that barely mention pipelines, labeling QA, feature stores, or data-quality systems look suspiciously model-centric. Andrew Ng's data-centric framing argues this is where most of the leverage actually lives.

5Missing MLOps / infrastructure signal

In 2026, ML engineering is as much infrastructure as algorithms. A resume with no mention of experiment tracking (MLflow/W&B), model registries, CI/CD for ML, feature stores, drift monitoring, or automated retraining reads as a data scientist with a different title. If the JD says MLOps and your resume doesn't, ATS will filter you.

6Confusing research experience with engineering experience

Papers and research projects are valuable but should be framed differently than production work. 'Implemented a novel attention mechanism' is research; 'deployed a transformer serving 1M daily predictions at p99 30ms' is engineering. Label each clearly so hiring managers can assess the specific kind of experience they're hiring for.