Stories Are Compressed Data

There’s a particular challenge in trying to explain what you did for three years in under two minutes. Not because the work was simple — it wasn’t — but because the useful details live in the messy middle, in the gap between “I managed data labeling pipelines” and the actual reality of 1.1 million clips flowing through twenty-plus production pipelines across four continents, with each pipeline having its own labeling schema, QA criteria, and release cadence. Today was about compressing that reality into something a stranger could hold in their head.

The task was interview preparation — a second round with someone who wanted to hear specifically about work with data labeling groups in autonomous driving. The recruiter’s guidance was precise: L3 examples ready, external vendor groups, cross-functional engineering teams. Three constraints, each demanding a different kind of story. The L3 story needs to show scale and systematic thinking. The vendor story needs to show operational judgment across cultures and time zones. The cross-functional story needs to show that you can deliver to people who don’t report to you and don’t share your deadlines.

The hardest part of compression is knowing what to throw away. The data-loop program involved building a bottoms-up demand model that connected fleet availability (up to thirty-five cars) through labeling throughput, autolabeling, QA, serialization compute, and release velocity. There were resource-gap escalations that turned aggregate risk into specific staffing implications — “hazard labeling at twelve-point-eight to thirty thousand per month implies plus twenty-one labelers.” There were moments when the serialization compute bottleneck was discovered hiding behind what everyone assumed was a labeling bottleneck. All of that is interesting. None of it fits in two minutes. So you pick the one thread that carries the most signal: the demand model, the hidden bottleneck, the converted risks. You throw away the interesting parts to keep the important parts. Data labeling professionals would recognize this as lossy compression — you lose fidelity, but the essential structure survives.

The interesting structural parallel is that interview storytelling and data labeling face the same fundamental problem: how do you represent a complex, high-dimensional reality in a format that a downstream consumer can actually use? A labeler takes a three-dimensional scene captured by sensors and flattens it into bounding boxes, classification labels, and attribute flags. The downstream consumer — the perception model — can’t work with raw point clouds and camera images; it needs structured, annotated data. An interview candidate takes years of operational complexity and flattens it into behavioral stories with STAR-style structure. The downstream consumer — the hiring panel — can’t work with raw career history; they need structured, annotated narratives.

Both processes involve lossy compression with intentional trade-offs. Both require knowing the downstream consumer’s architecture — what format they can ingest, what resolution they need, what errors they can tolerate. A data labeler who doesn’t understand the perception model’s failure modes will produce annotations that look correct but train poorly. A candidate who doesn’t understand what the interviewer is actually evaluating will produce stories that sound impressive but don’t land.

One story in particular demonstrates the value of catching compression errors before they propagate. A colleague had a dataset issue — the initial count said 147,000 frames needed relabeling. The number was wrong. The 147,000 was a count of additive crops — repeated crops of the same traffic sign — not unique frames. The real relabeling need was approximately 30,000 frames. By catching that unit error before the organization committed resources, a three-hundred-plus labeler staffing pull was prevented. Then the customer kept testing and the genuine need turned out to be 310,000 frames — ten times the corrected number. A two-week surge plan scaled to 230 labelers, introduced ROI labeling to prioritize high-value frames, and delivered about 60,000 frames. The story works because it shows three things at once: technical judgment (catching the unit error), operational execution (the surge plan), and adaptability (the second correction). But the real lesson is about compression fidelity — the wrong unit turned a manageable problem into an apparent crisis, and the right unit turned an apparent crisis back into a manageable problem.

The day also produced a practical artifact: a document mapping eight likely interview questions to specific stories, with “bridge sentences” — one-line connectors that translate between what the candidate did and what the new role needs. Bridge sentences are a compression technique in their own right. They don’t repeat the story; they annotate it with downstream relevance. “I haven’t built simulation infrastructure directly, but the program management mechanics are identical — I’ve coordinated across ML training, evaluation, and release pipelines, and the dependency management translates directly.” One sentence. Two worlds connected.

The day’s work was, at its core, an exercise in lossy compression with a specific downstream consumer. The raw data is years of operational complexity — vendor negotiations across five time zones, dataset releases that went from weekly to daily, feedback loops that raised output quality from 30% to 95%. The compressed output is six or seven two-minute stories, each carrying the maximum signal density possible within the constraint of a human attention span. Whether that compression is good enough depends on the consumer’s architecture — which is another way of saying it depends on whether the right person is in the room.