About 570 British employers name this library, which makes it one of the most widely used things on this site — and almost nobody advertises for it as a role in its own right. It appears as a line in a longer requirements list, which tells you something true: this is a baseline competence rather than a speciality, and hiring “for scikit-learn” usually means hiring a machine learning engineer or data scientist whose work happens to be tabular.

That framing matters, because tabular modelling is where most commercial value in machine learning still sits, and it is systematically undervalued by candidates and employers who both find language models more interesting.

Most business problems are still tables

Churn, fraud, credit risk, demand forecasting, pricing, propensity, triage, maintenance scheduling. These are the models that run the actual economy, and they are overwhelmingly built on structured data with gradient-boosted trees or something simpler.

The useful consequence for hiring is that the discipline is mature. There are established answers to most questions, the failure modes are documented, and a competent practitioner can be assessed against known good practice rather than against fashion. That makes this one of the more reliable technical interviews you will run — provided you ask about the parts that go wrong in production rather than about algorithms.

Leakage is the interview, really

If you ask one thing, ask about data leakage, because it is the defect that most often destroys a tabular model and it is invisible in cross-validation scores.

The forms worth hearing named: a feature that is only populated after the event you are predicting; scaling or imputation fitted on the whole dataset before splitting, so the validation set has informed the training; a random split on data with a time dimension, which lets the model see the future; target encoding computed across folds; and duplicated rows spread across train and test.

A candidate who has been burned will describe a specific instance — a model that scored beautifully and collapsed on deployment — and will usually mention the pipeline construct that prevents the class of error. Somebody who lists leakage as a concept without an example has read about it.

Validation that matches the way the model will be used

Follow with how they split their data. The right answer depends entirely on the problem, which is why it discriminates.

Time-series or any drifting process needs a forward-chaining split, not random folds. Data with groups — several rows per customer, per site, per patient — needs grouped splitting, or the model memorises the group and looks excellent. Rare-event problems need stratification and a frank conversation about whether accuracy is a meaningful metric at all when the positive class is one per cent.

That last point is worth pressing. Ask which metric they would report to a business sponsor and why. Precision and recall at a chosen operating threshold, tied to what a false positive actually costs, is the answer of somebody who has had to defend a model. A single headline figure is the answer of somebody who has not.

What good looks like beyond the model file

  • The pipeline is one object. Preprocessing and estimator together, so the same transformations apply at training and inference. Hand-rolled preprocessing that has to be reimplemented in the serving code is the most common source of silent production error.
  • Categorical handling is deliberate. What happens when an unseen category arrives in production is a decision, not an exception.
  • Explanations are available. In regulated or high-stakes work, being able to say why the model produced a given output is not optional, and tree-based models with feature attribution are often chosen for precisely that reason.
  • Baselines exist. A candidate who compares against a trivial baseline — predicting the mean, or the previous value — is measuring their contribution rather than assuming it.

Where the scarcity actually is

There is no shortage of people who can fit a model. The shortage is in people who can take an ambiguous commercial question, work out whether it is a prediction problem at all, define the target variable defensibly, and then defend the result to somebody who does not want to hear it.

That skill is mostly not technical, which is why interviews that focus on algorithms select poorly for it. A good probe: ask them to describe a project where the modelling was straightforward and the difficulty was elsewhere. Strong candidates have several and tell them readily, usually involving a target definition that turned out to be wrong or a stakeholder who wanted a different answer.

If the role genuinely is stakeholder-facing, the data scientist guide is the better description of the hire. If it is about getting models into production and keeping them there, the machine learning engineer guide fits closer.

What it pays, and a note on how to advertise it

Indicatively £55,000 to £90,000 permanent, with day rates from about £400 and the upper end in regulated sectors where model risk documentation is part of the job.

Do not put this library in the job title. Nobody searches for it as a role, and an advert built around it reads as though you have listed your stack rather than described a job. Advertise the problem — forecasting, fraud, risk, churn — and the library will be assumed. The candidates who match will recognise the problem; the ones who only match the keyword are not the ones you want.