Python / ML Engineer

This profile represents the applied ML shape teams actually need: an engineer who treats a model as one component of a working product, not the whole point. It sits deliberately between two job titles, and understanding that split is most of knowing whether it fits your opening.

The data-vs-ML split, honestly

Job posts blur “data engineer” and “ML engineer” together, but the work divides cleanly. Data engineering is moving and shaping data reliably: ingestion, transformation, storage, quality checks, orchestration. ML engineering is training, evaluating, serving, and monitoring models. Most companies that think they need ML first need the data work, because a model trained on an unreliable pipeline is an unreliable model with extra steps.

This archetype does both, weighted toward the applied side. Roughly, the working time splits into getting data trustworthy, then training or fine-tuning a model on it, then wrapping the result in a service the product can call. What it is not: a research scientist who designs new architectures or publishes papers. If your problem needs invention rather than application, that is a different and much rarer hire. If your problem is “we have data and a product, and we want predictions in it”, this is the fit.

Background

Six years in Python, split between data engineering and machine learning. Has built ingestion pipelines, trained and fine-tuned PyTorch models, and wrapped them in FastAPI services running on AWS. Most of that time was spent in healthtech and SaaS, where messy real-world data and strict handling requirements are the norm rather than the exception. Healthtech in particular teaches habits that transfer everywhere: validate inputs, keep an audit of what data trained what model, and never let convenience decide where sensitive records go.

What the work actually looks like

Pipelines that survive contact with reality. Upstream sources change schemas without warning, deliver late, and send duplicates. This profile builds ingestion with validation at the boundary, alerts when the data drifts from what the model expects, and idempotent jobs that can be rerun without corrupting anything. Orchestration through Airflow or a similar scheduler, with the discipline to make each step restartable.

Training and fine-tuning. In applied work, most wins come from better data and honest evaluation rather than exotic architectures. This archetype starts from a simple baseline, fine-tunes established PyTorch models where they beat it, and keeps experiments tracked so a result can be reproduced two months later. The instinct to try the boring approach first is a seniority signal, not a limitation.

Evaluation against the business. A validation score is not a business outcome. The experienced version of this profile asks what decision the model feeds, what a false positive costs versus a false negative, and builds the evaluation around that. In healthtech this is not optional, because the cost of the two error types is rarely symmetric.

Serving and monitoring. Models ship as FastAPI services with typed interfaces, tests, and a latency budget agreed with the product team. After launch, the model gets monitored for input drift and output quality, because models degrade silently in ways ordinary software does not. The engineer who plans for retraining at design time saves the team a scramble later.

Seniority signals to look for

• Ask what they do when a model underperforms in production but looked fine in training. Strong candidates go to data drift, training-serving skew, and evaluation gaps before touching the architecture.
• Ask how they would decide between fine-tuning a model and calling a hosted API. The honest answer weighs data sensitivity, cost per prediction, latency, and how much the task deviates from what hosted models already do well.
• Ask about a pipeline failure they had to clean up. Listen for backfills, idempotency, and what changed afterward.
• Be wary of candidates who only talk about models and never about the data feeding them. In applied work that ratio is backwards.

Typical engagement

Full time or substantial part time, often as the first ML hire alongside an existing product team. The fit is strongest when there is a product and real data already, and the mandate is to get from “we should use ML” to a served, monitored model. Also fits a data-platform-first mandate where the modeling comes second. IST hours with reliable overlap into European mornings and US evenings by arrangement. Available now.

This is a representative sample of the vetted pool. Request it and we confirm real, current availability for a developer with this background.