CrackML by @ml.with.umang
Interview questions / ML Fundamentals
ML Fundamentals interview question

Evaluate a Computer Vision Model

How would you evaluate a production computer-vision classifier beyond overall accuracy?

mediumconceptEvidence 34/1001 source reportAmazon

The 60-second answer

Choose metrics from the product error cost: class-wise precision/recall/F1, ROC/PR curves, calibration, top-k accuracy, or detection-specific metrics as appropriate. Build meaningful slices across lighting, camera/device, geography, demographic or object subgroups, rare classes, and image quality.

Build the answer in this order

1
Give the core idea

Choose metrics from the product error cost: class-wise precision/recall/F1, ROC/PR curves, calibration, top-k accuracy, or detection-specific metrics as appropriate.

2
Explain how it works

Build meaningful slices across lighting, camera/device, geography, demographic or object subgroups, rare classes, and image quality.

3
Compare alternatives

Inspect confusion matrices and hard examples to distinguish label problems, distribution shift, and model confusion.

4
State failure modes + validation

Validate robustness, latency/memory, and online outcomes; keep a stable golden set plus recent-data evaluation.

A useful interview mental model

This is the shape of a strong answer—not a script to memorize.

01Definition
02Mechanism
03Trade-offs
04Failure modes
05When to use

Senior-level signal

  • Senior answers discuss dataset shift and annotation quality as first-class evaluation risks.
  • Include confidence calibration and abstention/human-review policy when mistakes have asymmetric cost.

What the interviewer is really testing

Mechanistic understanding, assumptions, trade-offs, and whether you can turn a definition into a model decision.

Likely follow-up questions

What assumption makes this approach work?
When would you choose the strongest alternative instead?
What production or data failure mode changes your answer?

Common weak-answer patterns

  • Reciting a definition without mechanism or assumptions.
  • Claiming one technique is always better without a data regime.
  • Stopping before failure modes, validation, or deployment implications.