There is a fact about this library that most hiring managers have not registered, and it changes the interview: since version 3 it is a frontend that runs on top of TensorFlow, JAX or PyTorch interchangeably. It is no longer tied to one engine.
That makes “Keras engineer” an unusually ambiguous description. It might mean somebody maintaining a decade-old TensorFlow estate, somebody who learned deep learning through the friendliest available interface, or somebody deliberately using a portable frontend over a backend they can change. Those are three different hires and only one of them is about the library.
Ask which engine it ran on, and watch the answer
This is the single most efficient question available, because it dates the candidate’s experience precisely and without confrontation.
Somebody whose answer is simply “TensorFlow”, with no awareness that the question could have another answer, has experience from before the multi-backend era — which is common, legitimate and exactly what you want if your estate is that old. Somebody who says they ran it on JAX for the compiler, or on PyTorch to fit the surrounding ecosystem, has been paying attention recently and is thinking about the engine as a choice.
Neither answer is wrong. But if you hire the first for a greenfield project and the second for a legacy migration, you have mismatched both.
The legacy-estate hire, which is the most common real need
A great deal of production machine learning in Britain was built in this library between roughly 2017 and 2021, and much of it still runs. Those systems need maintaining, and the work has a specific character: the original authors have left, the training data pipeline is partly undocumented, dependencies are pinned to versions that constrain everything else, and nobody is certain what would happen if the model were retrained.
If that is your situation, screen for archaeology rather than for novelty. Ask how they have approached a model they did not write and could not fully reproduce. Strong answers involve establishing a baseline first — getting the existing model to produce identical outputs on a fixed input set before changing anything — because without that, any subsequent change is unverifiable.
Ask too what they would do about the dependency situation. The honest answer is usually to containerise and freeze rather than to upgrade optimistically, and to make the decision to rewrite explicitly rather than by accident.
The teaching-background candidate, and why they are underrated
This library’s deliberate friendliness means a disproportionate number of people learned deep learning through it, including many who came from academia, from another discipline, or from a career change.
That can read on a CV as inexperience and frequently is not. Somebody who can explain clearly why a model is not converging is more useful on most teams than somebody who can recite architectures, and the ability to explain things is not incidental — a great deal of applied machine learning is persuading colleagues to trust or distrust a result.
The test is whether the understanding goes below the interface. Ask what happens in a training step: forward pass, loss, gradients, an optimiser update, and why the batch size interacts with the learning rate. Somebody who learned through a high-level interface but understands the mechanism will answer comfortably. Somebody who only knows the interface will describe the function calls.
When this should not be a requirement at all
For new work, requiring this library specifically narrows your field for almost no benefit. An engineer strong in PyTorch will be productive in it within days, because the concepts are shared and the interface is the easy part.
So put it in the advert only when it is genuinely load-bearing: an existing estate to maintain, or a deliberate multi-backend strategy you can articulate. Otherwise advertise the problem and let the library be an implementation detail. If your actual requirement is the older engine underneath, the TensorFlow engineer guide describes that hire and its migration questions more directly.
What maintenance work pays, and why it is under-priced
Indicatively £60,000 to £95,000 permanent, with day rates from around £450. About 250 UK employers name it in the pages we index, a figure dominated by maintenance rather than by new building.
Two things follow. Legacy maintenance work is frequently under-priced relative to its difficulty — keeping an undocumented model alive is harder than building a new one and is rarely paid as though it were. And candidates whose experience is principally in this library sometimes undersell themselves against people with more current vocabulary, which is an opportunity if you are hiring for a maintenance role and a risk if you mistake modesty for weakness.
A note on the multi-backend strategy, if that is your reason
Some teams choose this library deliberately in order to keep the engine underneath replaceable — write the model once, run it on whichever backend suits the deployment. It is a coherent position and worth screening for properly, because it is not free.
Ask what they found did not port. The honest answer is that the high-level path is genuinely portable and anything custom is not: a bespoke training loop, a custom layer reaching into backend-specific operations, or a performance trick that exists in one engine. An engineer who has actually switched backends will describe where the abstraction held and where they had to write two versions. Somebody quoting the promise has not tested it.
A question for the migration decision
If you are weighing whether to move an estate off this stack, ask candidates for their view and listen for whether they ask what the model is worth. Rewriting a model that generates modest value is a poor use of a quarter; rewriting one that is central and unmaintainable is overdue.
The engineers worth hiring treat that as a commercial question with a technical component, not the reverse. It is also the fastest way to find out whether somebody will tell you an inconvenient thing before or after you have paid for the work.