Aiming your story at the role

Day 24: Aim Your Story at the Seat, Not the Job Description

You made the final round. You told your best stories well. Then the email came: 'strong candidate, not the right fit.' Your story usually isn't the problem. You told a good story that answered a question nobody on the panel was asking. Today you get one question that shows you the problem they actually need solved, and a way to re-aim your answers the moment you hear it.

The mis-hire I made from the founder's chair

Years ago, as a founder and CTO, I hired a senior engineer who matched my job description line for line: distributed systems, Kubernetes, clean architecture, good references. But I'd written that JD for the company I pictured two years out, with a platform team, proper data infrastructure and real scale problems.

The company I actually had dealt with a fire every Monday. Customers dropped weekend batch files into our ingestion pipeline, and something always broke. A schema change. A half-uploaded file. A timezone bug. Someone had to be online at 7am to fix the data, re-run the jobs and get on a call with the customer's ops person before their week started. That someone was me. It never went into the JD because I didn't think of it as a job. It was just something I did.

The engineer came in wanting to design the platform and got Monday fires and customer calls. They did the work. But every week felt like a bait-and-switch, and they were right about that. Five months later they left. That one was on me. I'd hired against the wish list and never named the job that was actually open. Ever since, when I open a role as a hiring manager, the first thing I ask myself is: what breaks if nobody sits in this seat?

Why job descriptions drift from the real job

• ▹Written by committee. The manager, the tech lead, HR and sometimes a VP each add a line. Nobody takes one out.
• ▹Copied forward. Last year's posting becomes this year's template, and last year's priorities come along with it.
• ▹Padded with the future stack. Tools the team hopes to adopt someday show up as requirements.
• ▹Now drafted by LLMs. Someone asks a model for 'a senior AI engineer JD' and gets every framework going: agents, RAG, vector DBs, fine-tuning, MLOps. It reads fine, so nobody edits it. It's generic by design and tells you nothing about this team.
• ▹What I see as an EM at PhoenixDX: the real need almost never reaches the posting. Things like 'our agent evals are flaky and nobody owns them' or 'inference cost doubled and nobody can explain why' stay in the hiring manager's head.

One catch for AI-era candidates. Plenty of companies screen CVs against the JD with tools that are more and more often LLM-based, so you still have to aim at the JD to get in the door. Once you're in the room, the JD has done its job. From there on, aim at the seat.

Where this sits in the course

Earlier days taught you to turn your work into clear, specific stories with stakes, actions and outcomes. Those stories are your ammunition, and today is about aiming them. A great story pointed at the wrong target still gets 'not the right fit', because the panel can't see how it solves their problem.

The question

Ask the hiring manager this, word for word:

What breaks if this seat stays empty another quarter?

• ▹It's concrete. You're asking about a failure, not 'the ideal candidate', so you hear about a real situation instead of a list of adjectives.
• ▹It has a time limit. 'Another quarter' pulls them into the next 90 days and away from the three-year vision in the JD.
• ▹Few people ask it. Managers get 'what does success look like?' constantly and have a polished answer ready. In my experience this one catches them off-script, and they tend to answer honestly, often after a sigh.
• ▹It shows your level. Asking about consequences tells them you think like an owner, before you've said a word about yourself.

If the person across the table isn't the manager, try one of these instead:

• ▹Recruiter: 'Why was this role opened now rather than six months ago?' Recruiters usually know what triggered the requisition: someone left, a customer escalated, an initiative got funded.
• ▹Peer engineer: 'What are you covering right now that you'd hand to this person on day one?' Peers know exactly which pager, backlog or Slack channel is waiting for the new hire.

Decoding the answer: fire, gap or bet

Most answers fit one of three types. Each type needs a different kind of evidence from you.

• ▹FIRE: an incident pattern, an angry customer or a hard deadline. Example: 'Our support agent's answer quality drops every time we upgrade the model, and an enterprise renewal depends on it.' What they want to see: you've stabilised something under pressure, debugged messy production systems, and kept stakeholders informed while you did it.
• ▹GAP: work nobody owns. Example: 'Nobody owns evals, so every prompt change is a gamble.' Or: 'Nobody owns the data pipeline that feeds our RAG index.' What they want to see: you picked up ownerless work without being asked, built the boring structure (runbooks, eval suites, on-call, docs) and made it stick.
• ▹BET: a new product or AI initiative that nobody is staffed on yet. Example: 'Leadership wants an agentic workflow for claims processing by Q2, and right now it's a slide deck.' What they want to see: you took something from zero to one without clear requirements, made scoping and kill decisions, and shipped an LLM feature to real users with evals and cost controls. A demo doesn't count.

The pivot, in the same interview

You walked in with three or four polished stories. Once you've heard the answer, set most of them aside. Pick the one story that best matches their fire, gap or bet, and tell it with their problem in mind. It doesn't have to match exactly. The problem just needs the same shape.

Here's one candidate answering 'Tell me about a project you're proud of' two ways. The manager has just said: 'If this seat stays empty, our support agent keeps regressing on every model upgrade and we lose the renewal.'

BEFORE (aimed at the JD: "LangGraph, RAG, vector DBs, Kubernetes")

"I built a multi-agent RAG system on LangGraph with a vector store,
deployed on Kubernetes. I designed the retrieval layer, added
re-ranking, and set up the agent routing between three sub-agents.
It was a really interesting architecture problem."

-> Accurate and impressive, but it answers "can you use our stack?"
   They already assumed you could. The panel thinks: fine, generic.

AFTER (aimed at the next 90 days: regressions on model upgrades)

"You mentioned regressions on model upgrades. I've been through
exactly that. On my last team, our support agent started giving
wrong refund answers after a model version bump, and we only found
out from customer tickets. I pulled a few hundred real tickets into
a regression eval set, wired it into CI so no prompt or model change
could ship without passing it, and set up a weekly review of failures
with the support lead. The next upgrade, we caught the regressions
before release instead of after. That's the first thing I'd want to
look at here."

-> Same person, same experience. Now it answers "can you stop
   the thing that's hurting us?"

Look at what changed. Not the facts. The order changed, the emphasis changed, and so did the last sentence. That last line turns you from a candidate into a colleague, because it puts you inside their problem.

The follow-up note: get the debrief to start from your framing

After the interview the panel meets to debrief, and in my experience the hiring manager often skims the candidate's follow-up first. A three-line note that turns what they told you into a first-90-days plan means the discussion opens with 'can they fix our problem?' instead of 'did they tick the JD boxes?'

Line 1 - What I heard:
  "You said that if this seat stays empty another quarter,
   [the specific thing] breaks."

Line 2 - Why I match:
  "I've dealt with this shape of problem before: [one-sentence
   version of the story you told]."

Line 3 - 30/60/90 sketch:
  "30 days: [understand + stop the bleeding].
   60 days: [own it end-to-end].
   90 days: [the outcome they named, delivered]."

Keep it short. The sketch doesn't have to be right. It has to show you understood the problem and can plan against it. If they correct you in the next round, great. Now you're working on their problem with them.

Where this fails, plainly

• ▹The manager doesn't know. That tells you something. Usually the role is a backfill nobody has thought through, a requisition driven by budget, or a team without a clear mandate. Ask one follow-up: 'What would you want to be different in six months?' If it's still fuzzy, expect a fuzzy job and fuzzy performance reviews.
• ▹The answer is 'nothing really breaks'. Also useful. Low urgency tends to mean a slow process, a role that's easy to cut, and less leverage for you. Not automatically bad, but price it in.
• ▹You can't honestly fix their problem. If the fire is Kubernetes on-call and you've never run production infrastructure, don't stretch a side project into a matching story. That's my Monday-pipeline mistake from the other side of the table, and it ends in a five-month exit. Say what you can do, and be ready to walk away.
• ▹You treat it as a script. Asking the question and then playing your prepared highlight reel anyway is worse than not asking at all. Only ask if you're willing to change your answers based on what you hear.

Day 24 exercise

• ▹Pick one live application, ideally one with a call coming up.
• ▹Read the JD and whatever the team has put out publicly: engineering blog, changelog, recent launches, other job posts for the same team. Write down three guesses at what breaks for them in the next 90 days, and label each one fire, gap or bet.
• ▹For each guess, choose the one story you'd tell if that guess turned out to be right.
• ▹On the call, ask: 'What breaks if this seat stays empty another quarter?' Write the answer down word for word.
• ▹Check it against your guesses. Whatever they told you is what you'll work with in tomorrow's lesson.

Extend your knowledge

• ▹'Who: The A Method for Hiring' by Geoff Smart and Randy Street. Their 'scorecard' defines a role by the outcomes it has to deliver, not a list of traits. It's today's question seen from the hiring side.
• ▹Will Larson's 'Staff Engineer', especially the essay 'Work on what matters' (also on lethain.com). Same skill of finding the real problem, applied once you've got the job.
• ▹Camille Fournier's 'The Manager's Path', for a sense of what a hiring manager is actually worried about when they open a role.
• ▹Try it: paste a job description into an LLM and ask for five things that are probably breaking on this team right now. Treat what comes back as guesses to test on the call. They aren't answers.