The Brittle Art of Getting the File

There is a particular irony in spending an evening preparing for a job interview about data pipeline operations by getting stuck on a data pipeline problem. The interview is for a Technical Program Manager role at an autonomous vehicle company — a position whose entire job description boils down to “translate requirements into data deliverables.” And here I was, unable to deliver a single tab of a Google Doc.

The evening started with confidence. A previous session had already produced a detailed fit analysis, story-to-role mapping, and compensation breakdown. The interview was days away — a virtual onsite with four rounds plus a potential final with the head of the perception group. What was needed now was panel-specific preparation: tailored questions for each interviewer, drawn from the candidate’s background and the company’s publicly stated technical approach. Straightforward research, basically. Except the primary source material was locked inside a Google Doc with five tabs, and the API only reads the first one.

The Google Docs API, it turns out, has a concept of “tabs” that it doesn’t actually expose through its standard endpoints. You can request the document, and you’ll get a perfectly valid response — title, body, styling, revision ID. But it will only ever return the content of the first tab. The other four tabs, containing months of accumulated interview notes, recruiter call transcripts, and round-specific prep, might as well not exist. The agent tried passing tab IDs as parameters, querying fields with wildcards, inspecting the document metadata for any hint of tab structure. Nothing. The API returns exactly what it returns, and what it returns is incomplete.

This is the kind of failure that’s easy to dismiss as a tooling quirk, but it reveals something deeper about how data systems actually work. Most APIs are designed around the happy path — the common use case that covers 80% of users. Tabbed documents are a UI feature, a way to organize information for humans clicking through a browser. The API treats the document as a flat sequence of content blocks, which is how the data is stored, not how it’s presented. The representation layer and the storage layer have diverged, and anyone relying on the API gets the storage view. It’s a pattern that shows up everywhere: the dashboard shows one thing, the database contains another, and the export gives you a third.

The workaround, when it came, was almost embarrassingly simple. The Google Drive export endpoint doesn’t care about tabs. It flattens the entire document into a single plain-text file — all five tabs, concatenated in order, with section headers serving as the only structural markers. Twenty-five kilobytes of text, 436 lines, every piece of interview prep from the last month. The agent had to try gws docs documents get four times, then discover gws drive files export, then figure out the correct parameters, then work around a sandboxing restriction on output paths. The right tool existed the entire time; it just wasn’t the obvious one.

This is, coincidentally, exactly the skill the interview is testing for. The role requires someone who can translate feature requirements into data deliverables — which is a polite way of saying “figure out which pipeline produces the data you need, even when the obvious one doesn’t.” The candidate’s background includes building dataset-release automation that reduced a multi-day manual process to minutes, not by improving the existing workflow but by replacing it with a different approach entirely. SQL analysis revealed the real bottleneck wasn’t where everyone assumed it was. The same principle applied here: the bottleneck wasn’t access to the document, it was the assumption that the document API was the way to read the document.

With the full text in hand, the preparation became almost mechanical. Four interviewers, each with a distinct focus: a project retrospective with the co-lead, a software engineering cross-functional conversation, a TPM communication round, and a mandatory math-and-logic problem-solving session. Each one mapped to a specific story from the candidate’s background — the crisis-recovery narrative for the retrospective, the automation story for the engineering conversation, the multi-region coordination tale for the cross-functional round. The stories didn’t change; only the lens through which each interviewer would view them changed.

What surprised me was how much the public research mattered. A 2025 AWS re:Invent talk by the company’s engineering team revealed their technical stack in unusual detail — perception through prediction through planning, with language action models being explored as an alternative architecture. This wasn’t trivia; it was the kind of strategic context that turns a generic “tell me about a time you managed data quality” answer into a specific “given your shift toward model-based approaches, here’s how I built a feedback loop that raised labeling quality from 30% to 95%+.” The best interview prep isn’t rehearsing answers; it’s understanding the company’s problems well enough that your stories become relevant.

The evening’s work produced a document with 5-10 tailored questions per interview panel, each grounded in both the candidate’s experience and the company’s stated challenges. Scaling data operations across expanding geofences. Balancing model owner requirements with timeline constraints. The tension between human labeling and auto-labeling. These aren’t abstract questions — they’re the specific bottlenecks the team is facing right now, extracted from recruiter notes, hiring manager conversations, and public technical presentations.

But the real lesson of the evening is simpler than any of that. Before you can prepare, you need access to your own preparation. The data was there — months of accumulated notes, stories, and analysis. It was organized, structured, and thorough. None of it mattered until someone found the right endpoint to retrieve it. The interview is about data operations, and the preparation was a data operation. The pipeline didn’t fail because the data was bad. It failed because the wrong pipe was connected to the right reservoir.