PurPassionDigital / Everywhere
Data Science / Analytics · Digital / Everywhere

ML Engineer

Unexpected
Resolution · Broken FunctionalThe pull to make things work
Pace
  • A hard push you keep up for a long stretch
  • A steady rhythm with room to breathe
What your week looks likeQuiet stretches, then deadline storms
How much you move around at workScreen and chair, almost all day
Whether you can work from anywhereWork from anywhere with a signal or internet connection
How quickly you receive feedback on your workGive it a few days
What you're actually working withNumbers, measurements, records — things you read on a screen / Concepts, theories, designs, stories — things you think up

Core
  • Constructing from parts into a functional whole. Structural, assembled.
  • Applying systematic problem-solving to make things work reliably.
  • Taking something that works and making it work better.
  • Iterative diagnosis under uncertainty.
Also present
  • Making processes run without constant human input.
  • Improving through rapid cycles — testing, learning, revising until it works.
  • Watching for danger, maintaining vigilance.
  • Verifying whether something is true or works as claimed.

The ML engineer is the person who takes a model that works in a notebook and makes it work in the real world. A data scientist builds a recommendation model that performs well on historical data. The ML engineer's job is to deploy that model into a production system where it serves predictions to millions of users, monitor its performance over time, retrain it when the data changes, and build the infrastructure that makes all of this happen automatically and reliably. The primary pull is Resolution — taking something that is fragile, manual, and researcher-grade and making it robust, automated, and production-grade.

The distinction between data scientist and ML engineer is one of the most important and least understood boundaries in the field. The data scientist asks: can we build a model that does this? The ML engineer asks: can we make this model work at scale, reliably, continuously, without a researcher babysitting it? These are different skills, different temperaments, and different daily textures. The ML engineer's world is closer to software engineering than to research — version control, testing, deployment pipelines, monitoring, alerting, and the particular challenge of systems whose behaviour is non-deterministic because the model's outputs depend on its inputs in ways that are not fully specified.

The work has a characteristic satisfaction and a characteristic frustration. The satisfaction: building a system that serves a million predictions a day without anyone noticing. The frustration: the gap between what research papers describe and what actually works in production, reliably, at scale. A significant share of ML engineering work is unglamorous infrastructure — data pipelines, feature stores, model registries, monitoring dashboards — that has nothing to do with the model itself but without which the model cannot do its job.

🦊
There's a guide here if you want one

Kitsune can talk through anything on this page — whether it might suit you, what to do next, questions this page doesn't answer. Everything here is yours to read either way.

The title "ML engineer" attracts people who want to build cool AI models. The actual job is production systems engineering with ML as the payload. If you want to design models, you want to be a data scientist or research scientist. If you want to make models work — which is a different and equally difficult problem — you want to be an ML engineer. The people who are happiest in this role are those who find infrastructure satisfying and who get genuine pleasure from reliability, automation, and systems that run without intervention.

The on-call and production-monitoring dimension is real. A model serving predictions in a production system is a thing that can break, and when it breaks, the consequences are immediate and visible — wrong recommendations, bad predictions, degraded user experience. ML engineers often carry on-call responsibilities for the systems they deploy.

The field is evolving rapidly. MLOps (the operational practice of ML deployment) has matured significantly, but the tools and best practices are still less stable than in traditional software engineering. An ML engineer's toolkit changes faster than most engineering disciplines.

Software engineering background is the most common path — ML engineers are engineers first who specialise in ML systems. Computer science degrees with coursework in machine learning, distributed systems, and software engineering provide the strongest foundation. Some data scientists transition into ML engineering after discovering they prefer the systems work to the research work. Cloud platform certifications (AWS, GCP, Azure ML) carry weight. The field values demonstrated ability to build and deploy production systems more than academic credentials.