11 Snap AR Engineer (New Grad) Interview Questions (2026)

Outline

Pick ONE project (a lens, a face-tracking demo, a small WebGL game, a CV pipeline). Cover: what you built, the performance budget, the design choices you made for real-time, what you'd do differently. Have numbers — frame rate, latency, model size. AR engineering is performance engineering; surface-level descriptions get caught fast.

Outline

Tie to a specific product surface: Lenses (consumer), Lens Studio (creator tools), Spectacles (hardware), or the camera platform. Mention a lens you noticed or a Lens Studio tutorial you tried. Generic 'AR is the future' answers signal you only applied for the buzzword.

Outline

STAR. Pick a real moment — squeezing a CV model from 50ms to 16ms per frame, reducing memory allocations in a hot loop, moving work from CPU to GPU. Cover how you measured (profiler use is real signal), the change you made, the result. 'I rewrote it in C++' is not the answer they want — show methodical work.

Outline

STAR. Snap's AR org pairs engineers with 3D artists and designers for lenses. Pick a moment where you bridged a gap — explaining a technical constraint without being condescending, suggesting an alternative that preserved the creative intent. Strong AR engineers communicate well with artists.

Outline

Exponential moving average is the simplest: out = alpha * new + (1 - alpha) * prev. Larger alpha = more responsive, more jitter. Smaller alpha = smoother, more lag. Discuss the one-euro filter as an adaptive alternative (more smoothing at low speed, less at high). Walk through the tradeoff visually — this is the bread and butter of lens engineering.

Outline

Least squares closed form: slope = cov(x,y) / var(x), intercept = mean(y) - slope * mean(x). Walk through the formula derivation briefly. For robustness to outliers, mention RANSAC — sample two points, fit, count inliers, repeat. Edge cases: vertical line (var(x) = 0).

Outline

Camera frame → detection (find face bounding box, often a lightweight model) → landmarks (key points like eye corners, nose tip) → pose estimation (translate to 3D rotation/translation). Discuss the budget: detection is the most expensive, so you may run it every N frames and track between. Mention the smoothing step (Kalman or one-euro filter) to avoid jitter.

Outline

Multiply world point by view matrix (camera transform) to get camera space, then by projection matrix to get clip space. Perspective divide by w to get NDC. Map NDC to screen pixels. Walk through the matrix shapes (4x4 homogeneous coords) and what each step does geometrically. Mention the depth value (z) is preserved for occlusion testing.

Outline

Translation is the last column. Scale is the length of each of the first three column vectors. Rotation is the upper-left 3x3 normalized by removing the scale. Discuss why decomposition can fail (negative scale, shear). Mention quaternions as the preferred rotation representation in pipelines for interpolation.

Outline

Concept-level. Model: quantized, mobile-optimized, runs on GPU or NPU when available. Pipeline: frame buffer pool, async inference, double-buffering between capture and process. Discuss the budget: 33ms per frame total, ~10-15ms for inference, rest for pre/post-processing and rendering. Mention thermal throttling and what happens when the device gets warm.

Outline

Need a depth signal for the real world: stereo cameras, a depth sensor, or monocular depth from an ML model. Per-pixel, compare the virtual object's depth at that pixel to the world depth; if world is closer, don't render. Discuss the quality tradeoffs: stereo is geometric and accurate but limited to baseline; ML depth is dense but noisy. Mention edge handling — most occlusion artifacts live at object boundaries.