OpenCV is the oldest thing on this site, and that changes the hire. It predates the deep learning era by a decade, which means the people who know it best are frequently not machine learning engineers at all — they are engineers who have been making cameras produce useful information since before that was fashionable.

The most common mistake is treating this as a junior version of a neural network role. It usually is not. It is a classical computer vision role, and the two skill sets overlap less than the shared job title suggests.

Most vision problems do not need a neural network

This is the argument for the role and it is worth stating plainly, because it runs against fashion. A great many industrial vision problems are solved better, faster and far more cheaply by classical methods: thresholding, morphology, contour finding, template matching, edge detection, a calibrated camera and controlled lighting.

If you are counting objects on a conveyor, reading a fixed-position label, measuring a dimension, or detecting whether a part is present, a classical pipeline runs in milliseconds on a cheap processor, behaves deterministically, and can be debugged by looking at the intermediate images. A trained model doing the same job needs labelled data, a GPU or a careful export, and fails in ways nobody can explain to a production manager at two in the morning.

So the screening question that matters most is: when would you not use a neural network? An engineer who cannot answer that will reach for a model regardless, and you will pay for training data you did not need.

The lighting question, which sorts candidates immediately

Ask what they would change first if detection accuracy were poor. The best answer in industrial work is frequently the lighting, not the algorithm.

Engineers who have actually deployed vision systems talk about lighting as a design variable: diffuse versus directional, backlighting to get a clean silhouette, polarisers to kill reflections off metal or glass, controlling ambient light so results do not change between morning and afternoon. It is unglamorous and it routinely turns an unreliable system into a reliable one for the price of a lamp.

Candidates whose experience is entirely in software will optimise the algorithm against images they cannot change. That is the right instinct when the images arrive from somewhere you do not control, and the wrong one when you own the camera.

Calibration and geometry, the part that is genuinely hard to fake

If your application measures anything, converts pixels to real-world units, or uses more than one camera, this is where competence shows.

Worth asking about: intrinsic and extrinsic calibration and why both matter, lens distortion and what happens if you ignore it at the frame edges, how they validated a calibration rather than assuming it, and — for stereo or multi-camera work — rectification and the relationship between baseline and depth accuracy.

This is mathematically real and hard to bluff. A candidate who has done it will talk about the calibration target, how many images they captured and why, and the residual error they accepted. Somebody who has only called the function will not.

Performance on hardware that cannot be upgraded

Classical vision is frequently deployed somewhere small: an embedded board, a camera, an industrial PC bought five years ago. That constraint shapes the work.

Ask how they made a pipeline faster. Good answers are specific to the domain — processing a region of interest rather than the full frame, working at reduced resolution where precision allows, converting colour space once rather than repeatedly, avoiding needless copies, and using the library’s own optimised paths rather than writing loops in a scripting language. Anybody who has shipped to a constrained device will also mention measuring frame time rather than estimating it.

Where the work has moved onto deep learning models running at the edge, that is a different and complementary skill, and our computer vision engineer guide covers the modern half. Many of the strongest practitioners do both, and the combination is genuinely valuable: a pipeline that uses a model only for the step that needs one.

Where these engineers come from

Look beyond AI teams. The deepest classical vision experience sits in manufacturing and industrial automation, in medical imaging, in robotics, in defence and aerospace, and in anybody who has built a machine that inspects something.

Those candidates often have C++ rather than Python as their primary language, have worked to tolerances, and are used to systems that must run unattended for months. They are also frequently overlooked because their CVs do not use current vocabulary — a CV that says “machine vision” rather than “computer vision” is usually somebody with fifteen years of exactly the relevant experience.

What it pays

Indicatively £60,000 to £95,000 permanent, with day rates from about £450, and the upper end reaching considerably higher where the work combines vision with robotics or safety-critical systems. Around 190 UK employers name the library across the pages we index, spread across industries rather than concentrated in technology companies.

The rates are lower than for model-centric roles, which is a genuine market inefficiency rather than a reflection of difficulty. Calibrating a multi-camera rig correctly is harder than fine-tuning a detector, and it is priced as though it were not.

A caution about the brief

Be specific about the environment, because it determines who is suitable. “Build a vision system” could mean a controlled enclosure with fixed lighting and a known camera, or an outdoor camera in weather with no control over anything. The first is a tractable engineering problem; the second is considerably harder and will fail if scoped as though it were the first.

The engineers worth hiring will ask you about the environment before they ask about the algorithm. Treat that as the strongest positive signal in the whole process.