Nobody has the job title, and you should not advertise it. What you have is a tabular prediction problem — churn, fraud, credit risk, demand, pricing, propensity — and gradient boosting is very likely the correct tool for it. The hire is a machine learning engineer or data scientist whose instincts are right for structured data.

The reason to have a page about it at all is that this family of models quietly produces more commercial value than anything fashionable, and the skills that make somebody good at it are specific and testable.

Start by asking why not a neural network

It is a fair question and the answer is well established: on tabular data of the size most companies actually hold, gradient-boosted trees usually match or beat deep learning while training in minutes on a laptop rather than hours on a GPU.

A candidate who can explain why — that trees handle heterogeneous, unscaled, mixed categorical and numeric features natively, and that tabular data lacks the spatial or sequential structure that makes deep architectures pay — understands their tools rather than following fashion. One who wants to bring a transformer to a table of 40,000 customer records is telling you their interest is in the technique rather than the problem.

The corollary is also worth hearing: they should know when trees are the wrong answer. Genuinely high-cardinality text, images, sequences where order carries the signal, or extrapolation beyond the training range, where trees simply cannot.

Hyperparameter discipline, which is where most candidates are weak

This model family has a lot of knobs and it is unusually easy to tune yourself into a result that does not survive contact with new data.

Ask what they tune first and why. The answer you want is short: learning rate against number of trees as the primary trade, then tree depth, then the sampling and regularisation parameters — with early stopping on a validation set doing most of the work on tree count so it is not a guess. Somebody who lists a large grid search over everything has substituted compute for understanding, and somebody who has never used early stopping has probably been overfitting quietly.

The follow-up that separates good from excellent: how did they know the tuning had not simply fitted the validation set? A candidate who has been burned will describe a held-back test set touched once, or nested cross-validation, and will be appropriately suspicious of a score that improved by a tenth of a per cent over forty experiments.

Imbalance, and the metric conversation it forces

Most valuable tabular problems are rare-event problems. Fraud is not half your transactions; churn is not half your customers.

Ask how they handle it. Adjusting the positive class weight is usually the first and most honest lever, and anybody reaching immediately for synthetic oversampling should be able to say why they prefer it and what it risks. But the more revealing part is the metric: accuracy is meaningless at one per cent positives, and the candidate should move straight to precision and recall at an operating threshold chosen from what a false positive actually costs the business.

A strong candidate will ask you that question rather than waiting to be told it. In fraud, a false positive is a blocked customer and a support call; in preventative maintenance it is a wasted inspection. The threshold is a commercial decision the engineer should insist on having.

Explanation, which is frequently the reason for the choice

In lending, insurance and anything with a model risk function, being able to say why a model produced a particular output is a requirement rather than a nicety — and it is a large part of why this family of models is chosen over something less interpretable.

Ask how they have explained an individual prediction to somebody outside the team. Feature attribution per prediction is the usual answer and a good one; what you are listening for is whether they understand its limits, particularly that correlated features share credit in ways that can mislead. Somebody who has presented to a credit committee will be careful about this in a way that somebody who has only produced a global importance chart will not.

What good production practice looks like

  • Categorical handling is explicit, and the behaviour when an unseen category arrives in production is a decision rather than an exception.
  • The model is versioned with its feature definitions. Trees are unforgiving about column order and type; a mismatch between training and serving is the classic silent failure.
  • Monitoring watches the inputs, not just the outputs. These models degrade when the population shifts, and the first visible sign is usually in the feature distributions.
  • A trivial baseline exists. Predicting the base rate, or last month's value, so the model's contribution is measured rather than assumed.

What it pays, and how to advertise it

Indicatively £60,000 to £95,000 permanent, with day rates from about £450 and the upper end in regulated work where documentation and defensibility are part of the job. Around 90 UK employers name the library across the pages we index, almost always as one line in a longer list.

Advertise the problem, not the library. “Build the model that decides which customers we contact” will reach people who have done it; a requirements list containing the package name will reach people who have read the documentation. If the role leans toward stakeholder work the data scientist guide fits better, and if it leans toward the surrounding library ecosystem the scikit-learn guide covers the same population from the other side.