What 250 Reviews Taught Me About Reading Between the Lines

READING BETWEEN THE LINES — FIRST 90
SECONDS:

Interviewer: "Walk me through your
migration work."

Candidate: "Sure. I led the migration to
Kubernetes. We had 12 services, a team of 4
engineers, and the migration took two
quarters. The main risk was the stateful
services — the database and the Redis
cluster — so we moved the stateless services
first, then the stateful ones with a canary."

What the interviewer notices:
- "12 services, 4 engineers, two quarters" —
  the numbers are specific, so the
  candidate actually ran it.
- "The main risk was stateful" — they name
  a real risk, not a generic one.
- "Canary" — they name the mechanism.

The follow-up: "Tell me about the stateful
migration." The candidate has a story.

What the interviewer thinks in 90 seconds:
- "Specific numbers = real ownership." ✅
- "Named risk = production experience." ✅
- "Mechanism = they can go deeper." ✅

Signal: trust. The rest of the interview
confirms it.

READING LITERALLY — FIRST 90 SECONDS:

Interviewer: "Walk me through your
migration work."

Candidate: "I led the migration to
Kubernetes."

What the interviewer notices:
- "12 services? Or 2? No number."
- "4 engineers? Or alone? No team size."
- "Two quarters? Or two weekends? No
  timeline."
- "What was the risk? No risk named."
- "What broke? No failure named."

What the interviewer thinks in 90 seconds:
- "Led" without a number is a hedge." ❌
- "No risk = never hit a real problem." ❌
- "No timeline = never finished a real
  project." ❌

What happens next:
- The interviewer asks "How many services?"
- The candidate says "I think it was
  around 10."
- The interviewer asks "What was the
  hardest part?"
- The candidate gives a generic answer
  about "the learning curve."

Signal: doubt. The candidate's "led" was
a hedge, and one follow-up exposed it.

Why it failed:
❌ No number
❌ No team size
❌ No timeline
❌ No risk named
❌ The candidate can't go deeper

NUMBERS ANSWER — WHAT DECIDES:

Interviewer: "You said you led the
migration. How big was it?"

WHAT THE CANDIDATE SAYS:
"12 services, 4 engineers, two quarters. Let
me give you the context.

The 12 services: 9 stateless — the API, the
workers, the reporting service — and 3
stateful, including the Postgres primary and
the Redis cluster. We moved the stateless ones
in Q1 and the stateful ones in Q2.

The 4 engineers: one on the platform side,
two on the service side, and me leading. The
platform engineer owned the cluster itself;
I owned the migration plan and the canary
gates.

The two quarters: 12 weeks of execution, 2
weeks of planning. The planning was slower
than I expected — we spent three weeks on the
networking because the old VPC had overlapping
CIDRs.

The result: 20% lower p99 latency, and the
deploy time dropped from 40 minutes to 8.
The cost: the cluster adds about $1.5K a
month over the old ASG setup, but the ops
time saved — about 6 hours a week — pays for
it.

I can show you the migration plan and the
canary config."

What the interviewer thinks:
- "Numbers on demand, not pulled." ✅
- "The scope is specific: 9 stateless, 3
  stateful." ✅
- "The plan is honest: planning was slower
  than expected." ✅
- "The result has a cost: $1.5K." ✅
- "This is someone who ran it." ✅

Signal: confirmed trust.

Why it decides:
✅ Numbers are volunteered
✅ Scope is specific
✅ Planning friction is honest
✅ Result has a cost
✅ Evidence is available

HONEST SCOPE — WHAT DECIDES:

Interviewer: "What exactly did you own?"

WHAT THE CANDIDATE SAYS:
"I should be precise, because 'led the
migration' overstates it.

What I owned: the migration plan for the
stateful services — the Postgres primary, the
Redis cluster, and the 3 workers. That
included the canary gates, the rollback
procedure, and the runbook for the on-call
team.

What I didn't own: the cluster itself. The
platform engineer set up the EKS cluster, the
networking, and the IAM. I worked with them,
but I didn't design it.

What the lead owned: the overall
architecture and the Q1 stateless migration.
I learned from that and applied the pattern
to the stateful services in Q2.

Why I listed it as 'led': I did lead the
stateful migration — the hardest part — but
if you ask me to design a Kubernetes cluster
from scratch, I'd say I'm intermediate, not
expert. I'd rather tell you that than have
you find out in the technical round.

The trade-off: owning the plan but not the
cluster meant I had to coordinate with the
platform engineer on every change. I accepted
that because the cluster was their expertise,
and the migration plan was mine.

The result: the stateful migration went
without an outage — the canary caught one
readiness-probe issue that I fixed before
rolling to 100%."

What the interviewer thinks:
- "They split what they owned from what
  they didn't." ✅
- "Each claim has a boundary." ✅
- "They'd rather be honest than impress." ✅
- "The trade-off is named." ✅
- "I trust the rest of the resume more." ✅

Signal: confirmed trust.

Why it decides:
✅ Owned vs. didn't own is explicit
✅ Each role has a boundary
✅ Honesty is prioritized
✅ The trade-off is named
✅ The rest of the resume gains trust

RESUME REVIEW — BETWEEN THE LINES VS.
LITERAL:

Scenario: "Review this bullet: 'Architected
a scalable microservices platform.'"

LITERAL READ:
"Architected" = designed. "Scalable" =
handles growth. "Microservices platform" =
many services. The literal read sounds
impressive.

BETWEEN-THE-LINES READ:
- "Architected" — did they design it, or
  implement someone else's design? The verb
  is doing a lot of work.
- "Scalable" — a claim without a number.
  How many requests? What p99?
- "Microservices platform" — how many
  services? 3 or 30?
- No team size. No timeline. No cost.

The follow-up question: "How many services,
and what was the scalability target?"

What the interviewer thinks:
- "The bullet is a claim, not evidence." ❌
- "One follow-up will clarify it." ⚠️

A STRONG REWRITE:
"Designed the order service (1 of 12
services) and its Postgres schema; the
service handles 4K requests/sec at p99
250ms. Led 2 engineers; the migration took
one quarter."

What the interviewer thinks:
- "The scope is specific: 1 of 12." ✅
- "The number is specific: 4K req/sec." ✅
- "The team is specific: 2 engineers." ✅
- "The timeline is specific: one quarter." ✅
- Signal: confirmed trust.

Why the rewrite works:
✅ Scope is honest: 1 of 12
✅ A number with a mechanism
✅ Team size
✅ Timeline
✅ The bullet survives a follow-up

INTERVIEW FOLLOW-UP — BETWEEN THE LINES VS.
LITERAL:

Scenario: "The candidate says 'it went
smoothly.' How do you probe?"

LITERAL READ:
"It went smoothly" = no problems. The
candidate is confident.

BETWEEN-THE-LINES READ:
"It went smoothly" = either the candidate
wasn't close to the work, or they're
omitting a problem they don't want to
discuss. A real migration always hits
something — a networking issue, a
readiness probe, a data migration glitch.

The follow-up: "What was the first thing
that broke, and how did you find it?"

What happens next:

STRONG CANDIDATE:
"The first thing was a readiness-probe
issue — the canary pods were getting
traffic before they were ready. We caught
it at 5% traffic because the canary gate
blocked the roll to 100%. I added the probe
and a policy check that fails the build if
it's missing."

What the interviewer thinks:
- "They named a real problem." ✅
- "They found it at 5% traffic." ✅
- "They added a prevention." ✅
- Signal: confirmed trust.

WEAK CANDIDATE:
"I don't remember anything breaking. It
was pretty smooth."
What the interviewer thinks:
- "Either they weren't close to the work,
  or they're omitting." ❌
- "No named problem = no production
  experience." ❌
- Signal: doubt.

Why it decides:
✅ Real migrations break
✅ A named problem is evidence
✅ A prevention is judgment
✅ "It went smoothly" is a red flag,
  not a good sign

Between-the-Lines Checklist:

FIRST 90 SECONDS:
☐ Is there a number? Team size, timeline,
  volume, cost
☐ Is the verb proportionate? "Led" vs.
  "contributed" vs. "built"
☐ Is the scope believable for one person
  and one timeline?
☐ Is there an outcome, or just an
  activity?

WHAT DECIDES:
☐ Numbers are volunteered, not pulled
☐ Scope is honest: what they owned and
  what they didn't
☐ A risk or failure is named
☐ The failure has a prevention
☐ The outcome has a cost

WHAT CONFIRMS:
☐ The bullet survives one follow-up
☐ The story is consistent across the
  resume and the interview
☐ The candidate can go deeper on any
  claim
☐ The candidate names what they don't
  know

RED FLAGS:
❌ "Architected the entire platform"
❌ "Led a large migration" with no numbers
❌ "It went smoothly"
❌ No team size, no timeline
❌ "Contributed" when the summary says
  "led"
❌ No failure anywhere
❌ A scope too wide for one person

Why this works:
- The first 90 seconds set the signal
- The rest of the review confirms or
  overturns it
- Numbers, honest scope, and named failures
  are the three things that can't be faked

30-DAY WRITING PLAN (FOR CANDIDATES):

Week 1 — Add the numbers
☐ For 5 bullets, add team size
☐ For 5 bullets, add a timeline
☐ For 5 bullets, add a volume or cost
☐ Cut every "large," "major," "significant"

Week 2 — Right-size the verbs
☐ For each bullet, ask: did I lead,
  contribute, or implement?
☐ Change "led" to "contributed" where
  it's true
☐ Change "architected" to "designed" or
  "implemented" where it's true
☐ Add a boundary: "I didn't own the
  cluster"

Week 3 — Add the failures
☐ For 3 projects, write the first thing
  that broke
☐ For each, write how you found it
☐ For each, write the prevention
☐ Add one failure per project to the
  resume or the README

Week 4 — The follow-up test
☐ For each bullet, ask a peer: "What's
  the first follow-up question?"
☐ If they ask "how many?" or "what
  broke?", add those details
☐ Rewrite until no bullet needs a
  follow-up to be credible
☐ Run the same test on your interview
  answers

Signs it's working:
✅ Every bullet has a number
✅ Every verb is proportionate
✅ Every bullet has a named failure
✅ Every failure has a prevention
✅ A peer has no follow-up questions
✅ The interviewer asks "what else?"
  instead of "how big was it?"