Career 22 min read

14 Interviews, 2 Offers: What a Staff Engineer Job Search Actually Looks Like

The honest, unglamorous version of a Staff Engineer job search — the books, the routine, the prep, the real questions across 14 processes, and the dozen rejections before two offers.

The honest, unglamorous version — the books I read, the routine I kept, the prep I did before every round and every negotiation, and the real questions I was asked across 14 interview processes. Most of them ended in rejection. That’s the point.


I recently accepted a Staff Software Engineer offer. The clean version of that story is “ran a structured search, scored opportunities, negotiated well, signed.” I packaged the system behind that — the rubric, templates, recruiter replies, and negotiation playbook — as a fork-and-go starter kit: ai-job-search-command-center.

This post is the other version. The one with the rejections in it.

Because here’s what actually happened: across roughly 14 interview processes, I got rejected or ghosted about a dozen times before two offers landed. Abnormal AI, Cohesity, Stripe, Veeam, TrueFoundry, SkyPilot, AlphaSense, Locus, ServiceNow — rejections. Tide and 6sense — silence. Rippling — rejected in a round where I was technically right. Only Suki and JazzX turned into offers, and I walked away from Suki on comp.

If you’re in the middle of a search and getting rejected, I want you to see the whole funnel, not the highlight reel. This is what a real senior-engineer search looks like from the inside: the routine, the prep, the actual questions, the patterns, and the mindset that carried it.

A note on candor: company names are real. Individual interviewers’ names are not — I’ve kept them out. Compensation numbers are not in here either; I’ve kept every salary, offer, and raise figure out of this post. The lessons don’t need the numbers.


The system, in one paragraph

I ran the search out of a single git repo: a profile file the AI assistant reads every session, a scoring rubric (9 weighted dimensions, score-before-you-apply), one tracker sorted by score, a per-company research template, and prep notes. Every opportunity got scored before I invested time; hard-passes (wrong domain, below-level, frontend-heavy, wrong location) got killed in minutes. The whole scaffold is open-sourced at github.com/Swadhin-K/ai-job-search-command-center — fork it. Everything below assumes that scaffolding exists and focuses on what I did inside it.


Engineering my inbound

Here’s something most search advice gets backwards: I barely applied to anything. Twelve of my fourteen processes came from inbound recruiter outreach. That wasn’t luck — it was configured.

  • I tuned my LinkedIn profile to be found. Updated it with accurate, current details and positioned the headline and skills around what I wanted to be approached for — Staff-level distributed systems, AWS, AI/ML platform work. Recruiters search on keywords; I made sure mine matched the roles I wanted.
  • I kept two résumés, not one. A general Staff-engineer résumé, and a separate GenAI-focused résumé that foregrounded my AI/LLM work to attract AI companies. Both were ATS-friendly and tailored per application — no clever formatting that a parser would choke on.
  • I screened companies out as aggressively as they screened me. Frontend-heavy “Staff” roles: declined. Roles where the salary band couldn’t meet my expectations: didn’t proceed. I rejected a real number of companies before any interview happened. (Those don’t get their own section here — but they’re the reason I had time for the fourteen that did.)

The inbound funnel is the highest-leverage thing you can build before a single interview. Spend a weekend on your profile and résumés; it pays off for months.


What I read

Four books and one website did most of the heavy lifting. What mattered wasn’t just reading them — it was watching each one show up in an actual round.

  • The Staff Engineer’s Path (Tanya Reilly) — reframed how I answered behavioral and “what does Staff mean to you” questions. Abnormal, AlphaSense, and every techno-managerial round leaned on this. It’s the difference between “I led a project” and being able to talk about leading without authority, turning around an underperformer, and being the person who makes the team better when you’re not in the room.
  • System Design Interview, Vol 1 & 2 (Alex Xu) — the backbone for the HLD/system-design rounds (Rippling, TrueFoundry, Suki, 6sense, Stripe). Structure, estimation, the standard building blocks.
  • Designing Data-Intensive Applications (Kleppmann) — the why under the patterns. When an interviewer pushes on storage, consistency, or partitioning trade-offs, this is what lets you go deep instead of reciting.
  • Database System Concepts (Silberschatz/Korth/Sudarshan) — paired with my cheat sheets (below), this is what should have saved me in the Stripe telemetry round when I named the wrong database.
  • System Design Handbook — I read its system-design guides regularly throughout the search, not just before a specific round. The GenAI system design interview guide was especially useful for the new-age AI rounds, but I used the whole site broadly.

My daily routine

A search is a months-long effort, and motivation is unreliable. So I ran it on a rotating daily routine instead of willpower. Each day had an assigned focus:

  • Coding days — hand-coding practice (my biggest time sink — more on why below).
  • Reading days — the books above.
  • System-design days — practicing designs out loud with Claude as a sparring partner: pose a prompt, design it, have it pushed back on, refine.

Two pieces of that routine deserve their own callouts.

The hand-coding problem

My single biggest time investment was rebuilding raw, by-hand coding speed — and the reason is a sign of the times. I’ve been using Claude Code / AI-assisted development for so long that my unaided hand-coding had gone rusty. I think and ship in a world where the AI writes the boilerplate. But most interviews don’t live in that world yet (see “old pattern vs. AI-native” below), so I had to deliberately retrain the muscle of writing correct code, fast, in a bare editor, under a clock.

If you’ve been living in an AI-assisted workflow, budget serious time for this. It’s a real skill that atrophies, and most companies still test it directly.

The data-storage cheat sheets

I kept technology cheat sheets — especially for data-storage choices — and reviewed them right before every system-design round. Relational vs. document vs. columnar vs. time-series vs. key-value vs. graph, and when each one wins. This existed specifically because I’d been burned: in the Stripe telemetry round I reached for MySQL when the right answer was a time-series / columnar store. The cheat sheet was my fix so it never happened again.


My prep ritual

For every serious round, I wrote a prep note. Not a vague “review the company” — a structured document. The template:

  1. Research the interviewer, not just the company. LinkedIn, talks, blog posts, anything they’ve written. People interview for what they value. My Rippling note on the hiring manager — a 20+ year infrastructure veteran, polyglot, mentorship-focused, who’d written publicly about large-scale Kubernetes networking — told me to lead with the journey and judgment of my architecture, not just the outcome.
  2. Predict the round format — likely structure and timing.
  3. Map 3–5 of my real stories to what this person probably cares about — pre-written, specific, with the punchline first.
  4. Write the questions I’d ask back (see below — this turned out to be one of my highest-leverage moves).

Designing questions that make the interviewer want to talk

This is the non-obvious one. I treated the questions I asked the interviewer as a designed artifact, derived from Claude research on both the company and the specific person. Each question was engineered to do three things at once:

  1. Teach me about the company — what they’re building, what greenfield projects are starting, where the roadmap is going.
  2. Give the interviewer a chance to brag — people light up when you’re genuinely curious about work they’re proud of. A well-aimed question turns an interrogation into a conversation.
  3. Reveal their culture to me — the way they answer tells me whether I’d want to work there.

The clearest payoff: in the JazzX VP round, after the formal part wrapped early, I spent the remaining time asking how they handle migrations for in-flight agentic loops. The VP lit up and engaged hard. Those questions did as much for the verdict as any answer I’d given. Asking great questions isn’t the polite closer — it’s part of the evaluation, in both directions.


The 14 companies, chronologically

Dates are approximate, and I’m certain there were a few more processes I’ve simply forgotten. Here’s the funnel as I remember it — sourced, rounds, the real questions, the outcome, and the lesson.

1. Abnormal AI — rejected after HM (early)

Inbound recruiter on LinkedIn; one of my first processes.

  • Coding (medium): a JSON-handling problem — data extraction, string manipulation, parsing/transforming.
  • Hiring manager (rapid-fire):
    • “Describe a challenging project” → deep project follow-ups.
    • “Your Lambdas are failing because that entire region’s Lambda service is down — how do you handle it? What are the trade-offs?”
    • “As a Staff engineer, how do you get an underperformer to perform? How do you lead without authority?”
    • “Describe an LLD you’re proud of.”

I’d barely started preparing, and I answered the behavioral questions abstractly. Lesson — and it reshaped my entire prep: never answer behavioral questions in generic, abstract terms. Use specific, real situations. Genuineness comes from detail.

2. Cohesity — rejected after HM (early)

Inbound recruiter. A coding round (a shortest-path problem — cleared it) and a hiring-manager round on work experience. Early-search, thin prep, rejected. Logged here for honesty: the early ones blur together because I hadn’t yet built the prep machine.

3. Stripe — rejected after full loop (~March)

Referral. Stripe has a distinct style worth internalizing: every round has 2–3 levels of follow-ups, you must finish the first part fast to unlock the next, and they care about working code above all — even if it’s not the most efficient.

  • Screening (2 coding rounds, both cleared): (1) deduplication of merchant entities with confidence scoring; (2) masking logs containing sensitive PII.
  • Bar-raiser coding: LLD for a task-scheduling + task-executor system.
  • Bug squash #1 (Scala): a cats library with a streaming issue. This went badly — sbt and Scala-version mismatches ate my clock. I fixed the first bug but they wanted two more levels.
  • System design: a telemetry/metrics service collecting data from all services and surfacing it to developers. Went well overall — but I named MySQL when the right answer was a time-series / columnar store.
  • Bug squash #2 (Python): a function-calling bug. Fixed it, but debugging took too long to reach the deeper levels.

Rejected, no reason given. Lessons: speed unlocks depth; be excellent in Python, not just Scala (the toolchain friction was self-inflicted damage); name the exact database technology; and pre-test your environment so version mismatches don’t silently burn your time.

4. Suki — offer, declined on comp (~March–April)

Inbound LinkedIn recruiter; healthcare/ambient-voice AI. My first offer.

  • Coding (in Google Docs): balance a binary tree.
  • LLD: a customer + subscription + usage-based billing system.
  • Onsite, round 1 — system design: stream third-party voice (a Zoom doctor↔patient conversation), collect it, convert to transcript, summarize, diarize it, and write it into a third-party EHR.
  • Onsite, round 2 — HM: STAR stories with cross-questioning.

They made an offer; it couldn’t meet my number, so I declined. Lesson: reaching an offer and then walking on comp is a disciplined win, not a failure — the floor exists precisely so a sub-floor offer is an easy no. (It also becomes leverage: a real offer in hand changes how you carry yourself everywhere else.)

5. Veeam — rejected (~April)

Inbound recruiter.

  • Round 1 — design: a program for file deduplication in a filesystem, where files can be huge (GBs–TBs). Designed it correctly; cleared.
  • Round 2 — coding: two-step processing of events, efficiently and with good failure recovery.

Rejected — most likely because closing the gaps in my implementation took several iterations. Lesson: in a timed coding round, repeatedly patching gaps reads as not having a plan. Think the edge cases and failure-recovery through before you start typing.

6. TrueFoundry — rejected after founder round (~April)

Inbound recruiter.

  • LLD: a system processing jobs from a queue with dynamic mid-flight re-prioritization — low-priority jobs can become high-priority and must then be processed faster. Went really well.
  • HLD: an AI/LLM gateway (mirroring their own product). Went really well.
  • Founder round: complex-systems discussion, then a ride-hailing system design. Clean overall — until the geo-fenced rider↔driver matching. The founder wanted the exact lat/long algorithm, and I gave vague answers instead of naming geohashing / quadtrees / S2 / H3 cells and Haversine distance.

Rejected; the geo-matching gap was the pivot. Lesson: for geospatial/matching design, know the algorithm by name and mechanics. (Same shape as the Stripe database miss — interviewers probe for the precise technique, not a hand-wave.)

7. Tide — no response (~April)

Inbound recruiter. A single code-review round: review a Python controller that handles paying a bill. I produced 24 review comments, categorized by priority, and when asked “what’s the one thing you’d fix first,” answered with the highest-leverage items — multi-tenancy fixes, ORM usage, dependency injection, a thread-pool executor, separation of concerns.

It went well; I never heard back — likely the role got filled. Lesson: a strong code-review answer prioritizes and can name the single highest-impact fix on demand. And silence usually isn’t about you.

8. SkyPilot — rejected (~April)

Reachout via the Weekday recruiting team.

  • Hiring manager: experience-based STAR questions.
  • Python bug squash: event handling — an event dispatcher / scheduler. I completed it, but more was expected (deeper levels than I reached).

Rejected. Lesson — by now a clear pattern: in bug-squash rounds (Stripe, Veeam, SkyPilot), completing the obvious fix isn’t enough. They expect you to go deeper and faster. Python fluency on event/scheduler code is a repeated bar.

9. 6sense — no response (~April–May)

Inbound recruiter.

  • Coding: a standard dynamic-programming problem; cleared.
  • System design (~1.5 hrs): an interview-scheduling system, both HLD and LLD in one round.

Never heard back. Another “silence ≠ verdict” data point, and a reminder that some rounds combine HLD and LLD into one long sitting.

10. AlphaSense — rejected after HM (~April–May)

Inbound reachout. A single hiring-manager round: my latest AI projects, production incidents I’d faced and how I handled them, and the scope of my Staff role at Zomentum. Rejected. Short, but a reminder that a single HM conversation can be the whole bar — and that incident stories need to be ready.

11. ServiceNow — rejected (~April–May)

The one process I applied to directly (everything else was inbound).

  • Proctored online test (~1 hr): (1) count the leaves blown off a 2D grid given wind directions as a string; (2) string compression/decompression; (3) MySQL multiple-choice questions. Cleared all of it.
  • Virtual round 1 — coding: topological sort — order letters from given word pairs (alien-dictionary style).
  • Virtual round 2 — coding: BFS on a tree. The interviewer was very strict, required their HackerRank link, wouldn’t allow an IDE, and the program wouldn’t run because of a HackerRank bug. I lost the round fighting the tooling; the rejection arrived about two hours later.

There was also a level-downgrade move worth naming: despite ~10 years of experience, the recruiter said they wouldn’t count my Wipro tenure (because it’s a “service company”), effectively treating me as ~7.5 years and trying to down-level me. Lessons: insist on (and pre-test) the coding environment — confirm whether you can use your own IDE before the round — and push back early when a company tries to discount your experience to under-level and underpay you.

12. Rippling — rejected after the HM round (and I was right) (~April)

Inbound LinkedIn recruiter; Staff Engineer, Infrastructure (CodeShip).

  • Coding (LLD): design an invoicing system. Went well.
  • System design: a high-traffic system that processes and syncs data into the system (high-throughput ingestion + sync).
  • Hiring manager (a Director of Infrastructure): present a complex project. I walked through my distributed-systems architecture: events → callback server → SQS → Lambda.

This became a stress round. The manager repeatedly challenged why I’d built any of it instead of just scaling the service vertically — “throw money at the problem, build first, engineer later.” I defended the reasoning; he turned hostile, said it was the wrong move, that “management should have questioned my motive.” Then he claimed the parallelism in my design was wrong — and on that he was simply mistaken. I held my ground: I’d tested it, it had run reliably in production. He kept insisting; I had to firmly refute him with evidence.

Rejected shortly after. I’m including this one deliberately: sometimes you can be technically correct and still get rejected. Fit, mood, and a single interviewer’s bias are real. Lesson: be ready to defend your design with zero hesitation and refute pushback with proof — but also accept that not every rejection is a referendum on your competence.

13. Locus — rejected (~May)

Inbound recruiter; Staff Engineer, Backend Platform.

  • Coding — BFS: shortest path across a 2D grid while avoiding landmines (obstacles). Cleared it.
  • Hiring manager: experience questions; the pivot was how I designed and deployed the distributed-system architecture.

Rejected, with refreshingly direct feedback: Scala is a stack mismatch for them, and they wanted a better-designed STAR story for the architecture narrative. Lesson: stack mismatch is a real, stated rejection reason (Scala worked against me more than once), and STAR stories must be designed, not improvised — even strong underlying work reads weak through a loose narrative.

14. JazzX AI — offer, accepted ✅ (May)

I applied via LinkedIn. SAIGroup-backed, building a mortgage/financial AI platform. Six rounds:

  1. HM: standard experience questions, but most of the time went to me understanding the company — the hiring manager walked through what they do and where they’re headed. More mutual fit than grilling.
  2. AI system design (Senior Staff Engineer): design an AI-native system that ingests financial inputs — receipts, handwritten docs, scanned docs, Excel — and reconciles them into the customer’s accounting system. I covered graceful recovery, retries, and evals as first-class concerns.
  3. Python coding with Claude Code: given a complex Python codebase, read it, find what to improve, and prompt/pair with Claude to bring it to production grade. I drove fixes for dependency injection, a thread-pool executor, Gunicorn integration, Pydantic models, separation of concerns, ORM usage, and SQL-injection prevention. (The same class of fixes I’d rehearsed for Tide’s code-review round — prep compounds.)
  4. Techno-managerial (Senior Engineering Manager): entirely situational/philosophical — how I’d handle various hypotheticals, answered with real examples from my current org.
  5. Techno-managerial (VP): similar — and after he finished early, I used the rest of the time on the interviewer questions I’d designed. My questions about migrating in-flight agentic loops made him light up; he engaged actively. A turning point.
  6. CTO round — waived: a day before it was scheduled, the CTO read the feedback, said he didn’t need the round, and rolled out the offer directly.

Negotiation: the first offer was already in a happy range and above my floor. I didn’t take it — I countered anyway. After about two weeks, they came back meaningfully higher, and I signed.

Lessons: AI-native interviews are real now (designing with evals and graceful recovery; pair-coding with Claude on a real codebase); always counter, even a good offer — it moved with zero downside; and the questions you ask back are a signal, not a formality.


Patterns across 14 interviews

Pull back from the individual companies and the same lessons repeat. These are the ones I’d tattoo on a new candidate:

  1. Behavioral answers must be specific and designed, not abstract. Abnormal taught it; Locus confirmed it. Pre-write your stories, lead with the punchline, anchor every claim in a real situation.
  2. Speed unlocks depth. Especially at Stripe, finishing the first part fast is what reveals the follow-ups. Slow-but-correct still caps your score.
  3. Bug-squash rounds expect more than the obvious fix. Stripe, Veeam, SkyPilot all wanted deeper levels, faster. Practice debugging unfamiliar code under a clock.
  4. Name the exact technology or algorithm. The right database (time-series/columnar, not “MySQL”); the right geo algorithm (geohashing/quadtree/S2/H3/Haversine, not “I’d index by location”). Cheat sheets fix this.
  5. Python beats Scala for timed rounds. Scala became a stated stack-mismatch rejection reason (Locus) and a self-inflicted toolchain tax (Stripe). Default to Python.
  6. Defend your design with proof under pressure — and know that being right isn’t always enough. Rippling.
  7. Pre-test your tooling. Version mismatches (Stripe) and a buggy mandated HackerRank with no IDE allowed (ServiceNow) can sink an otherwise-fine round.
  8. Push back on down-leveling. Some companies discount “service-company” tenure to under-level and underpay you (ServiceNow). Catch the level framing early.
  9. Silence isn’t a verdict. Tide and 6sense both went well and went quiet. Roles freeze and fill. Don’t over-read it.

The old pattern vs. the AI-native pattern

The most interesting thing I learned is that the industry is mid-split into two interview worlds:

  • The old pattern (most companies): data-structures-and-algorithms, code by hand, no AI allowed. This is still the majority, and it’s why I spent the most time rebuilding raw hand-coding speed.
  • The AI-native pattern (newer AI companies): they hand you a real codebase and a tool like Claude Code and evaluate whether you can drive an AI to production-grade output — plus AI system design with evals and graceful recovery as first-class concerns. JazzX’s loop was the clearest example.

These test almost opposite skills. The old world rewards unaided recall and speed; the new world rewards judgment, code review, and prompting. For now, you have to be ready for both — keep your by-hand muscle sharp for the majority, and practice driving AI well for the future-leaning minority.


Negotiation

Two offers, two very different endings — and the same discipline behind both.

Decide three numbers before any offer call: a walk-away floor (below it you decline and disengage), a target (the number you’d accept with no regret), and an anchor/stretch (what you quote first, leaving room for them to negotiate down and feel they won).

  • Suki came in below my floor. The floor existed precisely so this was an easy, non-agonized no. I declined politely and kept the relationship warm.
  • JazzX came in above my floor and in a happy range — and I still countered once. The first offer is rarely the last, and the downside of a single polite counter is essentially zero. It moved meaningfully in my favor.

The supporting moves that mattered: don’t anchor on your current comp — redirect to “market rate for this level and my other active processes.” Invoke your process truthfully — having a real Suki offer and live pipelines let me negotiate as someone the market wanted, not someone asking for a raise. Always counter, then stop talking — silence does the work. And get every verbal commitment into email before you sign.

What never to say: “my current is X and I want a Y% hike” (kills your leverage), “I really want to join” (signals you’ll take less), “can you match company Z” (anchors them to Z — say “exceed market for this profile” instead), and “I’ll think about it” with no deadline (wastes your only time pressure).


The mindset that actually carried it

Here’s the part the system essay can’t give you. Look at the funnel again: of fourteen processes, roughly twelve ended in rejection or silence. Abnormal, Cohesity, Stripe, Veeam, TrueFoundry, SkyPilot, AlphaSense, Rippling, Locus, ServiceNow — no. Tide, 6sense — silence. Two offers. One signed.

Rejection is the default, not the exception. When you internalize that, each individual no stops feeling like a verdict on your worth. It’s the funnel doing what funnels do.

The dangerous part isn’t the rejection — it’s what rejection tempts you to do: lower your bar. After a string of nos, the instinct is to loosen your hard-passes, entertain the sub-band offer, take the off-profile role “just to have something.” Don’t. Keep screening companies aggressively even while you’re getting rejected. Desperation leads to bad-fit acceptances you’ll regret in six months. The floor and the hard-passes exist for exactly these low-morale moments — that’s when they’re worth the most.

Believe in the process. The system works on a portfolio basis: most individual bets fail, and you only need the right one to land. Stay aggressive, hold your standards, keep showing up to the routine. The offer that matters is usually a few rejections away from where you almost gave up.


What I’d do differently

  • Rebuild hand-coding speed before starting interviews, not during. It was my biggest time sink and I learned it mid-search.
  • Pre-test every coding environment and confirm IDE rules up front (looking at you, ServiceNow).
  • Talk to a current engineer off the record before the final round, not after the offer — fifteen minutes on LinkedIn tells you more about culture than any review site.
  • Start the highest-scoring processes first, so offers have a chance to land together. Timing is leverage, and it’s mostly a scheduling problem.
  • Don’t over-invest in companies that smell like a stack mismatch. Scala-vs-their-stack cost me rounds; I should have read that signal earlier.

Appendix

Per-interview prep-note template

# {Company} — {Round} Prep

## Interviewer: {name}

- Background / tenure / what they've written or spoken about
- What they likely value (→ what they'll probe)

## Likely round format

- {coding / LLD / HLD / bug squash / code review / HM / techno-managerial / AI-native}

## My stories mapped to this round (punchline first)

1. {topic} → {specific situation, action, result}
2. ...

## Questions I'll ask (designed to: learn + let them brag + reveal culture)

- {question from research on the company}
- {question from research on the interviewer's work / greenfield projects}

## Cheat-sheet to review right before (esp. data storage)

- {relational / document / columnar / time-series / KV / graph — when each wins}

Offer & negotiation checklist

## Before the call — three numbers

- Walk-away (floor): *** Target: *** Anchor/stretch (quote first): \_\_\_

## On the call

- [ ] Don't anchor on current comp — redirect to "market rate + my active processes"
- [ ] Quote the stretch when asked for expectations
- [ ] Always counter once, even on a good offer — then stop talking
- [ ] Don't accept a number on the call; ask to review components

## Levers beyond base

- [ ] Sign-on bonus - [ ] Title/level bump - [ ] Larger/accelerated equity
- [ ] Annual equity refresh (in writing) - [ ] Year-1 bonus guarantee

## Lock it in writing

- [ ] Email a restatement of every component; request the formal letter
- [ ] Read the fine print: vesting/cliff, non-compete, clawback, notice

If you’re in the middle of the funnel right now and it’s all rejections: that’s what mine looked like too, right up until it wasn’t. Hold your bar. Keep showing up. Believe in the process.

Back to Blog

Related Posts

View All Posts »

Making an LLM Agent Production-Grade

The unglamorous half of shipping Zoe: poisoned conversations that 400 forever, duplicate edits from retries, tool timeouts, rate limits, tracing, and the prompt caching and telemetry that made it affordable and debuggable.

Designing Tools an LLM Can Actually Use

The tool layer, not the prompt, is where an agent behaves or misbehaves. Lessons from building Zoe's tools: uniform pagination, broaden-on-empty hints, read/write parity, and treating the system prompt as policy.

Giving an LLM Agent Hands

Notes on turning Zoe from a copilot that talks into one that edits the document you are looking at — the bridge, reviewable edits, and the bugs that came from a model acting on stale context.