Interview for Machine Learning

Tag: Model

MSD0060 RLHF Alignment Pipeline
Design an RLHF alignment pipeline for aligning a large language model with human preferences. A foundation model team must align a model so that it follows instructions, refuses harmful requests, and produces helpful, harmless, and honest responses.
The alignment must use reinforcement learning from human feedback, but the team must choose between PPO (Proximal Policy Optimization), GRPO (Group Relative Policy Optimization), and GSPO (Group Sequence Policy Optimization) as the alignment algorithm. Each has different sample efficiency, training stability, and compute requirements. The system must train a reward model from human preference data, run the alignment loop at scale on a distributed cluster, and produce a model that passes safety evaluations while keeping its capability.
How would you design this system? Cover the reward modeling architecture, the candidate RL algorithms (PPO vs GRPO vs GSPO) and their trade-offs, how you handle reward hacking and mode collapse, how you distribute the alignment training across GPUs, and how you evaluate alignment quality.

The Problem: humans can only tell you which of two whole responses they prefer, but gradient descent needs a scalar objective and a stable update signal at every token of every rollout.
Answer
The stack is the standard three stages: an instruction-tuned SFT checkpoint, a Bradley-Terry reward model trained on human preference pairs, and an on-policy RL loop that maximizes reward minus a KL penalty against the frozen SFT reference. Everything above the update rule is shared, so the real design question is the RL objective. PPO learns a separate value network to supply per-token baselines, while GRPO and GSPO delete the critic and use the mean reward of a group of sampled responses instead, removing one trainable model copy from memory. GSPO goes further and computes the importance ratio at the sequence level, matching the granularity of the reward itself, which is what keeps training stable on MoE policies and long rollouts. My default is group-relative advantages with a sequence-level ratio, a KL anchor plus reward-model ensembling to hold back reward hacking, and PPO kept in reserve only where a dense token-level value estimate genuinely earns its extra trainable model.
(1) Shared Substrate: SFT policy, preference-trained reward model, and a frozen reference for the KL anchor; all three candidates optimize the same penalized reward.
(2) PPO: actor-critic; a learned value network produces per-token advantages through GAE, and the importance ratio is clipped once per token.
(3) GRPO: no critic; sample $G$ responses per prompt and standardize their rewards into one advantage per response, still clipped per token.
(4) GSPO: same group baseline, but the importance ratio and the clip act on the whole length-normalized sequence, matching the sequence-level reward.

Figure 1: One alignment loop: preferences train the reward model, reward minus a KL anchor scores group rollouts, and only the update box changes between PPO, GRPO, and GSPO.
Clarify Before Designing:
(1) Policy Architecture: dense or sparse MoE, and at what size? Routing volatility in MoE is the single strongest argument for a sequence-level ratio.
(2) Reward Source: learned reward model only, or are parts of the traffic verifiable (unit tests, math checkers, format rules) so a rule-based reward can replace the model?
(3) Sequence Length: 1k-token chat replies or 32k-token reasoning traces? Long rollouts multiply token-level ratio variance and dominate step time.
(4) Compute Budget: how many GPUs, and does a second trainable critic-sized model fit next to the policy after sharding?
(5) Preference Data: how many pairs exist, what is the annotator agreement rate, and is there a recurring human evaluation loop or only an LLM judge?
(6) Release Bar: what refusal rate on red-team prompts and what maximum capability regression (the alignment tax) gate the release?
Login to view more content
September 10, 2026
MSD0049 Google Related Searches
When a user enters a query on Google, the search results page shows a list of “related searches” at the bottom: queries that other users have issued in the same session, or queries that are semantically close to the original. These suggestions help users refine their intent, discover alternative phrasings, and navigate to adjacent topics, and they drive a significant fraction of query reformulations. Generating them at scale requires a deep embedding model that maps queries into a semantic space where nearby queries are related, plus a retrieval mechanism that can surface the best candidates from billions of historical queries in milliseconds. The model must handle the long tail of rare queries that have little or no co-occurrence history, distinguish genuinely related queries from merely popular ones, and avoid suggesting queries that lead to harmful or policy-violating content.
How would you design this model? Cover the candidate embedding architectures (dual-encoder trained on query co-occurrence vs contrastive learning on query-query pairs vs LLM-based query expansion), how you build the retrieval index over billions of queries, how you handle the long tail of rare and unseen queries, how you filter harmful or policy-violating suggestions, and how you evaluate related-search quality (click-through rate, reformulation success rate, relevance judgments).

The Problem: billions of past queries could fill the three empty slots under the results, most of them were typed only once, some of them should never be shown, and the choice must be made in a few milliseconds.
Answer
The design is a contrastive query encoder: a BERT-base transformer (110M, 256-d output projection) trained with InfoNCE on query-query pairs harvested from session reformulations and same-click queries, using in-batch negatives plus mined hard negatives and a logQ popularity correction so that cosine similarity means “related” rather than “popular”. Every historical query is embedded once offline into an approximate nearest-neighbor index, and at serve time the live query is encoded and its neighbors are pulled out and filtered. LLM query expansion is deliberately not the online model. It runs offline to synthesize and relabel training pairs and to generate grounded candidates for tail queries that have no usable neighbors. The two pivotal decisions are to train on semantic pairs with explicit popularity debiasing instead of factorizing raw co-occurrence counts, and to keep the LLM offline and grounded so that every displayed suggestion is a real, auditable query.
(1) Dual-Encoder on Co-occurrence: two towers whose training target is the session co-occurrence matrix; a sampled softmax predicts the next or co-session query, which effectively factorizes the count matrix into embeddings.
(2) Contrastive Query-Query Encoder: one shared transformer trained with InfoNCE on curated positive pairs (reformulations, same-click queries, paraphrases), in-batch and mined hard negatives, a temperature, and a logQ correction; retrieval is cosine k-NN over the index.
(3) LLM-Based Query Expansion: a generative model writes related queries directly from the query text, or synthesizes and labels pairs for distillation; generated strings are snapped to real historical queries before use.

Figure 1: The contrastive query encoder is trained once on pairs, embeds the whole historical corpus offline, and serves each live query with one cheap forward pass plus a nearest-neighbor lookup.
Clarify Before Designing:
(1) Candidate Pool: must every suggestion be a real historical query (grounded, auditable), or may the system show generated strings nobody has typed?
(2) Latency and Compute Budget: how many milliseconds and FLOPs per query for encode plus retrieve, and may head queries be precomputed and cached?
(3) Training Signal: which logs exist at what volume: session reformulations, same-click query pairs, human relevance judgments; how many languages?
(4) Definition of Related: refinements, broadenings, lateral topics, or all three, and how much diversity is wanted versus precision?
(5) Tail Share: what fraction of distinct queries and of traffic is seen fewer than a handful of times, and must those queries receive suggestions or is an empty slot acceptable?
(6) Safety Bar: which policy categories apply (health misinformation, harassment, adult content, queries about private individuals), and is any false negative tolerable?
Login to view more content
September 8, 2026
MSD0048 Duolingo Story Difficulty Recommender
Duolingo wants to recommend stories of increasing difficulty as a student learns a language. The app has a library of short reading passages across multiple languages, each with a CEFR level (A1 to C2), and it must serve each learner a story that stretches them just past what they can already read comfortably — challenging enough to push growth but not so hard that the learner gives up. The core challenge is measuring story difficulty and learner ability jointly: a story’s difficulty depends on vocabulary frequency, grammar complexity, sentence length, and concreteness, while a learner’s ability depends on which words and grammar they have mastered so far. Deep knowledge tracing (DKT) can model a learner’s evolving knowledge state from their exercise interactions (correct/wrong, hints used, time spent), and this state can be matched against story difficulty estimates to pick the next story.
How would you design this model? Cover the candidate knowledge tracing architectures (deep knowledge tracing with recurrent networks vs transformer-based knowledge tracing vs item response theory enhanced with neural features), how you estimate story difficulty from text features and historical learner performance, how you combine the learner state with story difficulty to produce a recommendation score, how you handle cold start for new stories and new learners, and how you evaluate recommendation quality beyond simple accuracy.

The Problem: the shelf is sorted by CEFR level, but the learner is not a CEFR level. Which story is one step past what this particular learner can already read, and how would a model know?
Answer
The design is an attention-based knowledge tracer with an IRT-shaped head. A causal transformer reads the learner’s interaction history (which exercise, correct or not, hints used, response time) and emits two outputs: a scalar ability $\theta_t$ on a logit scale and a per-skill mastery vector over the words and grammar points the course teaches. Each story is placed on the same logit scale with a difficulty $\beta_s$ that starts from text features (vocabulary frequency, sentence length, clause depth, concreteness) and is then calibrated on historical learner outcomes. The recommendation score is the predicted comprehension probability $\sigma(\theta_t - \beta_s)$ pulled toward a target band of 0.70 to 0.85, plus a bonus for stories whose skills sit in the learner’s learning zone. The two pivotal decisions are to put ability and difficulty on one shared scale, so a brand-new story can be placed from its text alone, and to window the attention so the per-request cost stays flat as histories grow.
(1) DKT With Recurrent Networks: an LSTM consumes embeddings of (skill, correctness, hint, time) per interaction; its hidden state is the knowledge state and a sigmoid layer reads out per-skill mastery.
(2) Transformer Knowledge Tracing: SAKT, SAINT, or AKT-style causal attention in which the next item queries the interaction history; a distance-aware decay supplies recency and Rasch-style item embeddings supply a difficulty scale.
(3) IRT Enhanced With Neural Features: the Rasch logistic $\sigma(\theta - \beta)$ stays as the output model, while neural front-ends estimate $\theta_t$ from history and $\beta_s$ from story text (Deep-IRT, knowledge tracing machines).

Figure 1: Two estimators on one logit scale: the learner side traces ability and mastery from interactions, the story side places difficulty from text and outcomes, and the match picks the story whose predicted comprehension lands in the target zone.
Clarify Before Designing:
(1) Skill Granularity: is mastery tracked over individual words (thousands per course) or over grammar concepts and word families (hundreds)? This sets the output width and how sparse each skill’s evidence is.
(2) History Length: how many interactions does an active learner accumulate, hundreds or tens of thousands, and must the model attend to all of it or only a recent window?
(3) Inference Budget: is the learner state updated online after every exercise on a CPU budget of a few milliseconds, or recomputed in a nightly batch?
(4) Outcome Signal: do stories carry comprehension checks, or only completion and abandonment, and are hints and response times logged reliably enough to be features?
(5) Per-Language Data: how many learners does the smallest course have, since that number decides whether a transformer is even trainable there?
(6) Difficulty Ground Truth: are the editorial CEFR tags labels the model must respect, or priors it may revise from learner outcomes?
Login to view more content
September 8, 2026
MSD0046 Multi-Camera Tracking Surveillance
Design a multi-camera vehicle and person tracking engine that fuses feeds from dozens of overlapping cameras across a campus, parking lot, or city intersection into a unified, persistent track for every vehicle and pedestrian. Each camera sees only a partial view: objects enter and leave frames, get occluded by each other and by structures, change appearance across lighting and weather, and must be handed off from one camera to the next as they cross camera boundaries.
The engine must run in real time across all cameras, maintain consistent global IDs across views (the same car is ID 42 in camera 3 and camera 7), recover from occlusions and re-identification failures, and scale to hundreds of cameras without linearly growing compute.
How would you design this model? Cover the candidate multi-object tracking architectures (per-camera tracking plus cross-camera re-identification, joint multi-camera tracking, tracking-by-detection with a global association layer), the re-identification feature design and how it survives viewpoint and lighting change, the cross-camera handoff and global ID assignment strategy, how you handle occlusion and track fragmentation, and how you scale inference across many cameras.

The Problem: every camera invents its own local track ID, and the same vehicle looks different in every view. The model’s job is to decide which local tracks are one object and keep that decision stable for hours.
Answer
The design is tracking-by-detection with a two-tier association: a cheap per-camera tracker turns detections into short, high-purity tracklets, and one global association layer stitches tracklets from all cameras into persistent global IDs. Two decisions are pivotal. First, associate at the tracklet level, not the detection level, which shrinks the matching problem by one to two orders of magnitude and gives ReID a multi-frame embedding instead of one blurry crop. Second, gate every candidate pair through a camera-topology graph with travel-time feasibility, so cost grows linearly in cameras rather than quadratically. Geometric bird’s-eye-view fusion is used only where calibrated overlap actually exists, because most real deployments are mostly non-overlapping.
(1) Per-Camera Tracking + Cross-Camera ReID: independent ByteTrack-style Kalman and IoU trackers per camera, then match tracklets across cameras by appearance embedding against a rolling gallery.
(2) Joint Multi-Camera Tracking (BEV): project detections or features onto a shared ground plane through calibrated homographies, fuse them into one occupancy map, and track once in world coordinates.
(3) Tracking-by-Detection + Global Association Layer: keep per-camera tracklets, then solve one hierarchical graph association over all cameras with learned edge costs combining appearance, motion, and topology priors.
(4) Chosen Hybrid: approach (3) as the backbone, borrowing (1)’s tracklet-level ReID features and switching to (2)’s geometric fusion inside the few genuinely overlapping camera clusters.

Figure 1: One cheap tracker per camera, one global association layer for the whole site, and a stored ID book so a returning object reclaims its old identity instead of getting a new one.
Clarify Before Designing:
(1) Calibration and Overlap: do we have intrinsics and extrinsics per camera, and what fraction of camera pairs actually share ground-plane coverage?
(2) Latency Mode: is this live tracking with a sub-second budget, or forensic review where a few seconds of buffering (and thus batch graph solving) is allowed?
(3) Scale and Input Size: how many cameras, at what resolution and frame rate, and can we drop to 10 fps for detection?
(4) Identity Duration: must an ID survive a 90 second walk between two non-overlapping cameras, or only a handoff across an overlapping seam?
(5) Metric and Conditions: are we scored on IDF1 or HOTA, and does the deployment include night, rain, and fleet vehicles that look identical?
Login to view more content
September 3, 2026
MSD0041 Fitness Pose Estimation
Design a deep learning model for real-time pose estimation in a fitness app that counts reps, corrects exercise form, and runs on a phone. The app uses the phone’s front camera to track the user’s body keypoints (shoulders, elbows, wrists, hips, knees, ankles) while they perform squats, push-ups, and yoga poses.
The model must estimate 2D or 3D pose at 30 fps on-device, recognize which exercise is being performed, count repetitions by detecting the movement cycle, and flag form errors such as knees caving inward during a squat or a back rounding during a deadlift. It has to work across body types, clothing, camera angles, and lighting, and latency must stay low enough for real-time audio feedback.
How would you design this model? Cover the candidate pose estimation architectures (heatmap regression vs direct coordinate regression vs 3D lifting from 2D), the exercise classification and rep counting logic, the form-error detection mechanism, the on-device deployment strategy (quantization, distillation), and how you evaluate pose accuracy and rep-counting reliability.

The Problem: one lens, no depth, and a 33 ms per frame budget, yet every frame must answer three questions at once: where the joints are, where in the rep cycle the body is, and whether the form is safe.
Answer
Run a detector-tracker cascade around a single-person 2D keypoint network whose output head is a coordinate classifier (SimCC-style 1D bins per axis), trained with dense heatmap supervision and distilled from a large teacher. The scale-normalized keypoint sequence then feeds one small temporal head that emits the exercise label, the rep phase, and the form flags. 2D stays the primary signal because monocular depth is ambiguous, and a 27-frame 2D-to-3D lifting head is switched on only for errors that genuinely need depth, such as back rounding or knee valgus seen from an oblique angle. Two decisions carry the design: put the spatial prior in training (heatmaps) while keeping the cheap output at inference (coordinates), and treat rep counting as hysteresis on a phase signal rather than peak-picking on a raw joint angle.
(1) Heatmap Regression: the backbone emits one $H/4 \times W/4$ map per joint, and the joint location is the argmax cell plus a learned sub-pixel offset; strong spatial inductive bias, heavy output tensor.
(2) Direct Coordinate Regression: the head emits $2K$ numbers directly, or classifies each axis into 1D bins (SimCC); tiny output, no argmax, needs heatmap-style supervision or bin targets during training to localize well.
(3) 3D Lifting From 2D: a temporal network consumes a window of 2D keypoints and predicts root-relative 3D joints; it recovers depth-dependent form errors but inherits every 2D error and adds window latency.

Figure 1: One cheap keypoint pass per frame; everything the product actually says out loud is computed from the buffered keypoint sequence, not from raw pixels.
Clarify Before Designing:
(1) Depth Requirement: which form errors are in scope, and can any of them only be judged from depth (back rounding, hip hinge) rather than from an in-plane 2D ratio?
(2) Compute Budget: what is the target device tier, and how much of the 33 ms frame budget is already spent by camera capture, rendering, and audio?
(3) Framing Control: is the phone propped up with the whole body in view, or handheld with limbs leaving the frame; can the app force a calibration pose first?
(4) Exercise Vocabulary: a closed set of 20 named movements, or open-set counting for anything the user does?
(5) Label Availability: do we have keypoint labels on fitness footage (not just COCO street photos), and do we have per-rep form-error labels from coaches?
(6) Teacher Access: can we run a large server-side pose model offline to generate pseudo-labels and distillation targets?
Login to view more content
September 3, 2026
MSD0040 Automated Retail Checkout
Design a deep learning model for a retail store’s automated checkout system that recognizes items from camera feeds and computes totals without barcode scanning. A customer places items on a counter or walks through a gate, overhead and angled cameras capture the items, and the system must identify each product, count multiples, handle occlusion and stacked items, distinguish similar-looking products (two flavors of the same brand), and produce a receipt in seconds.
The system must handle a large product catalog (thousands of SKUs) that changes as inventory rotates, work under varying lighting and camera angles, and keep the error rate low enough that manual corrections are rare.
How would you design this model? Cover the candidate recognition architectures (object detection vs instance segmentation vs metric-learning retrieval against a product catalog), how you handle the large and rotating SKU catalog, how you count multiples and handle occlusion, how you generate training data for new products with few examples, and how you calibrate confidence to flag uncertain items for manual review.

The Problem: the catalog is huge and rotates weekly, the items overlap and stack, and two flavors of the same brand differ by a color band. The model has seconds to turn pixels into an exact receipt.
Answer
Split the problem into localization and identity, and keep identity out of the network weights. A class-agnostic instance segmenter finds every item instance and its mask, a crop encoder trained with a metric-learning loss maps each instance to a unit embedding, and the SKU is decided by cosine nearest-neighbor search against a catalog index of enrolled prototypes. This makes catalog rotation an indexing operation rather than a retraining project, since a new product needs about 20 enrollment crops and no weight update. Masks (not boxes) drive multiple-instance counting under occlusion, counts are fused across the overhead and angled views, and a calibrated margin gate abstains on ambiguous items so the review lane sees only the genuinely hard ones.
(1) Closed-Set Object Detection: one detector with a $K$ -way softmax head over all SKUs; fastest single pass, but the catalog is baked into the weights.
(2) Instance Segmentation With A Class Head: per-item masks give reliable separation of touching and stacked products, but identity still lives in a fixed classifier.
(3) Class-Agnostic Localization Plus Metric-Learning Retrieval: the chosen design; localization is SKU-independent and identity is a nearest-prototype lookup in an index that can be edited nightly.
(4) Open-Vocabulary Detection With Text Prompts: zero-shot on new categories, but it cannot separate two flavors of one brand, so it serves only as a proposal generator or a cold-start fallback.

Figure 1: Localize anything, then look it up: frames → masks → embeddings → catalog index → fused counts → gate. New SKUs enter through the index, never through the weights.
Clarify Before Designing:
(1) Catalog Shape: how many SKUs, how many are added or retired per week, and how many are near-duplicates within a brand family?
(2) Compute Budget: edge box per lane or shared server GPU, and what is the wall-clock budget from last item placed to receipt shown?
(3) Camera Geometry: fixed calibrated overhead plus angled views on a static counter, or a gate where items must be tracked while moving?
(4) Enrollment Data: does the retailer already supply studio packshots per SKU, and can we photograph new products before they reach the shelf?
(5) Error Asymmetry: what is the cost of an undercount (shrinkage) versus an overcharge (trust), and what per-basket review rate is acceptable?
(6) Presentation Rules: may the interface ask the customer to spread items out, or must the model handle arbitrary piles?
Login to view more content
September 3, 2026
MSD0039 Landmark Recognition Travel
Design a landmark recognition model for a travel app that identifies famous landmarks from user photos and returns relevant historical and visitor information. When a traveler points their phone at the Eiffel Tower, the Colosseum, or a lesser-known temple, the model must identify the landmark in seconds, even from unusual angles, partial occlusion, varying lighting, or when the photo is taken from inside rather than the iconic exterior view.
The system must handle the long tail of tens of thousands of landmarks worldwide, many with only a handful of reference images, and it must gracefully say “I don’t recognize this” rather than confidently misidentifying a similar-looking building.
How would you design this model? Cover the candidate recognition approaches (global descriptor retrieval vs local-feature matching vs deep metric learning with classification), how you handle the long tail of rare landmarks with few training images, how you build the reference index, how you calibrate confidence to enable abstention, and how you evaluate recognition accuracy and false-positive rate.

The Problem: the query is rarely the postcard view, the tail landmark has a handful of reference photos, and a confident wrong name costs more trust than an honest “not sure”.
Answer
Treat this as open-set instance retrieval with abstention, not 100k-way classification. A backbone trained with a margin-based classification loss (ArcFace with sub-centers) produces a compact global descriptor; that descriptor retrieves top candidates from an ANN index over all reference photos; local-feature matching with geometric verification re-ranks those candidates and produces an inlier count. The two pivotal decisions are to keep the final decision in the index rather than in a softmax head, so a new temple is added by indexing seven photos instead of retraining, and to build the confidence signal from geometric inliers plus descriptor margin rather than softmax probability, because that is what makes a calibrated “I don’t recognize this” possible.
(1) Global Descriptor Retrieval: GeM-pooled CNN or ViT embedding, PCA-whitened to 512-d, searched with IVF-PQ over every reference image; fast, memory-light, viewpoint-sensitive.
(2) Local Feature Matching: keypoints and descriptors (DELF, SuperPoint) matched pairwise, then RANSAC for a consistent transform; the inlier count is both the score and the explanation.
(3) Deep Metric Learning With Classification Head: train with ArcFace or sub-center ArcFace over the landmark ID vocabulary, discard the head at inference and keep the embedding for retrieval.
(4) Chosen Hybrid: (3) trains the descriptor, (1) does the cheap recall, (2) verifies the top 100, and a calibrated gate over inliers and margin decides answer versus abstain.

Figure 1: Cheap recall first, expensive verification second, and an explicit gate that is allowed to answer nothing.
Clarify Before Designing:
(1) Inventory And Reference Depth: how many landmarks, and what is the reference-count distribution (median photos per landmark, how many with fewer than 10)?
(2) Compute Budget: server-side with a 1 s budget, or on-device with a fixed memory ceiling and no index round trip?
(3) Metadata: is GPS or EXIF available at query time? A 5 km geo prefilter removes most look-alike confusions for free.
(4) Cost Asymmetry: what precision floor does the product require, and what abstention rate is acceptable to hit it?
(5) Definition Of Recognized: do interiors, statues, details, and reconstructions count as the same landmark, and how are near-identical siblings (replicas, chain temples) labeled?
(6) Data Rights: can web-mined and user-submitted photos enter the index, and can queries be logged for hard-negative mining?
Login to view more content
September 3, 2026
MSD0038 LinkedIn PYMK GNN
Design a “People You May Know” feature for LinkedIn using graph neural networks for link prediction over the professional social graph. Given a member and the current graph of connections, the system must recommend people the member likely knows and would connect with, ranking millions of candidates by connection probability.
The graph is massive (hundreds of millions of nodes, billions of edges), sparse for most members, and rich with side features: company, school, job title, location, co-workers, co-alumni. A GNN can propagate information along edges to capture multi-hop structure that simple heuristics (mutual friends, same company) miss, but it must scale to the full graph and stay useful as new connections form every second.
How would you design this model? Cover the candidate GNN architectures (GraphSAGE vs GAT vs PinSage-style random-walk plus convolution), how you handle negative sampling and class imbalance, how you scale training and inference to a graph with hundreds of millions of nodes, how you incorporate node side features, and how you keep recommendations fresh as the graph evolves.

The Problem: a member has a few dozen links inside a graph of hundreds of millions of people, so the model must find the handful of real-world acquaintances hiding in an ocean of strangers.
Answer
The model is a two-layer inductive GraphSAGE encoder trained as a link predictor: for each pair, sample a fixed-fanout neighborhood, aggregate side features along the sampled edges into a 256-dimensional embedding, and score the pair with a dot product. Fixed fanout is the pivotal decision because it makes cost per candidate independent of degree, which matters on a graph where recruiters carry tens of thousands of edges. The second pivotal decision is the negative sampling mixture: random negatives alone make the task trivially easy at a positive rate near $10^{-6}$ , so training mixes in hard two-hop negatives (people who share a company or mutual connections but never connected). Attention is added surgically as a last-layer GAT head on high-degree neighborhoods rather than everywhere, and side features enter as the layer-zero representation so a brand-new member gets an embedding without retraining.
(1) GraphSAGE (chosen encoder): uniform neighbor sampling with fanout $(25, 10)$ and mean or pooling aggregation, inductive by construction because weights act on features rather than node IDs.
(2) GAT (selective upgrade): learned per-edge attention softmax over neighbors, which can down-weight a recruiter or hiring-manager edge that mean aggregation blends into the signal.
(3) PinSage-style random walk plus convolution: neighborhoods defined by random-walk visit counts instead of the raw adjacency, giving importance weights and a hub-resistant top-T neighbor set.
(4) Heuristic and shallow baselines: common neighbors, Adamic-Adar, and matrix factorization set the accuracy floor the GNN must beat, and remain the cheap candidate generator that feeds it.

Figure 1: One shared encoder, two sampled neighborhoods, one dot product: the whole model is a siamese GNN over a bounded receptive field.
Clarify Before Designing:
(1) Label definition: is a positive an invitation sent, an invitation accepted, or a “we actually know each other” signal, and are dismissals usable as negatives?
(2) Inductive requirement: must a member who joined ten minutes ago and has zero edges get an embedding, or may cold-start fall back to a feature-only model?
(3) Freshness budget: how stale may an embedding be after a new connection forms, minutes or a full day?
(4) Compute and storage budget: how many GPUs for training, and can we store $|V| \times d$ embeddings in a serving store?
(5) Graph heterogeneity: do we get typed edges (co-worker, co-alumnus, message, profile view) and reliable side features for all members, or only for complete profiles?
(6) Candidate volume per request: does the GNN score millions of pairs, or a pre-filtered two-hop pool of a few thousand?
Login to view more content
September 3, 2026
MSD0033 Drowsy Driving Detection
Design a drowsy-driving detection system that uses an in-car camera to monitor the driver and warn before they fall asleep, as offered by Volvo’s Driver Alert, Mercedes Attention Assist, and aftermarket dashcam apps. The system must run on an embedded device or a phone mounted on the dashboard, process the camera feed in real time, and detect early signs of drowsiness (eyelid closure duration, blink rate, head nodding, gaze wandering, micro-sleeps) with few false alarms so drivers do not disable it. It must work across drivers of different appearance, in varying lighting (night, tunnels, sunglasses), and it must keep the video on-device.
How would you design this system? Cover the face and landmark detection, the drowsiness signal extraction (PERCLOS, blink dynamics, head pose), the temporal model that combines signals over a window, the on-device deployment and privacy design, and how you calibrate the alert threshold to minimize false alarms without missing real drowsiness.

The Problem: the dangerous state lasts a few seconds and arrives after minutes of visible warning signs, so the system has to fire during the slow decline, at night, through sunglasses, and almost never on an alert driver.
Answer
The design is a landmark-driven feature pipeline with a learned temporal model: a cheap face detector runs on a fraction of frames with a tracker in between, a landmark network gives eye, mouth, and head-pose geometry per frame, hand-designed physiological features (PERCLOS, blink dynamics, nod and gaze statistics) are accumulated over a sliding 60-second window, and a small recurrent model maps that window to a drowsiness score. The two pivotal decisions are to keep interpretable intermediate signals rather than regressing drowsiness end-to-end from pixels, and to treat the alert threshold as a calibrated operating point on a false-alarms-per-hour axis with hysteresis, because a system that chirps at an awake driver gets unplugged on day two. Everything runs on-device on an int8 quantized graph with a near-infrared sensor, and no frame is ever written to storage or uploaded.
(1) Geometric Landmark Pipeline: face detection plus a landmark network feeding eye aspect ratio, PERCLOS, blink timing, and head pose; features are physiologically interpretable and cheap.
(2) End-to-End Video Model: a 3D CNN or video transformer over eye-region crops predicting drowsiness directly, learning subtle cues no geometric feature encodes, at a much higher data and compute cost.
(3) Hybrid Fusion (chosen): geometric features per frame plus a small GRU over the 60-second window, with per-driver normalization and hysteresis on the output score.
(4) Vehicle-Signal Baseline: steering entropy, lane-position variance, and pedal behavior with no camera at all, which is what Volvo’s original Driver Alert used; it is robust to lighting but needs minutes of degraded driving before it reacts.

Figure 1: Per-frame geometry becomes per-window physiology, and only the last stage makes a decision: pixels never leave the device and never leave RAM.
Clarify Before Designing:
(1) Sensor: RGB rolling-shutter phone camera or a dedicated near-infrared global-shutter module with an 850 nm illuminator, and at what resolution and frame rate?
(2) Compute Target: a phone with an NPU delegate, an automotive SoC, or a low-power MCU, and what sustained thermal and power budget do we get on a 4-hour drive?
(3) Alert Budget: how many false alarms per driving hour before drivers disable the feature, and are we targeting a regulated warning profile (UNECE ADDW-style) or a comfort feature?
(4) Labels: do we have annotated drowsy driving data with KSS self-reports or expert video scoring, and how many distinct drivers, or only simulator and public sets?
(5) Occlusion Requirements: must the system work through sunglasses and face masks, or may it declare “sensing unavailable” and fall back to vehicle signals?
(6) Action Space: what can the alert actually do (chime, haptic seat or wheel, escalating voice prompt, rest-stop suggestion), since the escalation ladder shapes the threshold.
Login to view more content
August 22, 2026
MSD0032 End-to-End Self-Driving
Design an end-to-end learning model for self-driving, where a single neural network (or a tightly coupled stack) maps raw sensor inputs directly to driving actions (steering, acceleration, braking), as pursued by Tesla’s FSD v12+, Wayve’s LINGO, and research systems like UniAD and VAD. Unlike the traditional modular pipeline of separate perception, prediction, planning, and control modules, an end-to-end model learns the full policy from data and can in principle optimize the driving objective globally.
The catch is that this policy is a black box. It is hard to interpret, hard to verify for safety, hungry for data and compute, and it only ever sees the long tail of rare driving situations a handful of times.
How would you design this model? Cover the candidate architecture approaches (pure end-to-end policy network vs loosely coupled perception-prediction-planning with learned interfaces vs hybrid with a differentiable cost head), the training data and objective (imitation learning vs reinforcement learning vs inverse RL), how you handle the long tail of rare safety-critical events when learning from data, and how you verify and debug a black-box policy before deployment.

The Problem: one learned function must turn photons into pedal and steering commands, and the events that decide whether it is safe appear once every hundred thousand miles.
Answer
I would build a query-based end-to-end network with a differentiable cost head, not a raw pixels-to-pedal regressor. Multi-camera features are lifted into a BEV representation, a set of scene queries carries agents, map, and occupancy, and an ego query cross-attends to those queries to produce a short-horizon trajectory that a learned cost head scores together with a few hand-authored terms. Everything is trained jointly with one driving loss, so gradients still reach the encoder, but every intermediate is supervised and therefore inspectable. The two pivotal decisions are to keep auxiliary supervision on the intermediate queries (this is what buys sample efficiency and debuggability without cutting the gradient path) and to keep hard safety constraints outside the learned cost, in an independent rule-based guardian that the network cannot argue with.
(1) Pure End-to-End Policy: one network maps sensor history directly to control, trained by behavior cloning on fleet data with no intermediate supervision.
(2) Loosely Coupled Modules with Learned Interfaces: perception → prediction → planning stays as stages, but the interfaces are differentiable query tokens rather than hand-defined object lists, as in UniAD and VAD.
(3) Hybrid with a Differentiable Cost Head: the network emits a learned cost over candidate ego trajectories, combined with explicit collision, comfort, and rule terms, and an optimizer or sampler picks the executed trajectory.
(4) Chosen Combination: approach 2 for the representation plus approach 3 for the output, imitation pretraining followed by closed-loop fine-tuning in simulation.

Figure 1: The chosen architecture. One driving loss backpropagates all the way to the encoder, while auxiliary heads keep the intermediate scene representation readable and the cost head keeps the final decision expressible in physical terms.
Clarify Before Designing:
(1) Sensor Suite And Output Interface: camera-only or camera plus lidar and radar, and does the model emit a 3 second trajectory for a downstream controller or raw actuator commands?
(2) Compute And Latency Budget: how many TOPS on-vehicle and what reaction budget, since that caps token count, temporal context, and model size?
(3) Data Access: fleet miles per day, whether human control signals are time-aligned with sensors, and whether a closed-loop simulator with reactive agents exists.
(4) Operational Design Domain: highway lane keeping, dense urban, or both, and in which geographies and weather, because the ODD size sets the length of the tail.
(5) Safety Architecture: is an independent rule-based guardian or a safety driver allowed downstream, or must the network’s output be the last word before the actuators?
Login to view more content
August 22, 2026