Computer Vision Interview Questions That Actually Predict Performance

Why standard technical interviews fail for computer vision

A general software interview loop selects for algorithmic puzzle-solving. Computer vision work rewards something different: judgement about data, evaluation and failure modes. The result is that conventional loops routinely reject strong CV engineers and accept people who cannot make a model work outside a notebook. The fix is not to lower the bar but to move it — test the reasoning the job actually requires.

The single most useful question

Ask: "Tell me about a model you shipped that failed in production. What went wrong, how did you find out, and what did you change?" Almost everything you need is in the answer.

• Strong candidates have a specific story with a diagnosis and a fix, and often mention data rather than architecture.
• They describe how they detected the failure — monitoring, a metric they were watching, a customer signal.
• Weak candidates either have no production experience or describe only successes.
• Watch for people who blame the data without having done anything about it. Owning the data is the job.

Probing evaluation judgement

How someone builds an evaluation set tells you more than how they build a model. Anyone can train; far fewer can tell you honestly whether it worked.

• "How did you choose your validation set?" — look for deliberate splits, not "random 80/20". Splitting randomly when data is correlated by site, patient or session is the most common serious mistake in applied CV.
• "What did your headline metric hide?" — strong answers involve per-class, per-size or per-condition breakdowns.
• "How would you know this model has degraded three months after launch?"
• "What accuracy do you actually need, and how did you decide?"

Testing for practical constraint handling

Give a realistic constraint and see whether the approach genuinely changes. This is the closest thing to a live work sample you can run in an hour.

• "You have 200 labelled images and no budget for more. What do you do?" — transfer learning, augmentation, synthetic data, active learning, or arguing for a classical method.
• "This must run at 30fps on a Jetson Nano." — a good candidate reconsiders the architecture, not just the batch size.
• "The camera is being replaced with a different model next quarter." — should prompt domain shift and re-calibration concerns.
• "Half your training labels are wrong." — label auditing, confident learning, or relabelling a stratified sample.

Questions worth asking by role

The general questions above apply everywhere. These are the role-specific probes that reliably separate depth from familiarity.

• Perception: describe a time synchronisation or calibration bug you chased down.
• SLAM: what is the difference between SLAM and visual odometry, and when does your system lose tracking?
• 3D vision: why does a COLMAP reconstruction fail, and what do you change about the capture?
• Embedded: INT8 quantisation cost you three points of accuracy — what now?
• MLOps: your GPU cluster sits at 20% utilisation. Where do you start?

What to stop doing

Several common practices actively harm your ability to hire well in this field.

• Whiteboard implementation of backpropagation. It tests memorisation, not capability.
• Asking candidates to name architectures. The field moves; judgement does not.
• Take-home exercises longer than three hours. Strong candidates have options and will decline.
• Interviewing without anyone technical in the domain present. CV candidates can tell within minutes, and it costs you offers.

Common questions

More hiring guides