Case Study 2: The Job That Was Not the Job

"The title was Senior Data Engineer. Eleven months in, I had built two pipelines and maintained forty-one dashboards, and every question I would have needed to ask was one I could have asked in the interview."

Executive Summary

An engineer accepted a role titled Senior Data Engineer at a mid-sized retailer. Eleven months later they left.

Nothing they were told was false. The job description was accurate, the interviewers were honest, and the work was real. The job was simply not the one the title described:

what the title implied          what the work was
build and operate pipelines     41 dashboards, maintained
own the platform                a platform owned by a vendor and a consultancy
data modelling                  requirement-gathering for report changes
on-call for data                on-call for dashboard availability

Seven questions would have surfaced it in the interview, and the engineer asked none of them — not through carelessness, but because the questions they did ask had obvious good answers that a company can give whether or not they are true.

This case study is the reverse interview, worked: what they asked, what they should have asked, and what each answer would have revealed.

Skills applied: §39.10's question bank and what the answers mean; the dashboards-versus-pipelines ratio; and the distinction between a question that tests a claim and one that invites a claim.

Background

The role, as advertised:

"Senior Data Engineer. Build and maintain our data platform. Python, SQL, dbt, Airflow. Partner with analytics and finance to deliver trusted data."

Nothing in that is misleading. Every technology named was in use. The engineer did partner with analytics and finance. "Maintain our data platform" was doing quiet work, and "deliver trusted data" turned out to mean "produce the reports finance asks for."

What the interview covered: a SQL screen, a system design round, a behavioral round, and a hiring manager conversation. The engineer performed well and asked four questions, all of them reasonable:

"What does the tech stack look like?"
"What would my first 90 days look like?"
"How is the team structured?"
"What are the biggest challenges right now?"

⚠️ Failure Mode — questions that invite a claim rather than test one

All four questions are standard, all four got good answers, and none of them could have gone badly. That is the defect.

Look at what each one asks the company to do:

text "what's the tech stack?" -> list technologies. Every company can. "first 90 days?" -> describe an intention. Free. "how is the team structured?" -> an org chart. Verifiable and irrelevant. "biggest challenges?" -> a chance to sound self-aware.

Each invites a claim, and a claim costs nothing. "We use Airflow and dbt" is true at a company where two people run one DAG and at a company running four hundred, and the sentence is identical.

A useful question has a property these lack: a bad answer must be possible. §39.10's test, and it is the same test as Chapter 30 Case Study 2's for an access review — could the answer have been "no"?

Compare the same four, rewritten so that a bad answer exists:

text "how many pipelines does the team run, and how many dashboards?" "what did the last person in this role spend their time on?" "what happened in your last data incident?" "what's the last thing you deleted?"

Each of those has an answer that would have told the engineer to decline, and that is precisely why they are worth asking. The four they did ask could not produce that answer no matter what was true.

What the Questions Would Have Revealed

Working through §39.10's bank against what the company would honestly have said:

"How many pipelines does the team run, and how many dashboards?"

"About six pipelines. Forty-something dashboards — we're the reporting team really."

This single answer contains the whole finding, and the phrase "we're the reporting team really" is one an honest hiring manager will say if asked directly. The engineer never created the occasion.

"What did the last person in this role spend their time on?"

"Honestly, a lot of dashboard changes. That's part of why we're hiring — we want someone to get us onto a proper platform."

🔎 Read the Plan — the answer that sounds like an opportunity and is a warning

This answer is the most seductive one in the case study, because it is honest, self-aware, and describes exactly the job the engineer wanted: come and fix this.

Three follow-ups turn it from a promise into a fact, and each is one sentence:

"Who decided that, and when?" A decision made by the hiring manager three weeks ago is an aspiration. A decision made by the VP six months ago with a budget line is a plan.

"What has been done toward it so far?" "Nothing yet, that's what you'd be for" means you are the plan, alone, against forty-one existing dashboards with existing consumers. "We've stopped taking new dashboard requests" is a different company.

"What happens to the forty-one dashboards while I build the platform?" This is the question, and the answer is almost always "we'd need to keep them running." Which means the job is: maintain forty-one dashboards and also build a platform, with the first having deadlines and the second having none — Chapter 37 §37.13's political problem, and the reason the engineer built two pipelines in eleven months.

The generalizable form: when a company describes the job as fixing a problem, ask what happens to the problem while you fix it. If the answer is "it continues, and you keep handling it," the fixing is the part that gets deferred, every time, because it is the part with no deadline.

"What happened in your last data incident?"

"We don't really have incidents. If a dashboard is wrong someone tells us."

Which is §39.10's stated bad answer, and it says something precise: nothing is monitored, so the detection mechanism is a person noticing. It also implies there is no on-call, no SLO, and no reconciliation — all from one sentence.

"What is the last thing you deleted?"

"...Hm. I don't think we've deleted anything."

Forty-one dashboards, none retired. Chapter 25 §25.12's finding waiting to happen, and — per §39.10 — the answer that reveals both the absence of usage measurement and the absence of permission to remove things.

The Eleven Months

What actually happened, quarter by quarter:

Q1   onboarding; 14 dashboard change requests completed
     the platform work is "next quarter"
Q2   19 dashboard change requests; 1 pipeline built
     a platform proposal written and well received
Q3   22 dashboard change requests; the proposal is deferred to
     make room for a reporting deadline
Q4   12 more requests; 1 more pipeline; the engineer resigns

Two pipelines and sixty-seven dashboard changes in eleven months — and the ratio got worse each quarter, because each delivered dashboard generated its own follow-up requests.

🏭 From the Pipeline — nobody acted in bad faith and the outcome was still wrong

This is the part worth being careful about, because the instinct is to read the company as deceptive and it was not.

The hiring manager genuinely wanted a platform, wrote a supportive review of the proposal, and was disappointed when the engineer left. The dashboard requests were genuinely urgent — each had a requester, a deadline, and a business reason. Nobody chose reporting over the platform; the platform simply lost every individual scheduling decision, because it had no deadline and every dashboard request did.

That mechanism appears in this book four times — Chapter 25's alert ratchet, Chapter 30's grant sprawl, Chapter 33's idle warehouses, Chapter 34's layer drift — and this is the same shape applied to a career:

text the urgent thing: a requester, a deadline, visible completion the important one: no requester, no deadline, invisible until done

The engineer's mistake was not accepting the job. It was accepting "we want to get onto a proper platform" as a fact about the future rather than as an intention, and not asking the one question that distinguishes them: what happens to the existing work while I do the new work?

And the company's mistake was symmetrical: they did not ask themselves that question either, so they hired honestly for a job they had not actually created.

What the Engineer Did Differently Next Time

The second search, thirteen weeks later, used §39.10's questions. Four companies, and the answers sorted them quickly:

company   pipelines/dashboards   last deleted            incident story
A                6 / 41          "nothing"               "we don't have any"
B               22 / 15          "a churn model, in Q2"  detailed, 40 min
C               11 / 30          "some old tables"       vague
D                9 / 12          "an entire ingestion    specific, with a
                                  path, last month"       postmortem link

B and D were the offers pursued. A was declined after the reverse interview alone — the same company shape as the first job, identified in one forty-minute conversation rather than eleven months.

🎓 Interview Angle — the ratio is the fastest single signal

Pipelines to dashboards, asked as one question, is the highest-information-per-second question in §39.10's bank for this specific failure:

text pipelines >> dashboards a data engineering job roughly balanced a small team doing both; check the trend dashboards >> pipelines a reporting job with a data engineering title

It is fast, it is concrete, and it is very hard to answer misleadingly — a hiring manager who does not know the numbers will say so, which is itself informative, and one who inflates them is easily caught by a follow-up ("which are the six most important?").

Two refinements worth adding:

Ask for the trend, not just the level. "And which direction has that been going?" A team at 6/41 that was 6/50 last year is fixing it; one that was 6/30 is not.

And ask who builds new dashboards. If the answer is "the data engineers", the ratio will not improve regardless of intent, because the people who would build the platform are the throughput constraint on the thing that competes with it.

The honest caveat: a reporting job is a perfectly good job. The failure here is not that the work was beneath anybody — it is that the engineer wanted a different job, and both parties spent eleven months finding out something that was knowable in forty minutes.

Lessons

  1. Nothing the company said was false, the interviewers were honest, and the outcome was still wrong.

  2. ⚠️ Four standard questions, four good answers, and none of them could have gone badly. "What's the tech stack?" is identical at a company running one DAG and four hundred.

  3. A useful question has a property these lack: a bad answer must be possible. Chapter 30 Case Study 2's test — could the answer have been "no"? — applied to the reverse interview.

  4. One question contained the whole finding: "how many pipelines and how many dashboards?" → "six and forty-something — we're the reporting team really." An honest manager will say that if asked; the engineer never created the occasion.

  5. 🔎 "We want to get onto a proper platform" is an intention, not a fact. Three follow-ups make it a fact: who decided and when · what has been done so far · what happens to the existing work while I do the new work.

  6. The third is the one. If the existing work continues, the fixing is what gets deferred, every time, because it is the part with no deadline.

  7. 🏭 Nobody chose reporting over the platform. The platform lost every individual scheduling decision — the urgent thing has a requester, a deadline, and visible completion; the important one has none of the three. The same ratchet as Chapter 25's alerts, Chapter 30's grants, Chapter 33's idle warehouses, and Chapter 34's layer drift, applied to a career.

  8. The company's mistake was symmetrical: they did not ask themselves that question either, and hired honestly for a job they had not created.

  9. 🎓 The pipelines-to-dashboards ratio is the fastest single signal, is hard to answer misleadingly, and improves with two refinements: ask the trend, and ask who builds new dashboards — if it is the data engineers, the ratio will not improve regardless of intent.

  10. Four companies, sorted in four conversations. The one with the same shape as the first job was declined after the reverse interview alone — eleven months of information obtained in forty minutes.

  11. A reporting job is a perfectly good job. The failure was not the work; it was that two parties spent eleven months discovering something knowable in one conversation.

Questions for Discussion

  1. The four questions the engineer asked are the ones most commonly recommended. Why do you think they are recommended, and what are they good for?

  2. Apply the "could the answer have been no?" test to five questions you have asked in interviews. How many pass?

  3. "What happens to the existing work while I do the new work?" is called the decisive follow-up. What is the best possible answer to it, and have you ever heard one?

  4. The company hired honestly for a job they had not created. Whose responsibility is that, and what would have caught it on their side?

  5. The engineer declined company A after the reverse interview alone. Was that enough evidence? What would you have asked to confirm it?

  6. The pipelines/dashboards ratio can be gamed by a manager who knows the question. How would you detect that, and does the question survive becoming well known?

  7. This book argues repeatedly that the important work loses to the urgent work when it has no deadline. What gives platform work a deadline? Name three mechanisms from earlier chapters.