Last updated: September 3, 2026
By Mike Carter, Director of Partnership Success, KORE1
A computer vision engineer job description needs four facts up front: the sensor, the deployment target, the latency budget, and whether the job is training models or shipping them. Without them, a research scientist, an autonomous-vehicle perception engineer, and an industrial machine vision specialist all read the same posting and all think it might be theirs. That is how a req collects 180 applications and yields no shortlist. Public pay figures for the title land anywhere between about $103,000 and $167,000 depending on the source, which is a clue that the sources cannot agree on what the job is either. Our computer vision engineer staffing desk exists largely because of that spread.
The req had been open eleven weeks. Forty resumes reviewed, three of them liked.
A packaging manufacturer outside Grand Rapids needed someone to catch seal defects on a bottling line. Their posting said what these postings always say. Python, PyTorch, TensorFlow, OpenCV, experience with object detection and image segmentation, bachelor’s in computer science, master’s preferred. Around 180 people applied. Most of them were good. Genuinely good, people who had trained real models against real datasets and could talk fluently about mAP, class imbalance, and augmentation strategy.
None of them were right for the job, and it took eleven weeks before anybody said that out loud.
The defect was a wrinkle in a foil seal. About a millimeter across, on a reflective surface, moving past the camera at 300 units a minute. Hard problem. It stays a hard problem right up until somebody puts a dome light over the station and a telecentric lens on the camera, at which point the wrinkle becomes a dark line on a bright field and a threshold operation older than most of the applicants catches it at 99.98%. No model. No training set. No GPU.
The people who know that are machine vision engineers. They live in HALCON and Cognex VisionPro, they think about illumination geometry before they think about algorithms, and a fair number of them have never once described themselves as a “computer vision engineer” anywhere a recruiter would find it. That posting had been sourcing deep learning talent for a lighting problem since the middle of spring.
Worth saying who is talking here. I run a tech desk. We only get paid when a company gives up on filling one of these alone, so weigh everything below accordingly. The rest of this page is about fixing the posting yourself, at no cost, with nobody from my side in the room. The practice sits inside our wider AI and ML engineer staffing group, and honestly, the intake call we run before a search is roughly the first half of this article.
One Title, Five Different Careers
“Computer vision engineer” is not a job. It is a category. Five unrelated career tracks share it, and they have different tooling, different interview loops, and comp bands that overlap mostly by accident.
| Track | What the posting has to name | What you get when it does not |
|---|---|---|
| Applied deep learning research | The dataset, the model family, and what counts as done | Researchers who leave in month five when the work turns out to be integration |
| Perception, autonomous systems and robotics | The sensor suite, the calibration burden, and whether the code is C++ or Python | Python-only modelers on a stack that is mostly C++17 and ROS 2 |
| Industrial machine vision | The camera, the lighting, the cycle time, and the false-reject target | A bottling line in Michigan and eleven wasted weeks |
| Edge and embedded vision | The silicon, the frame rate, and the power envelope | Strong model builders who have never quantized anything to INT8 |
| Medical and scientific imaging | The modality, the regulatory pathway, and where labeled data comes from | Excellent engineers who have no idea what a 510(k) submission costs in calendar time |
People move between these tracks. A perception engineer out of an autonomous trucking program can absolutely learn HALCON, and some of the best industrial vision people I have placed started in academic research. The move is real. It is not free. Budget two quarters of ramp, and say so out loud in the offer conversation instead of discovering the gap in a sprint review five months later.
The overlap trap runs the other way too. Somebody who has shipped an inspection cell is often assumed to be junior by a hiring manager from the deep learning world, because the code has fewer layers in it. That assumption has cost several of my clients a very good candidate.
Name the Sensor Before You Name the Framework
Almost every posting leads with frameworks. OpenCV, PyTorch, TensorFlow, sometimes scikit-image if the writer was thorough.
Those lines filter nothing. Everyone in this field has touched all three, the way every backend engineer has touched Git, so naming them tells a candidate nothing about fit. The sensor is the filter. It decides which physics you are fighting, and the physics decides who can do the job.
RGB video from a fixed camera is one world. Stereo pairs and structured light and time-of-flight depth are another, with their own vocabulary around baseline, disparity, and the way a shiny surface destroys a depth map. LiDAR and camera fusion drags in extrinsic calibration and time synchronization, and anyone who has done it at scale will tell you that most of the hard work is not the network. Thermal and SWIR carry different noise characteristics entirely. Line-scan cameras on a moving web are their own discipline. DICOM volumes out of a CT scanner are three-dimensional and anisotropic, and the annotation comes from a radiologist whose time costs more than your GPU cluster.
An engineer who has spent four years debugging rolling shutter artifacts on a conveyor is not automatically an engineer who can register a cardiac MRI series. Both write Python. Both import OpenCV. Past that, almost nothing transfers.
So write the sensor into the first paragraph. “Six surround cameras and a 128-line LiDAR” or “a single 5MP monochrome area-scan camera with backlit fixturing” or “axial CT volumes at 0.6mm slice thickness.” One sentence. It does more filtering than the entire requirements section underneath it.
Where the Model Runs Is Half the Job
This one costs the most money. I see it in maybe seven of every ten reqs that cross my desk.
Training a model and deploying one are adjacent skills, not the same skill. The training side is data curation, architecture selection, loss design, and evaluation discipline. The deployment side is quantization, graph optimization, memory layout, and a long argument with a runtime that will not fuse the operator you need it to fuse. Both are computer vision. People who are genuinely excellent at both exist. They are expensive, and you want to know that before you set the band rather than after a candidate declines it.
A model that hits 94% mAP in a notebook and eleven frames per second on the target board is not a finished project. It is a research result. Getting from there to thirty frames per second inside a fifteen-watt envelope on a Jetson Orin module is weeks of work in TensorRT, ONNX Runtime, or OpenVINO, and it is the kind of work that either someone has done before or has not. There is no partial credit on this one.
Three numbers belong in the posting. Frames per second at the target resolution. End-to-end latency budget, meaning camera to decision, not just inference time. Power envelope in watts, if it runs on anything battery-powered or fanless.
Publish those and the wrong candidates screen themselves out before you spend an hour on a call. Leave them out and you will find the constraint in week three of an onboarding, which is a bad week to find it. If the deployment target is a real constraint on your req, our embedded software engineer job description template covers the adjacent skills you may actually be shopping for.
The Compliance Line Most Postings Skip
Computer vision carries a regulatory layer that most software roles do not. It changes who is qualified. Dramatically, in some cases.
Medical imaging is the obvious one. The FDA maintains a public list of AI-enabled medical devices that have cleared review, and the great majority of them are radiology. An engineer who has carried a model through a 510(k) submission understands what the documentation, the locked-model requirement, and the clinical validation actually cost in months. An engineer who has not will estimate the timeline off the modeling work alone and be wrong by a factor most CFOs find memorable. IEC 62304 governs the software lifecycle underneath all of it.
Defense and geospatial imagery work adds a clearance requirement. If the work touches ITAR-controlled data or needs an active Secret clearance, that is a line in the first paragraph and not a footnote in the benefits section, because it removes something like ninety percent of the market before anyone reads a bullet.
Then there is biometrics, which catches people out. Illinois has the Biometric Information Privacy Act, Texas and Washington have their own statutes, and a retail analytics or access control product that touches faces or gait needs an engineer who has thought about consent, retention, and on-device processing rather than one who has only thought about accuracy. Nobody puts this in a job description. It surfaces later, usually in a legal review, usually after the architecture is built.
One sentence handles all of it. “This role owns the perception model in a Class II device on a 510(k) pathway” does more sorting than everything under your Requirements header combined.
Six Sources, Six Different Answers
Pay data for this title does not converge. That is not a data-quality complaint. It is evidence for the argument this whole page is making.
| Source | What it is measuring | US figure |
|---|---|---|
| Comparably (2026) | Computer vision engineer, self-reported | $103,076 average |
| ZipRecruiter (July 2026) | Base pay pulled from active listings | $121,515 average |
| O*NET (2025 median) | Software developers, SOC 15-1252.00 | $135,980 median |
| O*NET (2025 median) | Computer and information research scientists, SOC 15-1221.00 | $140,300 median |
| Indeed (August 2026) | Computer vision engineer, 413 reported salaries | $151,709 average |
| Glassdoor (July 2026) | Computer vision engineer, total pay | $167,000 median |
Sixty-four thousand dollars of spread on one nominal job. Nobody in that table is wrong. Comparably and Glassdoor are counting different populations under the same heading, ZipRecruiter draws from posted listings that systematically under-count the senior end, and Indeed sits in between on a sample of 413.
Here is the detail I find genuinely useful. Search O*NET, the federal occupational database, for “computer vision engineer” and the top match it returns is Computer Hardware Engineers. The occupation does not exist in the taxonomy. The closest fits are software developers at a $135,980 median with about 115,200 annual openings projected, and computer and information research scientists at $140,300 with only 3,200. Neither describes the person you are hiring. Federal labor data cannot see this job, which is part of why the private aggregators disagree so loudly.
Demand is not ambiguous, even if the wage data is. Lightcast’s read of the 2026 Stanford AI Index puts AI skills in 2.5% of all US job postings, up 55% in a single year and close to 300% over the decade. Vision sits inside that curve.
Then post your band. Several states now require it, this candidate pool trades numbers in forums nobody on your side is reading, and one published range does more sorting than a whole screening call. The salary benchmark assistant will price a band against your actual scope for free, and the longer computer vision hiring guide breaks the market apart by vertical.
One more number, since we are talking about postings rather than candidates. LinkedIn’s own analysis found that job posts between 1 and 300 words earn 8.4% more applications per view than average. Whatever your requirements section has grown to, it is not earning its length. It probably never was.
Computer Vision Engineer Job Description Template
Take this and fill in the brackets. The notes in brackets are there to explain the reasoning. Delete them before the req goes live.
Job Title
[Computer Vision Engineer, [Perception / Edge / Medical Imaging / Machine Vision] / Senior Computer Vision Engineer / Perception Engineer] [The specialization belongs in the title. “Computer Vision Engineer, Edge Deployment” pulls a narrower and far more relevant slate than the bare title, because job boards weight titles heavily and so do candidates.]
About the Role
[Company] is hiring a computer vision engineer in [city, state or remote with time zone] to work on [describe the actual system in one sentence: defect detection on a high-speed packaging line, multi-camera perception for an autonomous yard truck, segmentation of axial CT volumes for a Class II diagnostic device]. Input comes from [name the sensors: a single 5MP monochrome area-scan camera, six surround RGB cameras plus a 128-line LiDAR, a 3T MRI scanner]. Models run on [target: an on-prem A100 cluster, a Jetson Orin NX at the edge, a customer’s browser] with [latency or throughput requirement]. The split is roughly [60% deployment and optimization, 40% modeling]. Reporting line is [role]. Day to day this person works with [the mechanical engineer, the regulatory lead, the platform team, and whoever they will end up negotiating with].
What You Will Own
- The [detection / segmentation / tracking / registration] pipeline end to end, from [ingest] through [decision], including the parts nobody puts in a diagram
- [Sensor calibration and synchronization across [N] cameras and [LiDAR / IMU / encoder], including the drift that shows up after a month in the field]
- Model optimization for the target hardware. Quantization, pruning, and graph-level work in [TensorRT / ONNX Runtime / OpenVINO / Core ML] to hit [X] FPS inside [Y] watts
- [If regulated: the verification and validation package for [system], written to [IEC 62304 / a 510(k) pathway], including locked-model and clinical validation requirements]
- Evaluation that survives contact with production. Long-tail failure analysis, drift monitoring, and a retraining trigger that is not a person noticing
- Data. Annotation strategy, quality control on the labels, and an honest answer about how much of it you actually need
What We Need to See
- [3+] years shipping vision systems that ran in production, not notebooks. We will ask what broke and how you found it
- Depth in [PyTorch / TensorFlow] plus the classical toolkit. Camera models, intrinsics and extrinsics, color spaces, and enough optics vocabulary to have a useful conversation about lighting
- [Language the codebase is in. If it is C++17 with Python bindings, say that. It removes half the pool and it should.]
- [Deployment experience on [target silicon], including a specific example of a latency or memory problem you solved]
- Judgment about when not to use a model. [If a candidate asks about your lighting and fixturing before proposing an architecture, that answer is most of your screen right there.]
- [If applicable: [3D reconstruction / SLAM / stereo depth / multi-spectral / DICOM and PACS workflows / GigE Vision and HALCON or Cognex]]
Nice to Have
- CUDA kernel work, for the cases where the runtime is not fast enough and somebody has to go a layer down
- [Your domain.] Automotive functional safety, FDA-regulated development, cleanroom practice, and retail biometric privacy each take years to absorb, and none of them get picked up on the fly
- Experience with foundation models in a vision context, meaning fine-tuning and evaluating them rather than calling an API
- Anything from the hardware side. Engineers who have specified a lens or argued with an optics vendor are disproportionately useful
Constraints and Environment
[Write this section. Put it above the benefits list, where somebody will actually read it.] [Target hardware and the performance requirement it has to hit.] [On-site expectations, because a physical camera rig usually means somebody has to be in the room with it. Say how often.] [Travel to customer sites or plants, as a percentage.] [Access to real data on day one, or a description of what exists and what does not. Candidates ask. The honest answer is fine, the vague one is not.]
Compensation
[$X to $Y] base. [Equity], [bonus], [relocation support], [benefits]. [Publish the range. If a clearance requirement or a regulated pathway moves the number, note that here rather than at offer stage.]
What Hiring Teams Ask Before the Req Goes Live
Why does every applicant have basically the same PyTorch resume?
Because the posting described a toolkit instead of a problem. Frameworks are shared across every track in this field, so listing them selects for nothing and attracts whoever is most actively looking.
Swap the framework bullets for one sentence naming the sensor and the deployment target. The pile gets smaller immediately, which feels like a loss for about a day and then stops feeling like one. Our ML engineer job description template runs into the same failure mode from the other direction, if the req is really a modeling seat.
Do we actually need a PhD on this req?
Usually not. A doctorate matters when you are inventing an approach rather than applying one, which describes a small minority of the vision work companies are actually hiring for right now.
Where it earns its keep is novel architecture work, publication-adjacent research, and a few medical and scientific imaging problems where the literature is the job. Everywhere else it functions as an expensive proxy for skills you could test directly in ninety minutes. I have watched “PhD preferred” cut a viable pool by two thirds on reqs where the actual work was integration and optimization. Write down what the person has to do first, then decide whether a dissertation is evidence of it.
Is machine vision a different job or just a different word?
Different job. Machine vision means industrial inspection with controlled lighting, fixed optics, and cycle-time constraints, and its practitioners often solve problems with geometry and illumination rather than models.
The two populations barely overlap on job boards. Machine vision people search “machine vision engineer,” “vision systems engineer,” or sometimes “controls engineer,” and they filter past a posting that leads with TensorFlow because it reads as a research role to them. If the work happens on a production line, use their vocabulary. Mention the camera and the lighting. That is the signal they are scanning for.
How long should the posting actually be?
Shorter than yours currently is. LinkedIn’s data shows posts under 300 words draw 8.4% more applications per view than average, and the length usually comes from padding rather than substance.
Cut the responsibilities section first, because that is where most of the bloat lives and it is the section high-performing posts trim hardest. Keep the sensor, the deployment target, the domain, the constraints, and the band. Those five are worth more than every soft-skill bullet ever written, and writing them down takes maybe ten minutes. Knowing them takes longer. That is the actual work.
The model has to run on a Jetson. Is that one hire or two?
One hire if you can find a deployment-first engineer and you accept that the modeling will be pragmatic rather than novel. Two if the model itself is the hard part and the hardware target is aggressive.
Be honest with yourself about which half is the actual bottleneck, then hire for that half and buy the other one. A pattern that works well: a contract engineer for the optimization push, running alongside a direct hire search for the person who owns the system afterward. Your permanent hire then arrives while the optimization work is still live and learns the system from someone whose hands are still in it. No written handoff comes close to that.
The req has been open three months. Rewrite it, or raise the band?
Rewrite it first. It is free, it takes an afternoon, and a posting that has attracted the wrong population for twelve weeks will keep attracting them at a higher number.
Money fixes a competitive problem. It does not fix a targeting problem, and the tell between them is in your funnel. Plenty of applicants and no qualified ones is a targeting problem. Qualified people withdrawing at offer is a comp problem, or a constraint you failed to disclose early enough. Those get fixed with different tools, and spending on the wrong one is how a three-month search becomes a six-month search with a bigger number attached.
Before You Post It
Name the sensor. Name where the model runs and what it has to hit. Say whether this is a training seat or a shipping seat. If it is genuinely both, put a percentage on it. State the regulatory or clearance overlay in the first paragraph if there is one. Post the band.
That is the whole list. It will do more for your applicant pool than the requirements section it replaces, and the reason most postings leave it out is not laziness. Nobody has settled those questions internally yet. Better to have that argument in a conference room in week one than on a bottling line in week eleven, getting a lesson in dome lighting from a candidate you are about to lose.
If you want a second read on a req before it goes live, or a stalled search looked at by somebody who has run a few hundred of them, talk to our technical recruiting team. Vision searches run alongside our deep learning and wider IT staffing desks across 30-plus US metros. Average time to hire is around 17 days and 92% of our placements are still in seat at twelve months. Ask any recruiter you talk to for both numbers. Most will give you one.
