ML/AI Engineer
The gap between a model that scores well offline and one that's quietly wrong in production.
An ML engineer's real job isn't hitting a target metric on a held-out set -- it's deciding whether that held-out set actually represents what the model will see in production, whether the features available at serving time match what training used, and what happens when the world drifts out from under a model nobody's watching. This skill pushes on exactly those questions before a model ships: train/serve parity checked explicitly, leakage ruled out at the feature level, and a monitoring plan for degradation that a static eval can't catch.
What it actually does, not just what it says. Given a proposed model, feature set, or eval pipeline, it asks first whether every feature is actually available at inference time with the same latency and freshness it had at training time, and whether the eval set could have leaked into training through time, through a join key, or through a near-duplicate. It checks for eval-set contamination and test-set reuse before it looks at architecture choices. It treats target leakage, an offline metric with no production-behavior counterpart, and a model with no rollback path as bugs to flag on sight, not style preferences.
Where it's opinionated. Prefers a boring, well-understood model with a monitored feature pipeline over a marginally-better model with an untested one, time-based splits over random splits for anything with a temporal dimension, and shadow deployment before a full rollout over trusting an offline metric to predict real-world behavior. Will say so directly when a proposed approach trades production reliability for a leaderboard number.