Computer Vision Engineer

Before you apply

• We're direct about how we work. Read this section first.
• This is client work, on site. Factory floors, gates, warehouses, public spaces. The camera is where the client could mount it, not where you would have chosen.
• We value engineers who know what they don't know, and say so. If you're honest about your gaps, we'll invest in closing them. If you hide weaknesses or oversell your experience, you won't last here.
• The model is the small part. Most of this job is lighting, camera placement, label quality, class definitions, and arguing about thresholds. If you want to spend your time on architectures, this is not the right fit.
• We move fast. Growth happens outside comfort zones. If this sounds harsh, we're probably not a fit. If it sounds like the work you have been waiting for, keep reading.

The role

We ship computer vision that runs somewhere hard. Defect detection on production lines, licence plate recognition at gates and on roads, detection and alerting in public spaces. Manufacturing, warehousing and logistics, retail, public safety, transport.

Every one of those is a system rather than a model. The client measures whether it works, there is a number attached, and the release has to clear a gate before it goes anywhere. You own the whole path from the camera to that number.

What you'll own

• The capture end: where the camera goes, what it can actually see, what the lighting does at 6am and at 3pm, and what you can negotiate with the client's facilities team.
• The data: class definitions that survive contact with real footage, annotation quality, and the edge cases nobody collected. A first production class usually needs a few thousand labelled examples, and getting them right is the job rather than a preliminary.
• The model, and its limits: training, fine-tuning where that is honest, and building from the ground up where it is not. Knowing which situation you are in is part of the skill.
• Making it fit: running inside a latency and hardware budget on the box the client will actually buy. ONNX, TensorRT, quantisation, and the trade-offs you accept to get there.
• Thresholds and the cost of being wrong: a false positive that stops a line and a false negative that reaches a customer cost very different amounts. You work out which way this client should lean, and you say so in numbers.
• Drift: noticing the model got worse before the client tells you, and knowing whether the world changed or the camera moved.

What you must arrive with

We do not count years and we do not require a degree. We look for evidence.

• You have put a vision model somewhere real and kept it working. Not a notebook, not a benchmark, something with a camera and a consequence.
• You can debug the whole path. When it works in testing and fails on site, you know how to find out why, and the answer is often not the model.
• Python, and PyTorch or equivalent. Enough systems ability to get inference running inside a constraint.
• You can explain a precision and recall trade-off to someone who runs a factory and does not care how convolution works.

A GitHub account is required to apply. A posting that says it does not count years has to count something else, and this is it. We are not counting stars or green squares. We are looking for something you built and can be questioned on, so a fork you have not committed to or a tutorial followed to the end does not help you. A small, unfinished, honest project does. We look at every link, including whether a repository is a fork and how it was actually built.

Everything else is welcome and none of it is required. Demos or video of something running, Kaggle, papers, write-ups, talks.

Nice to have

• Edge hardware in anger, meaning Jetson, an NPU, or whatever the client's integrator insisted on
• Annotation pipelines and the tooling around them, including how you audit label quality rather than assume it
• Multi-camera work, calibration, or anything involving position in space
• Video rather than frames, and the state that comes with it

A note on weapon detection

One of our product lines is detection in public spaces, and we will say plainly that almost nobody in this country has shipped that into production, so we are not going to pretend to screen for it. What transfers is detection under bad conditions with a false positive budget that actually matters, and that is what we will ask you about. If you have done the harder version of that in another domain, we want to talk to you.

What we offer

• Systems that run in the real world and get measured, rather than pilots that quietly end
• Several industries and several problem shapes in a year
• A team that argues about evidence and does not mind being wrong in public
• Investment in your growth if you're honest about where you need it

How we hire

Apply through the form. Seven questions, and four of them are drawn from a larger bank, so no two candidates get the same set and there is no list to prepare against.

If we talk, one round is a review. We show you a vision system that is performing badly on a client site, with the evidence you would actually have, and ask you where you would look and in what order. There is no single right answer. We are watching how you narrow it down.

A human reads every application, and answers that read as model-generated are tested in depth in that conversation, where they do not survive. Everything you write, and everything you link us to, will be discussed there.