Computer Vision Engineer interview questions

I would keep video transport site-local and give event evidence priority over best-effort analytics.

• Two gateways per site terminate RTSP, normalize timestamps, and maintain a 30-minute NVMe ring sized from measured bitrate plus recovery headroom.
• The ring covers a 5-second WAN outage only while a gateway and its local storage remain healthy; gateway loss is handled by camera reconnect to its peer, not by the ring itself.
• Congestion reduces analysis from 15 to 5 FPS first, while confirmed clips have reserved space and upload priority; if that reserve fills, the service reports the oldest recoverable timestamp instead of claiming zero loss.
• Kafka metadata is replicated across three zones; monthly ingest availability must reach 99.95%, while clip checksums and p95 search indexing under 2 seconds are measured independently.

I would schedule an 80 ms nominal pipeline and reserve the remaining 20 ms for jitter and thermal variation.

• Capture and synchronization get 8 ms, preprocessing 12 ms, parallel camera and lidar inference 45 ms, fusion 10 ms, and tracking plus publication 5 ms, totaling 80 ms.
• CUDA streams overlap transfers and kernels, queues hold at most one cycle, and stale work is canceled rather than allowed to delay the next control update.
• A release campaign spans the full ODD, temperatures, sensor faults, and enough drive-hours for the one-sided 95% upper confidence bound on deadline-miss probability to meet the target; one 60-minute drive cannot establish it.
• After a defined number of consecutive misses, the stack publishes degraded health and the planner enters controlled degradation or a minimum-risk state instead of silently dropping frames forever.

I would combine controlled imaging with a two-stage detector and power acceptance from defective positives, not from total line volume.

• Four strobed global-shutter cameras keep motion blur below 0.2 mm, and a PLC trigger ties every view to one part identifier.
• The trial predefines positive counts for each critical defect type and production line; recall passes only when its one-sided 95% lower confidence bound is at least 99.5% in the required strata.
• Normal parts form a separate representative denominator for the false-reject rate, with repeated views of one part counted as one decision rather than independent samples.
• Uncertain parts are diverted to review, and line throughput is verified at 600 parts per minute without weakening either statistical test.

I would run a compute-matched comparison that exposes each backbone's long-context trade-off rather than forcing one image recipe onto all three.

• The 576 GPU-hours are split into 192 per family with the same train split, frame decoder, pretraining corpus, optimizer-search budget, and number of frames seen; seeds and failed runs still consume the allocation.
• A temporal convolutional model tests strong local motion bias, a windowed or sparse-attention transformer tests long-range interactions with controlled token growth, and a state-space model tests streaming 10-minute context with linear state and memory.
• All models see identical short, medium, and 10-minute duration slices, while sampling density is varied as a declared ablation rather than hidden extra compute.
• I choose from the quality, calibration, peak-memory, streaming-state, and target-GPU latency Pareto frontier, not from architecture name or image top-1 accuracy.

I would store immutable media in object storage and searchable manifests in versioned Iceberg tables.

• Objects use content hashes, while Parquet manifests carry camera, legal basis, label, checksum, and preprocessing metadata without bucket listing.
• Every training query pins an Iceberg snapshot ID, and the archive tier still retains original media for the full five years.
• Checksums are verified on write, sampled on read, and checked during replica repair; the acceptance claim is zero undetected corruptions in the defined audit, not an unverifiable per-billion-read guarantee.
• Restore drills rebuild a pinned dataset from an archived replica and verify every object digest within the 30-minute manifest-resolution objective.

I would define an edit as durable only after a server acknowledgment and keep unacknowledged operations in a client-side write-ahead log.

• Each box operation is appended to IndexedDB with an idempotency key before the UI marks it pending; 10-second autosave batches transport but is not the durability boundary.
• PostgreSQL commits the operation against a monotonic task revision and returns the accepted revision, after which the client removes it from the local log.
• On reconnect or browser restart, pending operations replay idempotently; a stale base revision creates a review branch instead of overwriting another annotator.
• Failure tests require no loss of acknowledged edits, while load tests sustain 250 sessions, p95 task load below 2 seconds, and 120,000 accepted boxes per day; the UI states the remaining risk for local edits on a destroyed device.

I would combine hidden gold tasks, controlled overlap, and adjudication, but score classes and boxes with metrics that expose chance agreement and missing annotations.

• Five percent of tasks are refreshed hidden gold examples, and 10% are independently double-labeled.
• Class labels must retain the required 0.95 raw agreement, but acceptance also reports Cohen's kappa plus class-specific precision and recall because dominant classes can inflate agreement.
• Boxes are matched once with a declared class-aware IoU assignment; the required 0.85 overlap is accompanied by the IoU distribution, unmatched ground-truth recall, and extra-box precision instead of only a median.
• Rolling failures pause a labeler for calibrated retraining, while frequently disputed gold items go to senior adjudication rather than penalizing the workforce.

I would make evaluation a versioned batch job keyed by model digest, dataset snapshot, metric package, and slice commit.

• Ray workers write per-example predictions once, so 300 slices reuse one inference pass and deterministic example IDs.
• Metric aggregation uses a fixed ordering and stable reduction; identical digests should reproduce exact report values unless a documented nondeterministic kernel is unavoidable.
• Any allowed numeric envelope is metric-specific, such as 0.01 percentage points of recall rather than an undefined 0.01, and release slices include confidence intervals.
• Continuous integration reruns a fixed subset across worker counts to catch reduction-order or shard-boundary changes before the two-hour full suite.

I would use an MLflow-compatible registry over immutable artifacts and require a signed lineage manifest per version.

• The manifest links Git commit, container digest, training config, dataset snapshots, preprocessing contract, evaluation report, and parent checkpoint.
• Promotion from candidate to validated to production needs service identity and two approvals; artifacts are never overwritten.
• A prediction_id must return exact model and data lineage within five minutes, with 100% coverage verified daily.

I would reserve a bounded interactive service class and admit only the concurrency that its eight GPUs can actually start within 10 minutes.

• Each team gets a quota and at most one two-GPU interactive job in the protected class; excess submissions receive a queue estimate instead of inheriting the start-time guarantee.
• The other 56 GPUs run gang-scheduled batch work with fair-share and backfill, and idle batch capacity may be borrowed by interactive jobs through preemption checkpoints.
• Dataset manifests stage to node-local NVMe, while topology-aware placement avoids splitting multi-GPU jobs across slow links.
• Admitted jobs must keep p95 start below 10 minutes and monthly useful utilization above 75%; rejection and quota-wait rates prevent high utilization from hiding unmet demand.

I would use elastic workers with a committed sharded checkpoint every 15 minutes and measure compute loss separately from replacement time.

• Each rank writes a temporary shard, and rank zero publishes the generation only after all checksums arrive, so a failure loses at most one checkpoint interval of compute.
• The checkpoint includes global step, optimizer, RNG, dataloader sampler epoch and cursor, and dataset manifest, preventing skipped or repeated samples after reshuffling.
• Scheduler replacement may add about 10 minutes of downtime, but it does not change the 15-minute recovery point objective; both numbers appear separately in incident reports.
• Chaos runs compare the resumed and uninterrupted validation curve at the same global steps with a metric-specific tolerance and confidence interval, not a generic 0.1% divergence.

I would keep bytes inside their residency boundary and route immutable references through a regional asynchronous state machine.

• Regional ingest writes each image under a content digest and object version, then enqueues region, tenant, model, preprocessing digest, and the immutable object reference instead of copying image bytes through a global bus.
• The global control plane may route metadata, but policy admits work only to an allowed regional queue; workers receive short-lived read capability for that exact object version, so European media cannot be fetched from the US.
• An idempotency key over tenant, object version, model, and preprocessing makes at-least-once delivery safe, while a leased state transition and conditional result write publish only one terminal prediction.
• If a regional worker pool fails, jobs wait or move to another pool inside the same legal boundary; queue age, expired jobs, dead letters, and cancellation are visible outcomes rather than synchronous error masking.

I would use a pull-based signed updater, hardware-targeted manifests, and A/B model partitions.

• Devices poll a CDN with jitter, verify model and runtime signatures, check free storage, install to the inactive partition, and pass a hardware-specific self-test before switching.
• Rollout advances through lab, 1%, 10%, 50%, and 100% cohorts only when install, signature, storage, self-test, crash, and latency failure rates remain within their declared budgets.
• Completion is calculated over devices that were online and reachable during the 24-hour window; offline, policy-blocked, and unsupported cohorts are reported separately rather than counted as successful.
• The target is 99% completion among eligible devices within 24 hours and under 0.5% failed install attempts; a failed device switches back locally and reconciles desired and observed versions on reconnect.

I would split at a versioned intermediate representation only after proving that its privacy and bandwidth costs beat local inference.

• An edge encoder processes raw frames and emits a compressed feature tensor; measurements choose the split layer because early features are larger and more invertible, while late features may discard detail needed by the cloud head.
• Privacy review tests feature inversion, membership leakage, and cross-tenant linkage, then pins encryption, retention, access, encoder digest, tensor schema, and approved compression level.
• The cloud accepts only a compatible encoder and head pair, and the edge adapts feature quantization or sampling to a per-store bandwidth budget without changing the contract silently.
• When bandwidth or compatibility fails, the complete local model returns a labeled degraded result; raw pixels are never uploaded and queued features expire instead of replaying stale decisions.

I would place a calibrated CPU or small-GPU filter first and route ambiguous samples to the expensive detector.

• The first stage is tuned to 99.7% recall and removes only obvious negatives below confidence 0.05, targeting 70% early exits.
• The second stage handles positives and the uncertainty band; final thresholds use traffic-weighted slices rather than a balanced lab set.
• Ship only at 98% end-to-end recall, no critical slice losing over 0.3 points, p99 below 100 ms, and measured GPU-hours down at least 50%.

With standard Triton, I would use bounded dynamic batching and isolate traffic classes rather than claim EDF scheduling it does not provide.

• The interactive deployment sets max_batch_size 32, preferred_batch_size 8, 16, and 32, and max_queue_delay_microseconds 4000; preferred sizes are hints, while the maximum is enforced by max_batch_size.
• Triton priority levels and queue timeout policy can reject requests that wait too long, but the standard dynamic batcher does not dispatch from per-request absolute deadlines or when the oldest request has exactly 8 ms left.
• Bulk traffic uses a separately named model deployment with its own model config, queue, and proven max batch of 64; adding instance groups to one model would not create traffic-class queues.
• If EDF is required, I would explicitly place a custom scheduler or backend before Triton and test it at 1,000, 6,000, and 12,000 FPS while requiring end-to-end p99 below 100 ms.

I would size from sustained per-GPU throughput at the latency SLO and hold enough warm capacity for both the daily peak and a zone loss.

• At 300 FPS per L4, the 60,000 FPS peak needs 200 GPUs at 100% measured capacity.
• Capping post-failure utilization at 80% requires 60,000 divided by 300 times 0.8, or 250 surviving GPUs.
• With three equal zones, each zone therefore holds 125 GPUs and the fleet holds 375; losing one leaves the required 250 rather than a pool already at 100%.
• Forecast autoscaling may reduce active replicas only if reservations and startup time still meet that failure envelope; otherwise overload enters an explicit admission or load-shed mode.

I would profile memory and latency first, then isolate critical models on supported MIG profiles of a named GPU rather than schedule abstract slices.

• On 16 A100 40 GB GPUs, for example, a critical model with measured 14 GB peak memory can fit a 3g.20gb profile with headroom; a model that does not fit gets a full GPU.
• The NVIDIA Kubernetes device plugin advertises MIG resources, placement pins one Triton critical instance to its slice, and admission rejects an instance count that exceeds the profiled memory envelope.
• Long-tail models use separate full GPUs or compatible smaller profiles with weighted queues and unloading after idle periods.
• Noisy-neighbor tests cover the exact MIG layout, input shapes, Triton instance groups, and concurrent memory peak, requiring critical p99 below 80 ms and long-tail p99 below 500 ms.

I would version preprocessing as a declarative contract and validate each runtime at the stage where differences are meaningful.

• Decoder semantics, EXIF orientation, color order, resize geometry, padding, normalization, layout, dtype, and rounding are pinned by digest.
• Metadata and coordinate transforms must match exactly, while FP32 tensors use a tight numeric tolerance derived from golden fixtures rather than a universal constant.
• FP16 and INT8 runtimes get dtype-aware tensor bounds plus decision-level parity for boxes, masks, classes, and NMS around the operating threshold.
• A contract change creates a new version and either retrains the model or supplies explicit compatibility evidence for every target runtime.

I would keep the matrix at one engine per model, target stack, and precision, with several optimization profiles inside an engine when they share a safe memory envelope.

• For TensorRT 10 INT8, the exported graph carries explicit Q/DQ nodes; quantization scales or the calibration artifact are derived from a representative dataset and pinned by dataset and graph digests, not recalibrated merely because the GPU SKU changed.
• Engines are built and benchmarked for the exact target stack: T4, L4, A10, or Orin compute capability, OS or JetPack, CUDA, TensorRT, plugins, tactic policy, and allowed shapes.
• One serialized engine can contain multiple optimization profiles; I choose three for the expected small, medium, and large shape ranges, and split engines only when startup, memory, or tactic performance justifies it.
• Validation covers every profile boundary, output quality at its precision, engine deserialization on the target, peak memory, and latency rather than promising cross-stack portability.