The Actual Skills That Get You Hired as an ML Engineer

Why the job spec lies to you

Most machine learning job adverts read like a shopping list: PyTorch, transformers, distributed training, maybe a bit of Kubernetes for good measure. Candidates respond in kind, stacking their CVs with framework names as if fluency in an API were the same thing as engineering judgement. It rarely is. I have sat through enough interview prep and technical discussions to notice a pattern: the people who actually get hired and, more importantly, get retained past the first project, are not the ones who know the most libraries. They are the ones who can be trusted not to ship a model that quietly lies about how good it is.

That trust comes from a small set of skills that never appear explicitly in the job description because they are assumed to be table stakes. They are not. Most of what separates a strong candidate from a merely competent one comes down to how they handle evaluation, how they think about data before they think about architecture, and whether their results survive contact with someone else's laptop. None of this is glamorous. All of it is what keeps a model from being quietly withdrawn from production three weeks after launch.

Leakage-aware evaluation is the real interview question

Here is a scenario I would use to test a candidate, and one that comes up constantly in real work: you are building a model to predict whether a customer will cancel a subscription next month, using a dataset with one row per customer per month. If you split that dataset randomly into train and test sets, you will almost certainly have rows from the same customer appearing in both. The model learns to recognise the customer, not the pattern of churn behaviour, and your test accuracy of 94 percent is essentially fiction. Split by customer ID instead, or better, split by time so that the test period comes strictly after the training period, and that same model might report something closer to 71 percent. That gap is not a bug in the model. It is the difference between a number that describes reality and a number that describes wishful thinking.

This kind of leakage shows up in more subtle forms too. Features derived from aggregates computed over the whole dataset, a customer's average spend calculated before you split the data, will bleed future information into the training set. Time series problems are especially prone to this: if you shuffle rows before splitting, you let the model peek at data from after the point it is meant to be predicting from. I have seen entirely reasonable-looking pipelines produce metrics that were, in effect, meaningless, simply because the split happened one line too early or too late in the preprocessing script.

Candidates who catch this in an interview, or better, who ask about it before being told, are demonstrating something far more valuable than knowledge of a specific algorithm. They are showing that they treat a reported metric as a claim that needs defending, not a number to be quoted. Hiring managers who have been burned by a leaked test set once, and most who have been in the industry a few years have been burned at least once, will remember that instinct long after they have forgotten which frameworks you listed.

Strong baselines and honest comparisons

The second skill worth cultivating is a genuine respect for baselines. It is tempting, especially early in a career, to reach for the most sophisticated model available because that is what feels impressive. But a gradient boosted tree tuned properly on tabular data will often match or beat a deep learning model that took ten times longer to train, and a logistic regression with sensible features is sometimes embarrassingly close to both. If you cannot say precisely how much better your fancy model is than the simplest reasonable alternative, you do not actually know whether the complexity is earning its keep.

Concretely: suppose a churn model built with careful feature engineering and logistic regression achieves an AUC of 0.81. A gradient boosted model, with more tuning effort and longer training time, reaches 0.83. Is that two-point gain worth the loss of interpretability and the added maintenance burden of a heavier model in production? Sometimes yes, particularly at scale where a couple of percentage points translate into meaningful revenue. Sometimes no, particularly when the business needs to explain individual decisions to a regulator. Being able to reason through that trade-off, rather than defaulting to whichever model is currently fashionable, is exactly the kind of judgement that senior engineers look for when deciding whether to trust a junior colleague with a production pipeline.

This also means being honest when a result does not hold up. If a candidate tells me their model improved performance by 15 percent and, on questioning, it turns out that improvement came from a test set that happened to be unusually easy, or from a metric that was cherry-picked after several runs, that is far more damaging to their credibility than admitting the model only offered a modest, well-validated improvement of two or three percent.

Reproducibility is the skill nobody mentions until it is missing

The final piece is unglamorous but decisive: can someone else run your code and get the same answer. Fixed random seeds, pinned package versions, a clear record of which data snapshot produced which result. It sounds trivial until you have watched a demo fail because the presenter's notebook depended on a state left over from an earlier cell, or a model's reported performance turned out to be unreproducible because the training script pulled a slightly different dataset each time it ran.

In an interview or a work trial, this shows up as small things: does the candidate version their data splits, do they log which hyperparameters produced which metric, do they write down the assumptions behind a preprocessing step rather than leaving it implicit in a function nobody documented. None of this requires advanced mathematics. It requires the discipline to treat an experiment as something that should survive being handed to a stranger, because eventually it will be.

If I had to compress all of this into one piece of advice for someone preparing for machine learning interviews, it would be this: spend less time memorising architectures and more time practising the discipline of splitting data correctly, comparing against a sensible baseline, and writing experiments that someone else could rerun and trust. That combination, not the salary figure attached to the job title, is what actually gets you hired and, more usefully, what keeps you employed once you are in the room.