Senior engineers aren’t paid to write more complicated SQL. They’re trusted to understand what happens when a perfectly valid change meets a database that never stops receiving traffic.

A database migration can pass every automated test, work perfectly in staging, and still bring a production release to a standstill. The SQL might be correct. The application might compile without warnings. Even the deployment pipeline can report success while requests begin accumulating behind a database lock.

This is one of my favorite examples of how engineering experience changes the way you look at ordinary code. Early in your career, you want to know whether a migration works. Later, you become interested in what happens while it works, how long it takes, and whether the previous application version can survive the change.

Those questions sound less exciting than designing another distributed system. They’re also the questions that keep customers from discovering your database migration before your monitoring system does.

A Harmless Column Rename

Imagine you’re working on an order-processing platform built with Spring Boot and PostgreSQL. The orders table contains 80 million rows, and several application instances continuously read and update order records. A developer wants to rename customer_id to buyer_id. The change makes sense because the business has introduced a distinction between buyers and account owners.

The migration looks innocent:

ALTER TABLE orders
RENAME COLUMN customer_id TO buyer_id;

The statement is usually quick because PostgreSQL doesn’t need to rewrite every row just to rename a column. That makes the change attractive, especially when a team wants to keep its migration scripts small. But a quick metadata change can still require a strong lock. If another transaction is holding a conflicting lock, the migration may wait. Requests arriving behind that waiting migration can then become blocked as well.

Now consider the deployment itself. During a rolling release, some application instances still execute queries referencing customer_id, while newer instances expect buyer_id.

One schema change has created an application compatibility problem. The SQL was valid. The release plan was incomplete.

The Real Problem Is That Production Runs Multiple Versions of Reality

Developers often imagine deployments as a clean transition. Version 1 disappears, version 2 appears, and the database moves to the new schema at the same moment.

Real deployments are messier.

Kubernetes may run old and new pods simultaneously. Background workers can continue processing jobs created before the release. A delayed message may be consumed by application code that still expects the previous data model. Rollback makes the situation even more interesting.

Suppose the new application starts writing data using buyer_id, and an unrelated defect forces you to roll back the deployment. If the old application expects customer_id, restoring the previous container image won't necessarily restore service.

A rollback that requires reversing a database migration is considerably more dangerous than rolling back application code. This is why experienced engineers separate schema evolution from application deployment whenever compatibility matters.

Expand, Migrate, Contract

One practical approach is the expand-and-contract pattern.

Instead of immediately renaming the existing column, you introduce a new column while preserving the old one.

ALTER TABLE orders
ADD COLUMN buyer_id BIGINT;

At this point, old application instances can continue reading customer_id. Newer code can be deployed with awareness of both fields.

The next challenge is keeping the values consistent. Depending on the workload, you might temporarily write both columns, use a carefully designed database trigger, or establish a controlled synchronization mechanism. Each option has consequences, particularly when old application instances are still updating records.

For example, application-level dual writes inside one database transaction can keep two columns consistent for that operation. But if old instances continue writing only customer_id, the new field may become stale unless the migration plan accounts for those writes. After establishing a reliable synchronization strategy, you can backfill historical records in manageable batches.

Only after verifying the new column’s completeness and switching all readers should you consider removing the old one. The extra steps can feel tedious when the original request was simply to rename a field. But the purpose is to avoid forcing every application component to change simultaneously.

That flexibility becomes extremely valuable when something goes wrong.

Backfilling 80 Million Rows Is a Production Workload

A backfill is easy to underestimate because the SQL is straightforward.

UPDATE orders
SET buyer_id = customer_id
WHERE buyer_id IS NULL;

On a table containing 80 million records, executing this as one enormous transaction can generate substantial WAL, hold row locks, create dead tuples, increase replication lag, and put pressure on vacuum processing. The exact impact depends on row size, indexing, update patterns, database capacity, and transaction duration. Still, it’s a workload worth planning rather than casually attaching to a deployment.

A safer approach often involves bounded batches, short transactions, progress checkpoints, and deliberate throttling.

You might process records in primary-key ranges and monitor database CPU, I/O, WAL generation, replication lag, and application latency between batches.

There’s another subtle issue. If the backfill and live application writes can modify the same records, you need to define which value wins and how consistency is maintained. Finishing every batch doesn’t prove the migration is correct. You also need verification that new writes remain synchronized and historical records satisfy the intended invariant.

Adding an Index Can Be More Dangerous Than the Query You’re Fixing

Suppose the new application frequently searches orders by buyer_id.

A developer notices that the query is slow and adds an index:

CREATE INDEX idx_orders_buyer_id
ON orders (buyer_id);

On a busy PostgreSQL table, a conventional index build can block writes for the duration of the operation.

PostgreSQL provides concurrent index creation to reduce that disruption:

CREATE INDEX CONCURRENTLY idx_orders_buyer_id
ON orders (buyer_id);

This is often a better option for a live production table, but it isn’t free. Concurrent index creation performs additional work, can wait for existing transactions, and may leave an invalid index if the operation fails.

It also cannot run inside a transaction block, which matters when your migration framework wraps every migration in a transaction by default. An experienced engineer should know how their migration tooling executes SQL before placing that statement in a release.

A correct database command can still be deployed incorrectly.

The Interview Question I’d Ask a Senior Candidate

If I were evaluating a Senior backend engineer, I’d give them this scenario:

Your team needs to change the structure of a table containing 80 million rows. The application must remain available, multiple service versions may run during deployment, and a rollback must remain possible. I’d be interested in how the candidate approaches the problem before writing SQL.

Do they ask about the PostgreSQL version and current traffic? Do they investigate long-running transactions and replication lag? Can they explain which changes are backward compatible and how they’ll verify data consistency?

I’d also want to hear about deployment sequencing.

The candidate should understand why dropping the old column belongs near the end of the migration, after old application versions and background consumers no longer depend on it. For a Staff-level discussion, I’d introduce additional complications. Several teams own consumers of the same data, one integration cannot be upgraded for six weeks, and the database team is concerned about storage growth during the transition.

Now the challenge involves coordination and technical judgment across organizational boundaries.

There’s no single SQL statement that resolves those constraints.

What I’d Check Before Approving the Release

Before approving a production migration, I’d want a clear answer to a few operational questions.

First, which locks can the migration acquire, and what happens if it waits behind an existing transaction? A short lock_timeout may be appropriate for certain DDL operations because failing quickly can be safer than allowing a migration to queue behind a busy production workload. Second, how will we measure progress and detect damage? Database metrics should be considered alongside application latency, error rates, replication health, and connection pool behavior.

Finally, what does rollback actually mean? If the old application can run against the expanded schema, rollback may be relatively straightforward. If the migration has already removed data or changed its meaning, restoring the previous application version might accomplish very little.

These questions deserve answers before the deployment begins. Nobody enjoys discussing rollback plans during a successful release. People become considerably more interested when the release stops being successful.

You Probably Know More Than Your Interviews Are Revealing

Database migrations are also a useful reminder for engineers preparing for Senior and Staff interviews. You may already have experience with lock contention, production incidents, difficult rollouts, and data consistency problems. Yet if you describe that work as “I updated the schema and deployed the service,” an interviewer will never understand the engineering judgment involved.

Try reconstructing one difficult change from your own career.

Explain the original constraints, the failure modes you considered, and the reasons behind the implementation. Discuss what could have gone wrong during deployment and how you would have recovered.

If you haven’t worked on a migration at this scale, you can still practice the scenario. Read the database documentation, build a smaller environment with concurrent traffic, and observe what happens when transactions and schema changes compete for locks. That kind of preparation develops useful production knowledge while giving you stronger material for technical interviews.

A Senior offer shouldn’t depend on how many architecture diagrams you can memorize. Your ability to explain the consequences of engineering decisions deserves to be visible, and practicing that explanation is worth the effort.

Free Resources and Early Access

Subscribe to My Substack

I publish deeper engineering articles about Java, Spring Boot, distributed systems, production failures, and Senior/Staff system design interviews. You can follow and subscribe for free here:

Devrim Ozcay | ProdRescue | Substack

Download My Free Senior Engineer Interview Playbook

I’ve created five practical guides covering a 45-minute system design framework, production incident response, architecture decisions, and engineering career preparation. The 27-page collection is completely free.

Senior Engineer Interview Prep: Free 45-Minute System Design Framework + 5 Practical Guides

Help Shape the ProdRescue AI Interview Platform

I’m researching why experienced engineers struggle with system design interviews, technical evaluations, and Senior/Staff job offers. If you’ve faced those problems, I’d appreciate your feedback. The survey also gives you the option to express interest in early beta testing.

The SQL Migration That Works in Staging Can Destroy Your Production Release was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.

I knew Kafka, PostgreSQL, Redis, and microservices. Then an interviewer asked what would happen if a payment succeeded but the response never reached the client. That question exposed a problem no architecture diagram had prepared me for.

The first time I was asked to design a payment system in a technical interview, I thought I had done reasonably well. I clarified the requirements, estimated traffic, introduced a PostgreSQL database, and explained how asynchronous processing could reduce the amount of work performed during an HTTP request. I even discussed horizontal scaling before the interviewer asked about it, which felt like the sort of initiative senior candidates were supposed to demonstrate.

Then he interrupted me with a question that sounded almost insulting in its simplicity.

“Your service successfully charges the customer, but the client times out before receiving the response. What happens when the client retries?”

I explained that the API should be idempotent. He nodded and asked how I would implement that guarantee when two requests carrying the same idempotency key arrived simultaneously on different application instances.

I started describing a Redis lock. He asked what would happen if the instance holding the lock crashed after the payment provider completed the charge but before our database recorded the result. My carefully drawn architecture was still sitting on the whiteboard, looking considerably more confident than the engineer standing beside it.

That interview changed how I thought about system design preparation. I had spent too much time studying what successful architectures looked like and too little time understanding how those architectures behaved when operations failed halfway through.

The distinction matters because Senior and Staff System Design interviews are increasingly difficult once the conversation moves beyond choosing components. The interviewer wants to know which guarantees your system provides, where those guarantees stop, and whether you understand the operational consequences of your decisions.

Why Senior Software Engineers Fail System Design Interviews

A surprising number of experienced backend developers prepare for system design interviews by studying completed architectures. They learn how to design a URL shortener, a notification service, a distributed cache, or a messaging platform. After enough practice, the components become familiar, and the candidate begins recognizing patterns before the interviewer has finished describing the problem.

That familiarity is useful, but it can create false confidence.

A diagram showing an API gateway, application services, Kafka, Redis, and PostgreSQL tells an interviewer very little about how the system handles partial failures. The same components can support a reliable architecture or an operational disaster depending on transaction boundaries, retry policies, data ownership, and recovery behavior.

Consider a notification service that sends email, SMS, and push notifications. A candidate might propose publishing messages to Kafka and allowing independent consumers to process each delivery channel. The design looks scalable, and separating the consumers makes sense.

Now imagine the email provider starts returning HTTP 429 responses.

The consumer retries immediately, the provider continues rate-limiting, and the backlog grows. Increasing the number of consumers only makes the provider reject requests faster. Meanwhile, messages that have already been delivered may be processed again after consumer failures.

The interviewer has learned much more from those five minutes of discussion than from the original diagram.

They can see whether you understand backpressure, exponential backoff, dead-letter handling, idempotency, and the difference between accepting work and successfully completing it.

Those details are where senior-level engineering judgment becomes visible.

The First 90 Seconds of a System Design Interview Matter More Than Most Candidates Realize

I used to begin architecture discussions by drawing components almost immediately. It felt productive because I was giving the interviewer something concrete to react to, and I wanted to demonstrate that I understood the technologies involved.

The problem was that I often committed to an architecture before understanding the constraints.

Imagine being asked to design a payment processing platform. You might immediately introduce Kafka to decouple services, Redis to reduce database reads, and a microservices architecture to allow independent scaling.

Then the interviewer explains that financial operations require strict accounting invariants, duplicate charges are unacceptable, and every payment must remain auditable.

Those requirements change the discussion.

Before drawing the architecture, I now prefer to establish the business operation, its consistency requirements, expected traffic, and acceptable failure behavior. I want to know whether the system processes actual money, whether it coordinates with external payment providers, and what the user should observe when a request has an uncertain outcome.

For example, these two requirements sound similar but lead to different designs:

Requirement A: The platform must accept 50,000 payment requests per second.

Requirement B: The platform must accept 50,000 payment requests per second while ensuring that retries cannot create multiple logical charges for the same operation.

The first requirement primarily raises questions about throughput and scalability. The second introduces durable idempotency, concurrency control, external-provider semantics, and recovery from ambiguous outcomes.

A strong opening establishes which problem you’re actually solving.

I would rather spend the first two minutes discovering a constraint that changes the architecture than spend twenty minutes defending components I never needed.

System Design Interview Scenario: Design a Payment System That Survives Retries

Let’s build the payment example more carefully.

A client sends a request to create a payment. The backend validates the request, records the payment attempt, and calls an external payment provider. If the provider confirms the charge, the backend updates the payment state and returns a successful response.

Under normal conditions, the workflow is straightforward.

The difficult cases appear when a network connection fails, the application crashes, or two requests race against each other.

Failure 1: The Client Retries the Same Payment

Suppose the client sends the following request:

POST /payments
Idempotency-Key: order-7821-payment

{
  "orderId": "7821",
  "amount": 12500,
  "currency": "USD"
}

The amount is expressed in minor currency units, so 12500 represents $125.00.

The server processes the payment successfully, but the response is lost. The client retries with the same idempotency key, expecting the original result.

A naive implementation could charge the customer twice.

The first improvement is to persist an idempotency record associated with the operation. The record should capture the request fingerprint, processing state, and eventual result so that repeated requests can be handled consistently.

A simplified PostgreSQL schema might look like this:

CREATE TABLE payment_requests (
    id BIGSERIAL PRIMARY KEY,
    idempotency_key VARCHAR(128) NOT NULL UNIQUE,
    request_hash VARCHAR(64) NOT NULL,
    status VARCHAR(24) NOT NULL,
    provider_reference VARCHAR(128),
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

The unique constraint matters because two application instances can receive the same request concurrently. A database-enforced uniqueness guarantee gives us a durable coordination point that an in-memory check cannot provide.

However, that still doesn’t solve the entire problem.

We need to decide how to handle a duplicate request while the first attempt is processing. We also need to reject reuse of the same key with a different request payload, and define what happens when the original operation has an uncertain outcome.

An interviewer who asks about idempotency is often interested in those details.

Failure 2: The Payment Provider Succeeds, but Our Service Crashes

This is where many otherwise convincing designs begin to fall apart.

Assume our service sends a charge request to the payment provider. The provider processes the payment, but our application crashes before persisting the successful result.

After restarting, our database still shows the payment as processing.

Should we retry the provider call?

If the provider supports durable idempotency keys, we can use the same provider-level key when retrying. That can prevent the provider from creating a second charge, subject to its documented idempotency behavior and retention period.

If the provider does not offer that guarantee, blindly retrying may be unsafe.

We may need to query the provider using a stable payment reference, reconcile the external outcome, or move the operation into an uncertain state that requires further investigation.

This is an important distinction in distributed systems: a timeout does not prove that an operation failed.

It proves that the caller did not receive a definitive response within the expected time.

That difference has serious consequences when the operation transfers money.

A database transaction cannot automatically make a remote payment provider participate in the same atomic commit. We need an explicit protocol for handling the boundary between our database and the external system.

The interviewer doesn’t need you to invent a perfect distributed transaction protocol in forty-five minutes. They need to see that you recognize the failure boundary and can explain a recovery strategy consistent with the business requirements.

Failure 3: Two Application Instances Process the Same Request

Now assume the system runs across several Kubernetes pods.

Two identical requests arrive at nearly the same time. Both instances check whether the payment has already been processed, and both initially see no completed record.

If our implementation performs a read followed by an unprotected insert, both requests may proceed toward the external provider.

A unique constraint can prevent duplicate idempotency records, but the application must structure its workflow so that only the instance that successfully claims the operation is allowed to initiate the charge.

That may involve an atomic insert, conditional state transition, or another database-backed coordination mechanism.

Redis can be useful for some forms of coordination, but a temporary Redis lock alone is not a durable payment guarantee. Lock expiration, process crashes, and network partitions all complicate its behavior.

The correct design depends on what the database guarantees, how the provider handles retries, and which state transitions must be recoverable.

This is the kind of explanation that demonstrates experience beyond memorizing architectural patterns.

Why Adding Kafka Doesn’t Automatically Make a System Reliable

Kafka appears in an enormous number of system design interview answers. Candidates often introduce it because they want to demonstrate scalability, asynchronous processing, and loose coupling.

Those are legitimate reasons to use a message broker.

But a message broker also introduces new failure modes.

Imagine a payment service that updates PostgreSQL and then publishes a PaymentCompleted event. The database transaction commits successfully, but the service crashes before publishing the event.

The payment exists, yet downstream systems never receive the notification.

Reverse the order and publish the event first. Now the event may be consumed even though the database transaction later rolls back.

A common solution is the transactional outbox pattern.

The application writes the business state change and an outbox record within the same local database transaction. A separate publisher reads committed outbox records and sends the events to the broker.

That addresses the atomicity gap between the local business update and recording the intent to publish.

It doesn’t eliminate duplicate event delivery.

If the publisher sends an event successfully but crashes before marking the outbox record as published, the event may be sent again after recovery.

Consumers therefore need appropriate idempotency or deduplication strategies.

A simplified architecture looks like this:

Client
  |
  v
Payment API
  |
  v
PostgreSQL Transaction
  |-- Payment State
  |-- Outbox Event
  |
  v
Outbox Publisher
  |
  v
Message Broker
  |
  v
Idempotent Consumers
  |-- Notifications
  |-- Reporting
  |-- Reconciliation

The important part of this diagram isn’t Kafka or PostgreSQL. It’s the reasoning behind the transaction boundary and the recovery behavior.

When an interviewer asks why you introduced a message broker, explaining throughput is only part of the answer. You should also be able to describe ordering requirements, retry behavior, consumer lag, poison messages, and the operational cost of maintaining the messaging infrastructure.

Sometimes a simpler synchronous workflow is sufficient.

Choosing that simpler design can be a stronger senior-level decision than introducing distributed infrastructure without a compelling requirement.

The Redis Failure Question That Exposes Weak Architecture Decisions

Another common system design interview pattern involves caching.

The candidate introduces Redis to reduce database load. The interviewer asks what happens when Redis becomes unavailable.

A typical answer is to fall back to PostgreSQL.

That sounds reasonable until the interviewer explains that PostgreSQL cannot handle the additional traffic.

Now the recovery mechanism may trigger a second outage.

This is a cache stampede problem, and it illustrates why failure handling must be considered alongside normal operating performance.

A more complete discussion should consider bounded concurrency, request coalescing, stale data policies, circuit breakers, and load shedding. The appropriate combination depends on whether the cached data can safely become stale and how much degradation the product can tolerate.

For a public product catalog, temporarily serving stale information may be acceptable.

For an account balance used to authorize a financial transaction, stale data may be unacceptable.

The same technology can be correct in one architecture and dangerous in another.

Experienced interviewers are interested in whether you can identify that difference without being handed the answer.

Senior vs. Staff Engineer System Design Interviews: What Actually Changes?

Senior and Staff interviews often cover similar technologies. The difference is usually in the scope of the decisions you’re expected to make and the consequences you’re expected to consider.

A Senior Engineer may be asked to design a reliable service, explain its scaling strategy, and handle expected failure scenarios. A Staff Engineer may face additional questions about organizational boundaries, migration strategy, operational ownership, and how the design evolves across multiple teams.

Consider a company moving from a modular monolith to microservices.

A candidate can draw the proposed target architecture with independent services and asynchronous communication. That is relatively easy.

The difficult questions concern the transition.

How do you migrate data ownership without breaking existing workflows? How do you avoid introducing distributed transactions into operations that were previously atomic? What happens when different teams deploy incompatible changes, and who is responsible for investigating incidents that cross service boundaries?

A Staff-level answer should account for migration risk, team coordination, observability, and the cost of operating the new architecture.

Sometimes the best recommendation is to postpone the migration.

A modular monolith with clear boundaries may satisfy the company’s requirements with less operational complexity. If the organization cannot articulate which constraints require independent deployment or scaling, introducing microservices may create more problems than it solves.

That judgment is difficult to demonstrate if your interview preparation consists entirely of reproducing popular diagrams.

How I Changed My System Design Interview Preparation

After struggling with architecture discussions, I began approaching preparation differently.

Instead of memorizing a complete design and trying to reproduce it, I would take a system I understood and deliberately break one assumption. I might increase traffic tenfold, remove Redis, delay Kafka consumers, or introduce a database failover during a write.

Then I would ask myself what the system could still guarantee.

That exercise forced me to think about behavior rather than components.

I also started practicing explanations aloud. Understanding a trade-off internally is different from communicating it to an interviewer who has limited time and may challenge your assumptions halfway through an answer.

For example, saying that PostgreSQL provides strong consistency is too vague for a serious architecture discussion. The actual guarantees depend on transaction isolation, replication topology, read routing, and the operations being performed.

A stronger explanation connects the technology to a specific invariant.

If the requirement is that a payment cannot be recorded twice for the same logical operation, I should explain which database constraint or transactional mechanism enforces that rule and what happens during concurrent requests.

This became the foundation of how I organized my system design preparation.

The preparation system I built from these lessons

I eventually turned that approach into the Senior & Staff System Design Interview OS, built around the preparation methods I used myself and the interview weaknesses I had to address. It combines an 89-page interview playbook with a 41-page Visual Architecture Atlas containing 36 architecture diagrams, for 130 pages in total.

The material focuses on the parts of system design interviews that become difficult after the initial architecture is drawn. It covers requirement clarification, the first 90 seconds of an interview, architecture trade-offs, scaling bottlenecks, dependency failures, and interviewer follow-up questions that force you to reconsider your original assumptions.

The diagrams are useful for recognizing architectural patterns, but I designed the preparation around explaining why a component belongs in the system and what happens when it fails. You can explore the complete System Design Interview OS here if you’re preparing for Senior or Staff engineering interviews and want a more structured way to practice.

Five Advanced System Design Interview Questions Worth Practicing

The following questions are useful because they force you to move beyond architecture vocabulary and explain concrete system behavior.

1. How would you prevent duplicate payments when clients retry requests?

Start by defining what constitutes the same logical operation. Discuss durable idempotency keys, request fingerprints, concurrency control, and the behavior of the external payment provider.

Then explain how the system handles an operation whose outcome is uncertain after a timeout.

2. How would you design a notification system that handles provider rate limits?

Consider per-provider throughput limits, bounded queues, backpressure, retry scheduling, and dead-letter handling. Explain how you would prevent retries from overwhelming the provider and how you would detect messages that are repeatedly failing.

Also define whether duplicate notifications are acceptable and how delivery attempts are recorded.

3. What happens when Redis fails during peak traffic?

Estimate the additional load that would reach the database and determine whether the system can absorb it. Discuss request coalescing, bounded fallback traffic, circuit breakers, and whether stale responses are safe for the business operation.

The objective is to prevent the recovery strategy from creating a cascading failure.

4. How do you keep PostgreSQL and Kafka consistent?

Explain why a normal database transaction cannot atomically commit a Kafka publication without additional coordination. Discuss the transactional outbox pattern, publisher recovery, duplicate delivery, and idempotent consumers.

Be precise about which guarantees the proposed design provides and which it does not.

5. When should a company avoid microservices?

Evaluate independent scaling requirements, deployment constraints, team ownership, data consistency, and operational maturity. A modular monolith may be a better fit when the system’s complexity doesn’t justify distributed coordination.

A good answer explains what would need to change before microservices became worthwhile.

These questions are especially valuable because there is rarely a single universally correct architecture. The interviewer is evaluating whether your reasoning remains coherent as the constraints evolve.

How to Practice System Design Interviews Without Memorizing Answers

One useful exercise is to choose a familiar system and design it under a strict time limit. Spend the opening minutes clarifying requirements, then present the simplest architecture that satisfies them.

Afterward, introduce a failure that invalidates one of your assumptions.

If you designed a notification service, imagine the provider becomes unavailable for an hour. If you designed a payment system, imagine the database commits but the response disappears. If you designed a read-heavy API, imagine the cache fails during peak traffic.

Explain the resulting failure path and revise the design.

The exercise becomes more useful when you record your explanation or practice with another engineer. You’ll notice where your reasoning becomes vague, where you introduce technologies without justification, and where you rely on guarantees you haven’t actually established.

Over time, the goal is to become comfortable defending imperfect but deliberate architecture decisions.

Real production systems are full of trade-offs. Strong system design interviews reflect that reality.

Frequently Asked Questions About Senior and Staff System Design Interviews

What is the best way to prepare for a Senior Software Engineer system design interview?

Practice designing systems from requirements and explaining the trade-offs behind your decisions. Include capacity estimation, database consistency, caching, asynchronous processing, reliability, and failure recovery. Use architecture diagrams as references, then practice changing assumptions and defending the resulting design.

Why do experienced software engineers fail system design interviews?

Experience doesn’t automatically translate into a clear interview explanation. Some engineers know the technologies but struggle to communicate constraints, defend trade-offs, or adapt when requirements change. Practicing structured reasoning and realistic failure scenarios can help address that gap.

What is the difference between Senior and Staff Engineer system design interviews?

Senior interviews commonly emphasize designing and operating reliable systems within a defined scope. Staff interviews may place greater weight on cross-team architecture, migration strategy, organizational constraints, and long-term technical decisions. Expectations vary by company, so candidates should study the role’s actual responsibilities.

How do you handle changing requirements in a system design interview?

Identify which original assumptions are no longer valid and explain the consequences before changing the architecture. Preserve components that still satisfy the requirements and revise the parts affected by the new constraints. Communicating that reasoning is usually more valuable than immediately drawing an entirely new system.

How important is capacity estimation in system design interviews?

Capacity estimation helps establish whether a proposed architecture is plausible. Rough calculations for requests per second, storage growth, bandwidth, and peak traffic can reveal scaling bottlenecks early. The estimates don’t need to be perfectly precise, but their assumptions should be explicit and defensible.

Should I use Kafka in every system design interview?

No. Kafka is appropriate when its messaging, throughput, retention, and consumption characteristics satisfy actual requirements. It introduces operational complexity and delivery considerations that may be unnecessary for smaller or simpler systems. Explain why the broker is needed before adding it to the architecture.

How do you explain database consistency in a system design interview?

Begin with the business invariant that must be preserved. Then discuss the transaction boundaries, isolation levels, concurrency controls, and replication behavior relevant to that invariant. Avoid describing an entire database as simply consistent or inconsistent without specifying the operation and failure scenario.

What are the most important distributed systems concepts for Staff Engineer interviews?

Consistency models, idempotency, partial failures, retries, messaging semantics, backpressure, observability, data ownership, and recovery strategies are particularly useful. Staff-level discussions may also include migrations, organizational boundaries, and the operational cost of architectural decisions. Understanding how these concepts interact matters more than memorizing their definitions.

How do you answer system design questions when you don’t know the ideal architecture?

State your assumptions, identify the most important constraints, and propose a reasonable starting point. Explain the risks of your approach and what additional information would change your decision. Interviewers can evaluate your reasoning even when the problem doesn’t have a single definitive solution.

Are architecture diagrams enough to prepare for system design interviews?

Architecture diagrams help you recognize patterns and communicate component relationships. They cannot fully demonstrate failure recovery, consistency guarantees, or the reasoning behind technology choices. The strongest preparation combines diagrams with trade-off analysis and realistic follow-up questions.

The Part of System Design Interviews I Understand Differently Now

I used to measure my preparation by how many systems I could design from memory. If I could draw a URL shortener, chat application, notification platform, and payment service without consulting notes, I assumed I was ready.

That confidence disappeared whenever an interviewer introduced a failure I hadn’t rehearsed.

The more useful measure became whether I could explain the behavior of my design when an operation completed only partially, a dependency became unavailable, or a business requirement invalidated my original assumptions.

I still study architecture diagrams. They’re useful references, especially when comparing common patterns and understanding how systems are structured.

But I spend considerably more time thinking about what happens between the components.

That’s where many production incidents begin, and it’s where some of the most revealing Senior and Staff interview questions come from.

Go Deeper: System Design, Production Engineering, and Senior/Staff Interviews

I write more detailed engineering breakdowns on my free Substack, including distributed systems failures, backend architecture decisions, production debugging, and the technical judgment expected from experienced engineers. If you enjoy understanding why an architecture works under normal traffic and what happens when its assumptions fail, those are the subjects I explore there.

For structured interview preparation, I built the Senior & Staff System Design Interview OS from my own preparation methods and interview experience. It includes a 130-page system design resource with 36 architecture diagrams, an 89-page playbook, and exercises focused on difficult follow-up questions, scaling decisions, architecture trade-offs, and production failure scenarios.

The material is designed for engineers who already know the fundamentals and want to become more confident explaining technical decisions when an interviewer starts pushing beyond the diagram.

Explore the Senior & Staff System Design Interview OS

staff engineer system design interview, system design interview preparation, advanced system design interview questions, distributed systems interview, system design interview mistakes, payment system design interview, Kafka system design interview, system design architecture tradeoffs.

I Failed System Design Interviews Until I Stopped Drawing Perfect Architectures was originally published in Engineering Under Pressure on Medium, where people are continuing the conversation by highlighting and responding to this story.

Our first optimization made the query faster in staging and barely moved production latency. The real problem was how Hibernate, PostgreSQL, and the API contract interacted under load.

The first optimization looked convincing. A query that had been taking around 900 milliseconds in our staging benchmark dropped to 80 milliseconds after we added a composite index. The execution plan improved, buffer reads decreased, and the engineer who proposed the change had every reason to believe we’d solved the performance problem. We deployed it expecting a noticeable improvement in the account dashboard.

Production latency barely moved.

The endpoint’s p95 response time was still above two seconds during peak traffic. PostgreSQL CPU utilization remained elevated, and the HikariCP connection pool continued approaching saturation. We had made one SQL statement significantly faster without making the business operation much faster.

That result changed the investigation. We stopped asking how to optimize the slowest query and started asking what actually happened between an incoming HTTP request and the completed response.

The case below is a reconstructed engineering scenario, with illustrative measurements rather than claimed production results. The investigation reflects the kind of analysis I’d use on a Java, Spring Boot, Hibernate, and PostgreSQL system where conventional query tuning has stopped producing meaningful gains.

Our Original Architecture Looked Reasonable

The endpoint returned account information for a B2B SaaS dashboard. Customers could see their active subscriptions, recent invoices, payment status, and a summary of their usage. The application was built with Spring Boot, Hibernate, and PostgreSQL, with Redis used for a limited set of frequently accessed reference data.

The dashboard had grown gradually. The original API returned account metadata and a subscription summary, but later releases added billing details and usage information. Instead of redesigning the read path, the team extended the existing service and reused the same JPA entity relationships.

Nothing in the controller suggested a serious problem.

@GetMapping("/accounts/{accountId}/dashboard")
public AccountDashboardResponse getDashboard(
        @PathVariable UUID accountId) {

  return dashboardService.getDashboard(accountId);
}

The service loaded the account, mapped its relationships into response objects, and returned the result. Most of the work lived inside repository calls and mapping code, which made the endpoint appear simpler than the database workload it generated.

Our first mistake was assuming that a simple service method implied a simple execution path.

The second was trusting the duration of the most expensive SQL statement as a reasonable approximation of the endpoint’s database cost.

We Optimized the Query Everyone Was Complaining About

The slow-query logs pointed toward a statement retrieving recent invoices for an account.

The query filtered by account_id, ordered invoices by creation time, and returned the latest records.

SELECT id, account_id, amount, status, created_at
FROM invoices
WHERE account_id = $1
ORDER BY created_at DESC
LIMIT 50;

The table contained millions of invoices. The existing indexes were useful for other access patterns, but the query plan showed more work than we expected for a request that needed only fifty rows.

We added a composite index.

CREATE INDEX CONCURRENTLY idx_invoices_account_created
ON invoices (account_id, created_at DESC);

The change was technically justified. It aligned the index with the equality filter and ordering requirement, allowing PostgreSQL to retrieve the relevant rows more efficiently.

In the illustrative benchmark, the statement dropped from approximately 900 milliseconds to 80 milliseconds.

If we had been evaluating that query in isolation, the optimization would have been a success.

The problem was that the endpoint didn’t execute the query in isolation.

During a single dashboard request, Hibernate was issuing additional statements to load subscription relationships, invoice line items, payment metadata, and usage records.

Some queries were individually fast. There were simply too many of them.

The Trace Told a Different Story Than the Slow-Query Log

We added request-level tracing around the dashboard operation and correlated the trace with database activity.

The result was uncomfortable.

The optimized invoice query accounted for only part of the endpoint’s database time. Entity mapping triggered additional SQL statements, and the number of statements increased with the number of invoices returned.

For an account with fifty recent invoices, the application could issue queries for the invoices themselves, then additional queries for associated entities.

The behavior depended on the entity mappings, fetch configuration, and which relationships the mapper accessed.

It was a classic Hibernate N+1 pattern, although the actual request contained several related query families rather than one neat textbook example.

The mapper looked innocent:

return invoices.stream()
    .map(invoice -> new InvoiceResponse(
        invoice.getId(),
        invoice.getAmount(),
        invoice.getStatus(),
        invoice.getLineItems().size()
    ))
    .toList();

If lineItems was a lazy collection that had not already been initialized, accessing it could trigger another database query for each invoice.

The service didn’t explicitly execute those queries. Hibernate did it while the application constructed the response.

This explained why the index improvement had barely affected production latency. We had reduced the cost of one statement while leaving the rest of the request’s database round trips intact.

At that point, I wanted two numbers for every representative request: how many SQL statements it executed and how much total time those statements consumed.

The slowest query was no longer our primary unit of investigation.

We Tried JOIN FETCH. It Created a Different Problem.

The first proposed correction was to fetch the related entities eagerly in one query.

For small collections, a targeted fetch join can eliminate repeated round trips. It is a legitimate Hibernate optimization when the resulting data volume and query shape are understood.

Our dashboard had a less convenient requirement.

It needed the fifty most recent invoices, each potentially containing multiple line items. Joining invoices to line items could multiply the number of SQL result rows.

Fifty invoices with an average of eight line items could produce hundreds of joined rows before Hibernate reconstructed the entity graph.

That row multiplication affected network transfer, memory allocation, and result processing.

Pagination made the design more troublesome. Combining collection fetch joins with limits can prevent the database from applying pagination in the intended way, depending on the query and Hibernate behavior.

We enabled the Hibernate setting that fails when pagination over a collection fetch would otherwise be handled in memory:

spring.jpa.properties.hibernate.query.fail_on_pagination_over_collection_fetch=true

The setting was useful because it converted a potentially expensive behavior into an explicit failure during development.

It didn’t solve the dashboard query. It forced us to acknowledge that the read model itself needed attention.

We had been trying to make a complex entity graph behave like a lightweight API response.

The Better Fix Was to Stop Loading Objects We Didn’t Need

The dashboard wasn’t an entity editor. It didn’t need fully managed invoice aggregates with every relationship available for later modification.

It needed a small, defined set of fields.

That distinction gave us a simpler design.

We replaced broad entity loading with targeted projections for the invoice summary. The query returned the fields required by the response contract and avoided initializing unrelated associations.

For counts and totals, we used explicit aggregation queries where appropriate rather than loading entire collections into Java merely to count them.

For example:

SELECT
    i.id,
    i.amount,
    i.status,
    i.created_at,
    COUNT(li.id) AS line_item_count
FROM invoices i
LEFT JOIN invoice_line_items li
    ON li.invoice_id = i.id
WHERE i.account_id = $1
GROUP BY i.id, i.amount, i.status, i.created_at
ORDER BY i.created_at DESC
LIMIT 50;

This illustrates the projection approach, although the precise production query would depend on schema constraints, row cardinality, and execution plans. On large tables, it can be preferable to select the fifty invoice IDs first and aggregate line items only for that bounded set.

The key improvement was controlling how much data the application requested.

Instead of allowing entity traversal to determine database access dynamically, the endpoint used queries designed around its response requirements.

We also separated information that genuinely needed transactional freshness from information that could tolerate delayed updates.

The dashboard had been treating all fields as though they required identical consistency and latency guarantees.

They didn’t.

A recently confirmed payment status deserved stronger freshness guarantees than a historical usage chart. Making that distinction reduced the amount of work required on the critical response path.

The Connection Pool Was Still a Problem

After reducing the query count, the endpoint became substantially faster in controlled tests.

Under sustained concurrency, however, we still saw occasional connection acquisition delays.

The earlier investigation had focused on the maximum number of HikariCP connections. This time we examined how long each request occupied a connection and whether the application held transactional resources while performing unrelated work.

One service method used a read-only transaction around the entire dashboard assembly process.

That transaction included database reads and additional application-side processing.

A read-only transaction can be useful, but it doesn’t mean the method is free of transactional resource costs. Depending on when the connection is acquired and how the persistence context is used, the application may retain database resources longer than necessary.

We reviewed the transaction boundaries and removed unnecessary work from the transactional section.

The goal wasn’t to make every transaction as short as theoretically possible. We wanted database resources to remain occupied only for the period required to preserve the operation’s intended consistency.

That change mattered under concurrency because connection-pool pressure is affected by connection occupancy time.

A useful approximation is Little’s Law: under stable conditions, the average number of operations in a system relates to arrival rate and average time spent there.

For a connection pool, reducing the time each operation holds a connection can improve the number of requests the same pool can support, assuming the workload and database capacity allow it.

Increasing the pool size would not have addressed the unnecessarily long occupancy.

The Numbers Finally Started Moving Together

We repeated the benchmark with a representative dataset and a fixed concurrency profile.

This time, we measured the complete request rather than reporting only the slowest SQL statement.

<escape>

MetricOriginalAfter indexAfter read-path redesignInvoice query duration900 ms80 ms80 msSQL statements per request1261266Endpoint p95 latency2,400 ms2,180 ms410 msHikariCP acquisition p95310 ms290 ms24 ms

</escape>

These are illustrative benchmark values, not measured results from a named production system. They show why the initial optimization was insufficient and how I would evaluate the broader correction.

The index reduced one query’s duration by roughly 91%. Yet the endpoint’s p95 latency improved by less than 10% after that change alone.

The meaningful improvement came when we reduced repeated database access and shortened the time requests occupied constrained resources.

In this example, endpoint p95 fell from 2,400 milliseconds to 410 milliseconds after the broader redesign, an improvement of approximately 83%.

Those numbers are more useful to an engineering leader than a statement claiming that one SQL query became dramatically faster.

Customers experience request latency. Infrastructure pays for the total workload. Engineers need to understand the relationship between them.

We Also Changed How We Reviewed Performance Pull Requests

The technical fix addressed the immediate endpoint, but the incident exposed a problem in our development process.

Our pull request reviews focused on repository methods, indexes, and obvious algorithmic complexity. We rarely examined the number of SQL statements generated by a complete API operation.

That allowed database access patterns to change without attracting attention.

We added integration tests that exercised representative dashboard requests and inspected Hibernate statistics. For critical read paths, the team could detect unexpected increases in statement count before deployment.

We didn’t establish one universal SQL-count threshold for every endpoint. Some operations legitimately require more database interactions than others.

Instead, we created expectations for the workflows where query amplification would be expensive.

We also made performance reviews more specific.

A change to an entity relationship or DTO mapper deserved attention if it could alter lazy-loading behavior. A new dashboard field required an explanation of where its data came from and whether it introduced another query or remote dependency.

These practices weren’t particularly glamorous. They reduced the chance that a harmless-looking response field would quietly multiply database work.

The team had previously treated performance as something to investigate after an alert.

We began treating database access behavior as part of the API contract.

What I’d Do Differently on the Next System

The next time a Spring Boot service shows high PostgreSQL latency, I wouldn’t begin by assuming the slowest query is responsible for the slow endpoint.

I’d first trace a representative request and identify its total database workload.

That includes the number of statements executed, their cumulative duration, connection acquisition delays, transaction boundaries, and any SQL triggered during entity mapping or serialization.

Then I’d compare the behavior under light and sustained load.

A request that executes 120 individually fast queries may perform acceptably on a developer laptop while becoming expensive under real concurrency. A query that is genuinely slow may require indexing, query restructuring, or changes to the data model.

Those are different problems, and they deserve different fixes.

I’d also resist optimizing every endpoint with aggressive eager fetching. Loading more data in fewer queries can be useful, but it can create its own memory and pagination problems.

For read-heavy SaaS endpoints, purpose-built projections are often easier to reason about than exposing large JPA entity graphs to the response layer.

The final decision should be driven by the workload and the consistency requirements of the operation.

The Index Was Correct. Our Diagnosis Was Too Narrow.

The composite index stayed.

It was a valid improvement, and removing it would have made the invoice query slower again.

What changed was our understanding of the incident.

The endpoint had accumulated responsibilities over several releases, and Hibernate had made the resulting database access patterns easy to overlook. Our first benchmark measured a SQL statement, while customers were waiting for a much larger operation.

The index solved the problem we had measured. It simply wasn’t the problem that dominated the user experience.

For an engineering leader, this is the part worth remembering. Performance work should be evaluated against the business operation it is supposed to improve, with enough instrumentation to explain why the numbers changed.

Otherwise, a team can celebrate a 91% query improvement while customers continue staring at the same slow dashboard.

Backend Performance & Architecture Consulting

I’m Devrim Ozcay, founder of ProdRescue AI, an independent engineering consulting practice focused on Java and Spring Boot systems, PostgreSQL performance, distributed architectures, and production reliability.

I work with SaaS founders, CTOs, and engineering leaders who need an external technical assessment of backend performance problems, inefficient data-access patterns, transaction behavior, and architectural risks that are difficult to isolate during normal development.

Our engagements include focused architecture reviews, technical risk assessments, written recommendations, and ongoing engineering advisory. Monthly consulting plans start at $750.

Explore consulting services:

ProdRescue AI: Backend Reliability, Architecture & Production Engineering Consulting

ProdRescue AI:

ProdRescue: AI Postmortem & RCA Generator for Backend Teams

Business inquiries: info@prodrescueai.com

If your team has already optimized SQL queries but still sees high API latency, connection-pool pressure, or unpredictable PostgreSQL performance, email me a brief description of the system and the changes you’ve tried. We can discuss whether a focused backend architecture review would help identify the remaining bottlenecks.

Frequently Asked Questions

Why is my Spring Boot API slow even after optimizing PostgreSQL queries?

The endpoint may execute many additional SQL statements through Hibernate lazy loading, entity mapping, or other repository calls. Connection acquisition delays, transaction duration, and downstream dependencies can also dominate response time.

How do I detect N+1 queries in Spring Boot and Hibernate?

Inspect generated SQL and Hibernate statistics while executing representative API requests. Look for repeated queries triggered by accessing relationships during DTO mapping, serialization, or collection traversal.

Is JOIN FETCH always better than lazy loading in Hibernate?

No. Fetch joins can reduce database round trips, but collection joins may multiply result rows and create pagination or memory problems. Targeted projections or bounded batch loading may be more appropriate.

How do I reduce HikariCP connection acquisition time?

Investigate transaction duration, database query performance, connection occupancy, and application concurrency. Increasing pool size can help in some circumstances, but it can worsen database contention when the underlying workload is inefficient.

Should I use DTO projections instead of JPA entities for read-heavy APIs?

DTO projections are often useful when an endpoint needs a defined subset of fields and doesn’t require managed entity behavior. They can reduce unnecessary data loading and make SQL access patterns easier to control.

How should I benchmark PostgreSQL performance in a SaaS application?

Measure complete business operations under representative data volume and concurrency. Include request latency percentiles, SQL statement count, cumulative database time, connection acquisition latency, and resource utilization.

Spring Boot PostgreSQL performance, Hibernate N+1 query, Spring Boot slow API, HikariCP connection acquisition time, Hibernate DTO projection, PostgreSQL query optimization, JPA performance tuning, Spring Boot database bottleneck.

We Cut PostgreSQL Query Time by 91%. The Index Wasn’t the Fix. was originally published in Engineering Under Pressure on Medium, where people are continuing the conversation by highlighting and responding to this story.

HR called it a culture decision. Finance called it an expensive hiring problem. The engineering team had a more uncomfortable explanation.

The email arrived at 8:42 on a Monday morning, two hours before our engineering leadership meeting. Starting in January, every employee within commuting distance of an office would be required to work on-site four days a week. Exceptions would require executive approval, and managers were instructed to treat the policy as a company-wide operating standard rather than a subject for individual negotiation.

Our Staff Engineer, Daniel, forwarded the announcement to his manager with a short response. He had been working remotely for four years, had led the redesign of our payment infrastructure, and was responsible for several services that operated across three engineering teams. He wanted to know whether the company intended to evaluate his work differently after January.

His manager replied that the policy was about collaboration, mentorship, and rebuilding engineering culture. Daniel asked which of his responsibilities had become harder to perform remotely. The manager suggested discussing it during their next one-on-one.

That conversation lasted twenty-seven minutes. Daniel explained that his work already involved engineers in different cities, that most architectural discussions happened through shared documents, and that production incidents were handled through remote collaboration regardless of where anyone sat. His manager acknowledged the points but said the company needed consistent expectations.

Daniel asked for an exception and was denied. Six weeks later, he resigned.

The engineering director described the departure as unfortunate but necessary to preserve fairness. HR emphasized that the company could not create separate rules for highly compensated employees. The CEO praised the leadership team for maintaining a consistent culture.

Three months later, we had hired two engineers to absorb Daniel’s responsibilities. One focused on backend architecture, while the other took ownership of reliability and infrastructure coordination. Both were capable, experienced professionals, and neither had done anything wrong.

Together, their compensation exceeded Daniel’s previous package by a substantial margin. The transition had also consumed hundreds of engineering hours, delayed two projects, and exposed gaps in our understanding of systems Daniel had maintained for years.

During the next budget review, our CFO asked why enforcing a collaboration policy had required additional engineering headcount.

Nobody had included that possibility in the original return-to-office proposal.

The Return-to-Office Policy Was Written for a Different Kind of Work

Our company had grown rapidly during the remote-work years. Engineering teams were distributed across several locations, and most technical decisions were documented asynchronously. Developers used GitHub for code reviews, shared design documents for architecture discussions, and incident channels for production coordination.

The company still maintained offices, but attendance varied by team. Some employees preferred working on-site, while others came in for planning sessions or occasional collaboration days. There was no universal schedule, and managers generally evaluated performance through delivery, technical impact, and team responsibilities.

The new policy changed that arrangement. Leadership argued that remote work had weakened informal communication and made it harder for newer employees to learn from experienced colleagues. Those concerns were legitimate enough to deserve investigation, particularly in teams where onboarding and mentoring had become inconsistent.

However, the policy applied broadly without distinguishing between teams that worked primarily in one location and teams whose members were geographically distributed. It also assumed that physical attendance would improve collaboration even when the people who needed to collaborate were sitting in different offices.

Daniel’s team illustrated the problem. His closest engineering partners were located in three cities, and his most important meetings already took place through video calls. Returning to the office would have changed his physical location without placing most of his collaborators in the same room.

The policy had been designed around a general belief about company culture. Nobody had demonstrated how four office days would improve the specific engineering work Daniel performed.

Staff Engineers Create Value That Doesn’t Fit an Attendance Dashboard

Daniel’s responsibilities extended well beyond implementing features. He reviewed architectural decisions across teams, helped engineers resolve difficult production problems, and maintained technical context that connected several business-critical systems. His calendar contained design reviews, mentoring sessions, and operational discussions that rarely resulted in visible individual deliverables.

His influence was especially important during incidents. When a payment service experienced unusual latency, Daniel could often identify which downstream dependencies were relevant and which recent changes deserved investigation. He knew the historical reasons behind several architectural compromises and understood which parts of the system were safe to modify under pressure.

That expertise had developed over years of maintaining the platform. It was not tied to his home office, the company’s headquarters, or the number of hours he spent near other employees.

The engineering director believed that experienced engineers should be physically available to mentor junior developers. Daniel agreed that mentoring mattered, but he questioned whether office attendance was an effective measure of mentorship. He regularly reviewed designs with engineers in other locations and had created internal technical workshops that employees could attend regardless of geography.

The director suggested that spontaneous conversations were difficult to reproduce remotely. Daniel acknowledged that informal interactions could be useful, but he wanted the company to examine whether those benefits justified the costs of changing established working arrangements.

The discussion never reached that level of detail. Leadership had already decided that consistent attendance was the priority.

The Staff Engineer Asked One Question HR Couldn’t Answer

During his exception review, Daniel presented evidence of his work. He showed cross-team architecture proposals, mentoring records, production incident contributions, and delivery outcomes from the previous year. His argument was that the company should evaluate whether remote work had reduced his effectiveness before requiring a change.

HR responded that exceptions based on individual performance would create fairness concerns. If one employee received permission to remain remote, others might request the same arrangement. The company wanted a policy that managers could apply consistently.

Daniel asked whether fairness meant treating every role identically or evaluating employees according to the requirements of their work. The HR representative said the policy was intended to establish shared expectations across the organization. His manager added that leadership believed the long-term cultural benefits would outweigh short-term disruption.

Daniel asked whether those benefits had been measured. The answer was that the company expected to evaluate the policy after implementation.

The exception was denied because approving it would have conflicted with the policy’s stated objective. Daniel left the meeting with no further appeal available.

A few days later, he began interviewing.

The Resignation Looked Ordinary Until We Opened the Ownership Map

Daniel gave the company a standard notice period and offered to document his responsibilities before leaving. His manager accepted the resignation professionally and began preparing a transition plan. The initial assumption was that his work could be redistributed among existing senior engineers until a replacement was hired.

The ownership review complicated that assumption. Daniel was involved in payment processing, database architecture, incident response, and technical decisions across several teams. Some responsibilities were clearly documented, while others existed through informal consultation and historical knowledge.

One senior engineer could take ownership of the payment services, but doing so would reduce her availability for a major migration project. Another engineer understood the infrastructure but lacked experience with the business rules governing transaction recovery. The engineering manager could coordinate the work, but he was already responsible for delivery planning and personnel management.

The team eventually divided Daniel’s responsibilities into separate areas. Backend architecture would require one experienced engineer, while reliability and operational coordination would require another. The director initially considered hiring a single Staff Engineer, but the available candidates did not consistently match the combination of expertise Daniel had developed internally.

The recruiting team recommended opening two positions. Leadership approved the plan because the affected systems were too important to leave without clear ownership.

The company had rejected Daniel’s exception partly to avoid creating a precedent. It was now creating two new positions to replace the capabilities that precedent might have retained.

The Cost of Replacing a Staff Engineer Wasn’t Just Salary

The finance team initially compared Daniel’s compensation with the proposed replacement packages. That calculation was straightforward, but it did not capture the full cost of the transition. Recruiting required time from hiring managers and senior engineers, while onboarding reduced the capacity of employees who were already responsible for ongoing delivery.

The two new engineers also needed to learn the platform. They understood distributed systems and backend architecture, but they had not participated in the incidents and design decisions that shaped our existing services. Their early work therefore involved reconstructing context from documentation, code history, and conversations with remaining team members.

Several projects slowed during the transition. A payment reconciliation improvement was delayed because the engineer responsible for it had been reassigned to operational support. An infrastructure modernization initiative also lost momentum while the team established new ownership boundaries.

The engineering director argued that these were temporary costs. He was correct that onboarding expenses would decline as the new engineers became productive. However, the original policy decision had not considered those costs at all.

The CFO asked for an estimate of the financial impact. The engineering manager could identify additional compensation, recruiting expenses, and some delayed project work, but other costs were difficult to quantify reliably. The company had not maintained a model for evaluating the business impact of losing critical engineering expertise.

Finance began treating the resignation as a retention case that had never received a proper economic review.

Remote Work Productivity Was Never the Actual Disagreement

The return-to-office debate had become emotionally charged across the company. Some employees believed remote work improved concentration and flexibility, while others preferred the social interaction and faster informal communication of office environments. Both groups had legitimate experiences, but the policy discussion increasingly treated those preferences as competing ideologies.

Daniel’s argument was narrower. He wanted his working arrangement evaluated according to the responsibilities of his role and the outcomes he delivered. He had not claimed that remote work was universally superior or that office attendance had no value.

The engineering director believed shared physical space could improve mentoring and collaboration. That belief was reasonable enough to test, but the company had implemented a universal rule before establishing which problems it was solving. It had also failed to consider whether different engineering functions might benefit from different arrangements.

For example, a newly formed team working on a tightly coupled project might benefit from regular in-person planning sessions. A distributed infrastructure team responsible for global production systems may already depend on asynchronous communication and remote incident coordination. Applying identical attendance requirements to both teams does not guarantee identical benefits.

The company had treated consistency as evidence of good management. Daniel had questioned whether consistency was useful when the underlying work differed substantially.

The resignation forced leadership to confront the distinction.

The New Engineers Were Excellent. The Transition Was Still Expensive.

The two replacements joined within several months of Daniel’s departure. One had extensive experience designing backend services, while the other specialized in reliability engineering and operational practices. Both quickly became respected members of the organization.

Their technical ability was not the problem. The challenge was transferring ownership of systems whose important decisions had accumulated over years. Documentation explained how components worked, but it did not always explain why certain alternatives had been rejected.

The backend engineer proposed simplifying a payment workflow that appeared unnecessarily complicated. During review, another team member discovered that the additional state transitions had been introduced after an earlier incident involving uncertain payment outcomes. The design looked excessive without that history, but removing it would have recreated a known failure mode.

The reliability engineer encountered a similar issue with an internal retry mechanism. The implementation contained safeguards that seemed redundant until the team found an old incident report describing how duplicate events had affected downstream processing. Daniel had been involved in both incidents and understood the relationship between the code and the operational constraints.

The new engineers eventually reconstructed the necessary context. They also improved documentation and clarified ownership boundaries, which made the organization less dependent on any single individual.

Those improvements were valuable. They did not erase the cost of losing someone who already possessed the knowledge.

The CEO Wanted Collaboration. The Engineers Wanted a Definition.

After the transition, the CEO asked engineering leadership whether the return-to-office policy had improved collaboration. The director reported that office attendance had increased and that employees were spending more time together. The CEO considered those encouraging signs.

Our engineering manager asked whether attendance was the same as collaboration. He had observed more people in the office, but many still spent substantial portions of their day on video calls with colleagues in other locations. The physical environment had changed more than the structure of the work.

The director suggested that cultural improvements would take time to appear. The manager agreed that long-term effects mattered, but argued that the company needed specific outcomes to evaluate. If the objective was better mentoring, the organization should examine onboarding effectiveness and access to experienced engineers. If the objective was faster decisions, it should study decision delays and the causes behind them.

The CEO asked whether engineering leadership opposed the policy. The manager said the team needed a way to distinguish useful collaboration improvements from increased attendance. Without that distinction, the company could declare success simply because employees followed the rule.

The conversation was uncomfortable because it challenged a decision leadership had already presented as a cultural priority. However, the resignation and replacement costs had made the financial consequences difficult to ignore.

The CFO supported a more detailed evaluation. He wanted to know whether the policy was improving business outcomes enough to justify its implementation costs.

The Return-to-Office Policy Created a Retention Risk Nobody Modeled

The company eventually reviewed employee feedback and retention data. Some engineers appreciated more frequent in-person interaction, especially those who lived near the office and preferred structured collaboration days. Others reported longer commutes, reduced flexibility, and frustration with attending virtual meetings from office desks.

The results varied across teams. Employees working primarily with local colleagues described different experiences from those collaborating with distributed groups. The company had expected a universal policy to produce broadly similar benefits, but the effects depended heavily on how teams actually operated.

The retention analysis also revealed that several experienced engineers were reconsidering their long-term plans. They had not necessarily decided to resign, but the policy had changed the value proposition of remaining with the company. Remote flexibility had been part of their working arrangements for years, and removing it affected how they compared internal opportunities with external offers.

Leadership initially interpreted the feedback as resistance to change. The engineering manager argued that employees were responding to a material change in employment conditions. Whether leadership considered that response reasonable did not eliminate the business risk.

The company began examining the cost of losing specialized expertise in critical roles. It also considered whether attendance requirements should reflect team structure, collaboration needs, and operational responsibilities.

The policy remained in place during the review, but exceptions became easier to discuss when managers could demonstrate a clear business case.

Staff Engineer Retention Is an Engineering Risk Management Problem

Losing a Staff Engineer can affect more than delivery capacity. Staff-level engineers often influence architecture across teams, maintain institutional knowledge, and help organizations navigate complex technical decisions. Their value is partly reflected in the work they complete and partly in the mistakes they help others avoid.

That does not mean Staff Engineers should receive unlimited flexibility or that companies must accommodate every preference. Organizations have legitimate operational needs, and some roles require physical presence. The important question is whether a particular requirement is justified by the work and whether its benefits outweigh the associated costs.

Our company had treated Daniel’s request primarily as an HR policy issue. The decision was evaluated according to consistency and precedent, while the operational consequences of losing him received limited attention. Only after his resignation did engineering and finance examine the full impact.

The experience changed how managers approached retention discussions. Critical-role decisions began involving engineering leadership and finance earlier, particularly when an employee’s responsibilities were difficult to replace. The company also improved documentation and succession planning to reduce dependence on individual engineers.

Those changes made the organization more resilient. They also revealed that retention was not simply a matter of employee satisfaction; it was part of managing the risks associated with operating complex technical systems.

The Company Eventually Introduced Team-Based Flexibility

The revised policy allowed engineering teams to propose working arrangements based on collaboration requirements and operational needs. Managers had to explain how the arrangement supported delivery, mentoring, and team effectiveness. Exceptions were no longer treated automatically as threats to organizational fairness.

Some teams continued working primarily from the office. Others adopted scheduled collaboration days or maintained distributed arrangements with periodic in-person sessions. The company still expected accountability and clear performance standards, but attendance was no longer the only visible measure of collaboration.

The engineering director remained concerned about consistency. The CFO responded that consistency should exist in how decisions were evaluated, even when the resulting arrangements differed. A policy could be fair without requiring every employee to work in exactly the same way.

The new approach required more management judgment. Leaders had to understand their teams, identify collaboration problems, and evaluate whether proposed arrangements addressed those problems. That was more demanding than enforcing a universal schedule, but it also created room for decisions grounded in actual work.

Daniel did not return. He had accepted a role at another company and was satisfied with the move. Our replacements continued improving the systems they inherited, and the engineering organization gradually recovered its previous delivery capacity.

The company eventually reached a more balanced position on office attendance. The change arrived after the employee whose departure triggered the review had already moved on.

The Real Cost of Return-to-Office Policies Depends on Who Leaves

The debate about remote work often becomes a contest between competing assumptions about productivity and culture. Some teams benefit substantially from working together in person, while others operate effectively across locations. The relevant question for engineering leadership is how working arrangements affect the specific responsibilities, collaboration patterns, and outcomes of the organization.

Our company had introduced a broad policy without adequately considering the retention risks associated with critical engineering roles. Daniel’s resignation forced the organization to confront costs that were absent from the original proposal. Replacing his capabilities required additional compensation, recruiting effort, onboarding time, and operational adjustments.

The two new engineers were successful, and the company eventually improved its documentation and ownership practices. Those outcomes were valuable, but they did not establish that the original policy decision had been economically sound. The organization had made a cultural decision without fully evaluating its engineering consequences.

The CFO’s final review focused on that distinction. He did not argue that employees should never return to the office, and he did not suggest that every experienced engineer deserved an exception. He wanted leadership to evaluate policy decisions using the same financial discipline applied to other operational changes.

The engineering director acknowledged that the company had underestimated the cost of losing Daniel. He also admitted that attendance had been easier to measure than the collaboration improvements leadership hoped to achieve.

The revised policy was less rigid and required more judgment from managers. It reflected a recognition that different engineering teams could have different operational needs while still being held to consistent standards of performance.

Daniel’s former desk remained empty for several months. The two engineers who replaced his responsibilities eventually worked from different offices, coordinating most of their technical decisions through the same shared documents and video calls he had used.

Frequently Asked Questions About Remote Work and Engineering Retention

Are return-to-office policies causing software engineers to quit?

Return-to-office requirements can influence employee retention, particularly when they materially change established working arrangements. The impact varies by organization, labor-market conditions, employee preferences, and the availability of alternative jobs.

Is remote work better for software engineers?

Remote work can support concentration, flexibility, and distributed collaboration, while office work may improve certain forms of informal communication and mentoring. The best arrangement depends on team structure, responsibilities, and individual circumstances.

Why do Staff Engineers prefer remote work?

Some Staff Engineers value remote work because their responsibilities involve cross-team coordination, architecture reviews, and asynchronous communication. Preferences vary, and many experienced engineers also appreciate in-person collaboration.

What is the difference between Senior and Staff Engineer responsibilities?

Senior Engineers typically own complex technical work within a team or domain, while Staff Engineers often influence architecture and technical direction across multiple teams. Exact expectations differ between companies.

How much does it cost to replace a Staff Engineer?

Replacement costs depend on compensation, recruiting expenses, onboarding time, knowledge transfer, and the impact on ongoing projects. Engineers with extensive institutional knowledge or critical system ownership may be particularly difficult to replace quickly.

Do return-to-office policies improve collaboration?

They can improve certain forms of collaboration, especially when team members work in the same location and benefit from frequent in-person interaction. However, increased attendance does not automatically establish improved engineering outcomes.

How can engineering managers improve remote team collaboration?

Managers can establish clear communication practices, document technical decisions, improve onboarding, and create opportunities for deliberate collaboration. The approach should reflect the team’s actual working patterns.

Why is Staff Engineer retention important?

Staff Engineers often provide technical leadership, architectural continuity, and cross-team problem-solving capabilities. Losing that expertise can affect delivery, operational reliability, and organizational knowledge.

Should companies offer remote work exceptions to senior engineers?

Exceptions can be appropriate when they support business needs and are evaluated through transparent criteria. Companies should consider role requirements, fairness, operational impact, and retention risks.

How should companies measure engineering productivity?

Engineering productivity should be evaluated through multiple signals, including delivery effectiveness, quality, reliability, collaboration, and developer experience. Attendance and activity metrics alone provide an incomplete picture.

Free: The Engineer’s High-Stakes Playbook

Senior engineering careers are shaped by technical decisions, organizational expectations, and the ability to recognize when a working arrangement no longer supports your goals. Understanding your responsibilities and the value you provide becomes especially important during compensation, promotion, and career negotiations.

I created a free engineering playbook covering production investigation, system design reasoning, and critical career decisions. It’s designed for engineers who want to make stronger decisions when technical responsibilities and organizational incentives begin pulling in different directions.

Get the Free Engineer’s High-Stakes Playbook

Help Us Build a Better System Design Interview Tool

Senior and Staff Engineer interviews increasingly evaluate technical leadership, architectural judgment, and the ability to explain complex tradeoffs. Those skills matter whether engineers work remotely, in the office, or across distributed teams.

At ProdRescue AI, we’re researching an interactive AI-powered system design interview platform for engineers preparing for Senior, Staff, and Principal roles. We’re exploring an architecture canvas, realistic interviewer follow-up questions, and structured feedback on scalability, reliability, data consistency, and engineering tradeoffs. Your feedback will help shape the first release, and you can request early access to the private beta.

Take the 3–4 Minute System Design Tool Survey

I also publish engineering stories about remote work, software careers, AI-assisted development, backend architecture, and the decisions that shape engineering organizations. If you enjoy discussions about what makes engineers effective and how companies manage technical talent, you’ll find more of them on my Substack.

Subscribe to My Engineering Writing on Substack

Our Staff Engineer Refused to Return to the Office. We Hired Two People to Replace Him was originally published in Engineering Under Pressure on Medium, where people are continuing the conversation by highlighting and responding to this story.

I spent 76 days preparing for technical interviews, memorizing answers, and trying to sound like a Senior Engineer. The interview that changed everything started with a question I couldn’t answer.

The interviewer asked me what would happen if a PostgreSQL transaction was interrupted while waiting for a row lock. I knew the general behavior, but I couldn’t remember the exact distinction between a statement timeout, a lock timeout, and a transaction being canceled by the client. Instead of admitting that, I started explaining transaction isolation levels.

He listened for about thirty seconds before interrupting me.

“That wasn’t my question,” he said, looking directly into the camera. “I’m asking what happens to the transaction after the statement is canceled.”

I tried again, this time discussing rollback behavior and connection management. Some of what I said was correct, but I was mixing database behavior with assumptions about how Spring handled exceptions. The interviewer asked whether I’d tested the scenario myself, and I realized I was about to spend another five minutes defending an answer I wasn’t confident about.

I told him I hadn’t tested that exact case.

He waited.

Then I said I didn’t know the precise behavior and would need to verify it before making a production decision.

He nodded, opened a shared document, and asked me to explain how I’d investigate it.

For the first time in seventy-six days, an interviewer seemed more interested in what I’d do when I didn’t know something than in whether I could produce an answer immediately.

I Had Started the Search With More Confidence Than Preparation

I’d left my previous backend engineering job after several years working with Java, Spring Boot, PostgreSQL, Redis, and asynchronous processing systems. I’d been involved in production incidents, database migrations, and architecture discussions that required making decisions with incomplete information. I considered myself a capable engineer, although I knew there were areas where my knowledge was less developed.

When I started applying for Senior Backend Engineer positions, I expected technical interviews to focus on the kind of work I’d been doing. I assumed companies would ask about production failures, database performance, and designing reliable services. Some did, but many interviews felt more like a test of how quickly I could recall details from documentation.

The first rejection came after a Java concurrency interview. The interviewer asked me to explain the difference between volatile and synchronized, and I gave a reasonable answer about visibility and mutual exclusion. Then he asked whether volatile made a compound operation atomic, and I hesitated before giving an incomplete explanation.

The feedback said my understanding of concurrency fundamentals needed improvement.

I spent the following weekend studying the Java Memory Model. I reviewed happens-before relationships, atomic operations, and the circumstances where synchronization was necessary. By Monday, I could explain the topic more clearly, although I was frustrated that one question had apparently outweighed years of production experience.

The second rejection came after a system design interview. I proposed a message broker for an event-processing platform, but the interviewer questioned whether the expected workload justified the operational complexity. I defended the design because I’d used similar architectures before, even though I hadn’t established the throughput requirements.

The recruiter said the team wanted someone who demonstrated stronger judgment when selecting technologies.

I added the feedback to my spreadsheet.

Then I started studying system design more aggressively.

Every Rejection Added Another Topic to My Study Plan

By the fourth interview, my preparation notes had become enormous. I had sections covering Java concurrency, PostgreSQL indexing, Redis eviction policies, Kafka consumer groups, distributed locks, transaction isolation, and Kubernetes networking. I could explain concepts I’d never implemented and discuss failure scenarios I’d only encountered in articles.

That seemed like progress.

The problem was that I was starting to confuse familiarity with understanding.

During the fourth interview, an Engineering Manager asked how I’d investigate a sudden increase in API latency. I described checking application metrics, database performance, and external dependencies. He asked what I’d do if the database metrics looked normal but request latency had doubled.

I said I’d examine thread pool utilization and garbage collection behavior.

He asked what I’d expect to see if garbage collection were responsible.

I explained that long pauses could delay request processing, but I couldn’t remember which JVM metrics would distinguish allocation pressure from other causes. Instead of acknowledging the gap, I continued discussing garbage collection algorithms.

The interviewer eventually moved on.

The rejection arrived two days later.

The fifth company asked me about Kafka exactly-once semantics. I’d read about the feature and understood that Kafka could coordinate certain producer and consumer operations, but I struggled to explain its limitations when a workflow involved an external database. I gave an answer that sounded confident while overlooking an important boundary.

The interviewer challenged me with a scenario involving a successful database commit followed by a consumer crash.

I explained that Kafka transactions could help prevent duplicate processing.

He asked how a Kafka transaction would roll back a PostgreSQL commit.

I stopped talking.

The question was fair, and I knew I’d made a mistake. I’d treated a feature name as a guarantee that applied to the entire business workflow, even though the database and Kafka weren’t participating in one atomic transaction.

I corrected myself, but the damage was done.

The recruiter later said the team had concerns about my depth of understanding.

That feedback bothered me more than the others because I knew exactly what had happened.

I’d answered too quickly because I wanted to sound knowledgeable.

I Started Practicing Answers Instead of Solving Problems

After the sixth rejection, I changed my preparation routine. I began recording myself answering common interview questions and listening for hesitation, unnecessary detail, and weak explanations. I wanted to sound more confident, so I practiced until the answers became smooth.

I prepared stories about production incidents, difficult technical decisions, and disagreements with managers. I rehearsed explanations of database locking, message delivery guarantees, and distributed system failures. I even practiced how I’d respond when an interviewer interrupted me.

The preparation made me more comfortable speaking.

It also made me less comfortable thinking.

During the seventh interview, a Staff Engineer asked how I’d design a service that processed customer payments asynchronously. I started explaining idempotency keys, durable state transitions, and retry behavior before he’d finished describing the requirements.

He asked whether I’d considered that some payments might need immediate confirmation.

I said the system could return an acknowledgment and complete the operation later.

He asked whether that behavior would satisfy the business requirement.

I realized I hadn’t asked.

We spent the next twenty minutes revising a design I’d introduced before understanding the problem.

The eighth rejection was similar. I was asked to investigate a hypothetical production incident, and I immediately started listing the metrics I’d check. The interviewer asked which metric I’d examine first and why, and I struggled because I’d prepared a comprehensive answer rather than a prioritized investigation.

The ninth company rejected me after a behavioral interview. The Engineering Manager asked about a time I’d made a technical mistake, and I described an incident where a configuration change had increased database load. I spent most of the answer explaining how we’d detected and corrected the problem.

He asked what I’d personally done wrong.

I started explaining the circumstances that had made the mistake possible.

He repeated the question.

I eventually admitted that I hadn’t validated the configuration under representative load before approving the change.

The manager thanked me and moved on.

The feedback said I needed to demonstrate stronger accountability.

I thought that was unfair until I listened to my recording of the answer.

I’d spent nearly four minutes describing the incident without clearly acknowledging my own mistake.

The Tenth Rejection Made Me Question My Experience

The tenth company was a financial technology business hiring a Senior Backend Engineer. The role involved Java services, PostgreSQL, and transaction processing, which matched my previous work closely. I passed the initial coding round and reached a technical interview with a Principal Engineer.

He asked about a production incident involving duplicate financial transactions. I described how we’d investigated repeated message delivery and added safeguards to prevent duplicate business effects. He asked how we’d handled operations where the external payment provider returned a timeout.

I explained that we’d used idempotency keys and checked the provider’s transaction status before retrying.

He asked what happened if the status endpoint was also unavailable.

I said we’d retry later.

He asked how we’d prevent the retry mechanism from repeatedly contacting an unavailable provider.

I started discussing exponential backoff.

He asked how we’d handle a transaction that remained unresolved for several hours.

I described a reconciliation process, but I hadn’t considered how the system should represent the uncertain outcome to customers during that period. The interviewer kept introducing realistic failure scenarios, and I kept trying to produce immediate answers.

By the end, I was exhausted.

The recruiter called four days later and said the team had decided not to proceed. The feedback was that my experience seemed relevant, but I needed to demonstrate more structured reasoning when dealing with unfamiliar failure scenarios.

I thanked her and ended the call.

Then I opened my spreadsheet.

Ten rejections in seventy-six days.

I had more technical notes than when I’d started, but I wasn’t sure I was becoming a better engineer.

My Friend Asked Me to Explain Something I Didn’t Know

That weekend, I met a former colleague named Daniel. We’d worked together on several backend services, and he knew how much time I’d been spending on interview preparation. I told him about the latest rejection and complained that companies seemed to expect candidates to know every possible failure scenario.

Daniel listened for a while.

Then he asked me a question about PostgreSQL behavior that I couldn’t answer immediately.

I started explaining what I thought would happen.

He interrupted me and asked whether I knew or was guessing.

I said I was making an educated guess.

He asked why I hadn’t said that at the beginning.

I told him interviewers didn’t usually reward uncertainty.

Daniel disagreed.

He said there was a difference between being uncertain and being careless. An engineer who admitted a knowledge gap and explained how to investigate it could be more useful than someone who gave a confident answer that turned out to be wrong.

I told him that sounded reasonable in theory, but technical interviews often rewarded speed.

He said some did.

Then he asked whether I’d want to work with an engineer who confidently approved a database change without understanding its consequences.

I said no.

He asked why I was trying to behave like that during interviews.

I didn’t have an answer.

We spent the next hour discussing how I’d approached the previous ten interviews. Daniel pointed out that I was treating every question as a test of whether I already knew the answer. When I encountered something unfamiliar, I tried to connect it to a topic I’d studied and produce an explanation quickly.

That approach worked when the connection was valid.

When it wasn’t, I sounded confident about something I didn’t understand.

Daniel suggested I practice a different kind of interview preparation. Instead of memorizing more answers, I should work through unfamiliar problems and explain how I’d investigate them.

I wasn’t convinced.

But I was tired enough to try.

The Eleventh Company Asked a Question I Couldn’t Answer

The next opportunity came from a recruiter at a software company building infrastructure for business customers. The position involved maintaining Java services, improving database performance, and investigating production incidents.

The first interview was with an Engineering Manager who asked about my previous projects. We discussed a service migration, a difficult database performance issue, and how I’d handled technical disagreements.

The conversation went well.

The second round was with a Staff Engineer named Michael. He explained that the interview would involve discussing production scenarios rather than writing code. He wanted to understand how I approached problems when the available information was incomplete.

He started with a PostgreSQL transaction that had been interrupted while waiting for a row lock.

He asked what would happen to the transaction after the statement was canceled.

I began explaining transaction isolation.

Michael stopped me.

He said that wasn’t the question.

I tried again, discussing rollback behavior and how Spring might handle exceptions. He asked whether I’d tested the scenario, and I realized I was relying on assumptions about several different layers of the system.

I told him I didn’t know the precise behavior.

He nodded.

Then he asked how I’d find out.

I explained that I’d first separate PostgreSQL behavior from application framework behavior. I’d reproduce the scenario using two database sessions, create a lock conflict, and trigger the relevant timeout or cancellation mechanism. I’d inspect the transaction state afterward and verify whether subsequent statements could execute before rollback.

Michael asked how I’d distinguish a PostgreSQL lock timeout from a client-side cancellation.

I said I’d examine the database error codes, server logs, and the behavior of the client connection. I’d also verify the relevant PostgreSQL documentation rather than relying on memory.

He asked how I’d test the behavior in a Spring Boot application.

I described writing an integration test against a real PostgreSQL instance, controlling the transaction boundaries, and checking how the framework handled the exception. I said I’d avoid assuming that behavior observed through JPA was identical to what happened in a raw database session.

Michael seemed satisfied.

We moved on to another scenario.

The Next Question Was Worse

Michael described a service that occasionally returned successful responses even though some downstream operations had failed. The application used asynchronous processing, and the team suspected that errors were being swallowed somewhere in the workflow.

He asked where I’d start.

I said I’d first clarify what the successful response was supposed to mean. If it only acknowledged that the request had been accepted, a downstream failure might be expected and should be represented through a separate operation status. If the response promised completed processing, then the system had a correctness problem.

Michael asked me to assume the response was intended to confirm completion.

I said I’d trace a single request through the relevant services and identify where the system decided the operation had succeeded. I’d examine logs, traces, and persisted state to determine whether the response was generated before all required operations completed.

He introduced another constraint.

The team didn’t have distributed tracing.

I said I’d use whatever correlation identifiers were available and inspect the relevant database records and message metadata. If correlation was insufficient, I’d add targeted instrumentation in a controlled environment to reproduce the failure.

He asked whether I’d immediately introduce a tracing platform.

I said no.

I’d want to understand the scope of the problem and the team’s existing observability before introducing another system. Better tracing might be valuable, but it wouldn’t automatically fix incorrect success semantics.

Michael nodded.

Then he asked how I’d handle a case where the operation’s final outcome couldn’t be determined.

I paused.

I told him I’d need to understand the business consequences before choosing a recovery strategy. For a financial operation, I wouldn’t blindly retry an uncertain outcome without a way to establish whether the original operation had completed.

He asked what I’d do if the external provider couldn’t confirm the result immediately.

I said I’d represent the operation as unresolved, preserve the information needed for reconciliation, and avoid telling the customer it had definitely failed or succeeded until the system had authoritative evidence.

We discussed the trade-offs for another fifteen minutes.

I didn’t know every answer.

But I was no longer trying to pretend I did.

The Interview Ended Without a Perfect Solution

Near the end, Michael asked whether I’d change anything about my investigation approach.

I said I’d probably prioritize establishing the system’s success semantics earlier because several later decisions depended on that definition. I’d also want to identify which failures could be safely retried and which required reconciliation.

He asked whether I thought the design was complete.

I said no.

We’d discussed several important failure scenarios, but I hadn’t addressed operational ownership, alerting, or how the system would recover after a prolonged outage. I explained which questions I’d investigate next and why they mattered.

Michael thanked me.

He said he’d enjoyed the discussion and appreciated that I’d been clear about which behaviors I understood and which required verification.

The interview ended after seventy minutes.

I closed my laptop and realized something unusual.

I wasn’t trying to remember every question I’d answered incorrectly.

I was thinking about the problems we’d discussed.

For the first time in weeks, a technical interview had felt like engineering work.

The Feedback Was Different This Time

The recruiter called two days later.

She said the technical team wanted to move forward.

I asked whether Michael had provided any feedback.

She said he’d been impressed by my structured reasoning and the way I’d handled uncertainty. He’d specifically mentioned that I hadn’t rushed into solutions when the requirements were incomplete.

I almost laughed.

For ten interviews, I’d been trying to eliminate uncertainty from my answers. I’d studied more topics, rehearsed explanations, and practiced speaking confidently because I thought that was what senior engineers were expected to do.

Now the first interviewer who’d explicitly praised my approach had done so because I was willing to acknowledge what I didn’t know.

The final interview was with the Engineering Director. He asked about my previous projects, how I handled production incidents, and what I’d do if a team needed to make a technical decision without enough information.

I explained that I’d identify the assumptions, evaluate the consequences of being wrong, and look for ways to reduce uncertainty before committing to an irreversible decision. I also said that sometimes teams had to proceed without complete information, but they should understand the risks they were accepting.

The director asked whether I’d ever made a decision that turned out badly.

I described the configuration change that had increased database load.

This time, I started by acknowledging my mistake.

I’d approved the change without validating it under representative traffic. The team had recovered quickly, but the incident had exposed a weakness in our deployment process. We added load testing for similar changes and improved the monitoring used during rollouts.

The director asked what I’d learned.

I said I’d become more careful about distinguishing assumptions from verified behavior, especially when a change could affect production reliability.

We discussed the incident for another ten minutes.

The interview ended with a conversation about the team’s current challenges.

I Received an Offer Three Days Later

The recruiter called on Friday afternoon and said the company wanted to hire me. The salary was within the range we’d discussed, and the team hoped I could start the following month.

I accepted.

After the call, I opened the spreadsheet I’d been maintaining since the beginning of the search. It contained ten rejections, dozens of technical questions, and notes about the mistakes I’d made during interviews.

I added the new offer.

Then I looked through the earlier entries.

Several rejections had been justified. I’d misunderstood requirements, overlooked failure scenarios, and struggled to explain technical decisions clearly. Some companies had preferred candidates with different experience, and others had provided feedback that was too vague to be useful.

I couldn’t know whether admitting uncertainty would have changed those outcomes.

But I could see how my preparation had gradually pushed me toward a behavior I didn’t respect in other engineers.

I’d been trying to sound certain about things I hadn’t verified.

That wasn’t how I approached production incidents.

When a service failed, I didn’t assume I knew the cause because I’d seen a similar problem before. I checked metrics, examined evidence, tested hypotheses, and changed my understanding when new information appeared.

During interviews, I’d been doing almost the opposite.

I heard a familiar technical term and rushed to produce an answer.

I Still Prepare for Questions I Can’t Answer

I haven’t stopped studying for technical interviews. Java concurrency, PostgreSQL transaction behavior, distributed systems, and production reliability still matter. A senior engineer needs a strong technical foundation, and uncertainty isn’t an excuse for avoiding difficult topics.

But I prepare differently now.

When I encounter a question I can’t answer, I try to identify exactly what I don’t understand. I separate facts from assumptions and think about how I’d verify the behavior in a real system.

Sometimes that means writing a small test. Other times it means reading documentation, examining source code, or discussing the problem with someone who has more experience.

I also practice explaining uncertainty clearly.

There’s a difference between saying I have no idea and saying I understand the general behavior but need to verify a particular edge case. The second answer gives an interviewer something useful to evaluate, especially when the role involves making decisions about production systems.

I still remember Michael asking what happened to a PostgreSQL transaction after a canceled statement.

After the interview, I reproduced several cancellation and timeout scenarios using real database sessions. I examined the error states, tested the behavior through Spring, and wrote down the differences I’d previously been mixing together.

The exercise took less than an afternoon.

I learned more from it than I had from several evenings of memorizing interview answers.

I still have the notes.

They’re in the same folder as the spreadsheet from those seventy-six days, alongside the questions I answered badly and the feedback I received from companies that rejected me.

I don’t look at the rejection count very often anymore.

But I occasionally open the PostgreSQL test when I’m preparing for a difficult technical discussion. It reminds me that the most dangerous answer in engineering is often the one that sounds convincing before anyone has checked whether it’s true.

I wish I’d understood that before the tenth rejection.

I might have spent less time trying to sound like a senior engineer and more time demonstrating how I actually worked.

Resources for Senior Backend Engineers

If you’re preparing for Java and backend engineering interviews, my Senior Java & Spring Boot Engineering OS covers concurrency, transaction management, PostgreSQL, and production debugging. For architecture interviews, the Senior & Staff System Design Interview OS focuses on distributed systems, reliability, and explaining engineering trade-offs under pressure.

I also write about production engineering, system design interviews, and software engineering careers on Substack. If you’re interested in practicing realistic architecture scenarios, you can request access to the ProdRescue System Design Lab private beta.

I Got Rejected From 10 Software Engineer Jobs. Then I Stopped Saying I Knew Everything was originally published in Engineering Under Pressure on Medium, where people are continuing the conversation by highlighting and responding to this story.

After 81 days of rejections, I finally reached a coding interview where everything worked. Then the interviewer told me to throw away my solution and start again with 23 minutes left.

The interviewer watched me delete forty-seven lines of working Java code. I’d spent the previous half hour implementing a solution that passed every test he’d provided, and I was beginning to think the interview might actually go well. Then he changed one requirement, asked me to remove the implementation, and told me I had twenty-three minutes to solve the problem again.

I looked at the clock in the corner of my screen. There were other ways to adapt the code, and deleting it seemed unnecessary, but I didn’t want to spend another interview arguing about the instructions. I’d already been rejected eleven times in eighty-one days, and I was becoming painfully familiar with the sound of a recruiter explaining that the team had decided to move forward with someone else.

I asked whether I could keep the original implementation in a separate file for reference. He said he’d prefer a clean solution and wanted to see how I’d approach the problem with the new constraint. I deleted the code, opened a blank class, and tried to remember the last time anyone had asked me to discard working software because a requirement had changed.

It was an ordinary Wednesday afternoon. I had $2,840 left in my savings account, three unanswered recruiter emails, and a Java interview that was beginning to feel like an expensive practical joke.

The First Four Rejections Had Made Sense

My job search started after I left a backend engineering position where I’d spent several years working with Java, Spring Boot, PostgreSQL, and internal services that processed financial transactions. I was comfortable investigating production incidents and maintaining systems with complicated business rules, but I’d never been particularly good at solving algorithmic problems while someone watched my screen.

The first company asked me to implement an LRU cache without using an existing library. I understood the data structures, but I made a mistake updating the linked list when an existing key was accessed. The tests caught it, and I spent the remaining time debugging pointer changes that should have been straightforward.

The second rejection came after a system design interview. I was asked to design a job scheduling platform, and I proposed a distributed architecture before clarifying whether the company actually needed to execute jobs across multiple regions. The interviewer spent most of the session pulling me back toward the requirements, which was embarrassing because I’d criticized exactly that kind of overengineering during architecture reviews at my previous company.

The third company wanted someone with more experience building infrastructure on AWS. I’d deployed applications to cloud environments, but I hadn’t personally designed every part of the networking and security configuration. The hiring manager was direct about the gap, and I appreciated that he didn’t pretend the decision was about cultural fit.

The fourth interview was the one that bothered me. The interviewer asked me to implement a bounded queue, and I wrote a solution using a lock and condition variables. It passed the tests, but I struggled to explain how interruption should be handled when a producer was waiting for capacity.

The feedback said my concurrency knowledge wasn’t strong enough for a senior role.

I’d spent years debugging concurrent services in production. I knew how to identify transaction conflicts, investigate thread pool exhaustion, and recognize when an asynchronous workflow could process the same operation twice. But I hadn’t been able to explain one detail of Java interruption semantics clearly enough during a forty-five-minute exercise.

I spent the following weekend reviewing ReentrantLock, Condition, BlockingQueue, and the difference between interruption and cancellation. By Sunday evening, I understood the topic considerably better, although I was also starting to resent how much of my job search involved studying things I'd rarely needed to implement from scratch.

By Interview Seven, I Had Started Hiding My Experience

The next few interviews were strange because I was technically improving while becoming less confident about describing my previous work. I could answer more questions about Java collections and concurrency, but I was increasingly worried about saying something that an interviewer might interpret as insufficiently senior.

During the fifth interview, I described a production incident involving a PostgreSQL database that had become overloaded after a deployment. The interviewer asked how we’d identified the problem, and I explained the query metrics, connection pool behavior, and application traces we’d examined.

He asked whether I’d personally written the fix.

I said another engineer had implemented part of the database change while I’d handled the application-side investigation and rollout verification. He asked whether I’d been the technical lead, and I explained that responsibility had been shared between several engineers.

The rejection arrived three days later. The feedback said I needed to demonstrate stronger ownership of complex projects.

For the sixth interview, I tried to emphasize my individual contributions more clearly. I described the decisions I’d made, the risks I’d identified, and the changes I’d implemented. The interviewer asked how I’d collaborated with the team, and I realized I’d spent so much time proving ownership that I’d barely mentioned the other engineers.

The company rejected me after the behavioral round.

By the seventh interview, I’d started preparing different versions of the same stories. One emphasized technical depth, another focused on leadership, and a third highlighted collaboration. I wasn’t inventing achievements, but I was choosing which parts of my experience to discuss based on what I thought the interviewer wanted to hear.

That made every conversation exhausting.

I remember finishing one interview and realizing I’d spent almost an hour talking about work I genuinely enjoyed without sounding particularly interested in any of it. I’d become so focused on avoiding rejection that I was speaking like someone presenting evidence in a legal dispute.

The Eighth Rejection Was the First One I Didn’t Understand

The eighth company was a mid-sized SaaS business hiring a Senior Backend Engineer to improve its data processing platform. The role involved Java services, PostgreSQL, and event-driven workflows, all of which matched my background.

The technical interview went well. I explained how I’d investigate delayed message processing, discussed the consequences of retrying operations after timeouts, and answered questions about transaction boundaries. The interviewer asked thoughtful follow-up questions, and the conversation felt like a discussion between engineers.

Two days later, the recruiter said the technical feedback was positive and scheduled a final conversation with the Engineering Manager.

We discussed team structure, code reviews, and how the company handled production incidents. I asked about the deployment process and whether engineers were expected to participate in on-call rotations. The manager gave detailed answers, and I left the interview believing I had a reasonable chance of receiving an offer.

The rejection arrived the following Monday.

The recruiter said the company had chosen someone whose experience was more closely aligned with its immediate needs. I asked whether there was a specific area where I could improve, but she said the team hadn’t provided additional feedback.

I added the rejection to my spreadsheet and stared at the screen.

The first few rejections had given me something concrete to work on. This one offered nothing beyond the knowledge that another person had been preferred.

I was beginning to understand why job searches could make experienced engineers question their abilities even when they were performing reasonably well.

Interview Eleven Lasted Seventeen Minutes

The eleventh interview was with a company that advertised a Senior Java Engineer position. The recruiter had described the role as primarily backend development, with responsibility for maintaining services and improving performance.

The interviewer joined the call seven minutes late and immediately asked whether I’d worked with Java 21. I said yes, although most of my recent production work had used Java 17. He asked me to explain virtual threads, and I described their purpose, how they differed from traditional platform threads, and the situations where they could improve the scalability of blocking workloads.

He asked whether virtual threads made synchronized code faster.

I explained that they didn’t automatically improve CPU-bound work and that pinning could affect scalability in certain situations. I also mentioned that the relevant behavior depended on the JDK version and the code being executed.

He interrupted me and asked for a simpler answer.

I tried again.

He then asked whether I’d used virtual threads in production. I said I hadn’t deployed a production system built around them, although I’d experimented with them and understood the trade-offs.

He said the company needed someone with practical Java 21 experience.

I reminded him that the job description listed Java 17 or newer and that the recruiter had confirmed my background was appropriate. He said the team had recently changed its requirements.

The interview ended after seventeen minutes.

I closed my laptop and went for a walk because I couldn’t think of anything useful to do with the rest of the afternoon.

For the first time, I seriously considered applying for positions below the senior level. I wasn’t convinced that would solve anything, but I was tired of spending weeks preparing for interviews that sometimes seemed unrelated to the work companies actually needed done.

The Twelfth Company Didn’t Ask Me to Explain My Résumé

The twelfth opportunity came through a recruiter named Hannah. She contacted me about a Senior Backend Engineer position at a company building software for logistics businesses. The engineering team maintained Java services responsible for processing shipments, calculating prices, and coordinating updates between external systems.

The job description wasn’t particularly exciting. It mentioned Spring Boot, PostgreSQL, REST APIs, and experience with distributed systems. There were no promises about revolutionizing an industry or building the next generation of artificial intelligence.

That was refreshing.

During our first conversation, Hannah asked about my previous projects and the kinds of problems I enjoyed solving. I told her I liked investigating difficult production behavior, improving unreliable systems, and designing services that other engineers could maintain without needing to understand every historical accident behind the architecture.

She laughed and said the team had plenty of historical accidents.

The first technical interview was with a Staff Engineer named Thomas. He asked about database transactions, message processing, and how I’d approach a service that occasionally produced duplicate customer notifications.

We discussed the difference between duplicate delivery and duplicate business effects. I explained how I’d investigate whether messages were being redelivered, whether consumers were retrying operations, and whether the database enforced the necessary uniqueness constraints.

Thomas asked how I’d verify the fix.

I described the tests I’d write and the production metrics I’d monitor. He seemed satisfied, and we spent the remaining time discussing the company’s existing architecture.

The recruiter called the next morning to schedule a coding interview.

I opened my preparation notes and tried not to get excited.

The Coding Exercise Looked Almost Too Simple

The interviewer was another Senior Engineer named Alex. He explained that the exercise involved processing a stream of events representing changes to customer orders. Each event contained an order identifier, a sequence number, and a new status.

The initial requirement was to maintain the latest status for each order. Events could arrive out of order, and the implementation needed to ignore updates with sequence numbers older than the most recently processed event.

I asked whether two events could have the same sequence number.

Alex said they could, but duplicate events would contain the same status.

I asked whether the input needed to be processed concurrently.

He said the initial version could assume a single thread.

I implemented the solution using a map that stored the latest sequence number and status for each order. The code was straightforward, and the tests passed. I added a test for out-of-order events and another for duplicate delivery.

Alex asked me to explain the time complexity.

I said each event required an expected constant-time map lookup and update, so processing (n) events would take expected (O(n)) time. Memory usage would grow with the number of distinct order identifiers retained.

He nodded.

Then he changed the requirement.

The system now needed to support a query that returned the status of an order at any historical sequence number.

I started explaining how I’d extend the data structure to retain history rather than only the latest state. I suggested storing an ordered collection of updates for each order and using binary search to locate the relevant version.

Alex asked whether I’d be comfortable rewriting the implementation around that requirement.

I said yes.

Then he asked me to delete the original code.

I looked at the clock.

Twenty-three minutes remained.

I Deleted the Code and Immediately Regretted It

My first instinct was to create a map from order identifiers to lists of events. If the events arrived in sequence order, I could append each update and use binary search for historical queries. But the original requirement allowed out-of-order delivery, which meant I couldn’t assume the list would remain sorted.

I considered using a TreeMap for each order, with sequence numbers as keys. That would make insertion and historical lookup logarithmic in the number of stored versions for that order. It also meant I needed to define exactly what a historical query should return when no event existed at the requested sequence number.

I asked Alex whether the query should return the latest known status at or before the requested sequence number.

He said yes.

I asked whether sequence numbers were unique per order or globally.

He said they were per order.

I started implementing the new version.

After about ten minutes, I had the core structure working. Each order mapped to a navigable map of sequence numbers and statuses. Incoming events were inserted into the appropriate history, and historical queries used floorEntry to find the latest event at or before the requested sequence number.

Alex asked what would happen if the same sequence number arrived twice with different statuses.

I reminded him that the original requirement said duplicate events would contain the same status.

He smiled and said the new version should detect conflicting duplicates rather than silently overwrite them.

I added a check.

Then I made a mistake.

While refactoring the code, I changed the method responsible for retrieving the current status. Instead of using lastEntry, I accidentally used the same lookup method as the historical query and passed an incorrect sequence number.

One of the tests failed.

I had six minutes left.

I started debugging, found the mistake, and corrected it. The tests passed again, but I hadn’t added every edge case I wanted.

Alex asked whether I was satisfied with the implementation.

I said the core behavior worked, but I’d want to add tests for empty histories, conflicting duplicate events, and large sequence numbers before considering it complete.

He asked whether I’d change anything about the data structure.

I said it was reasonable for the stated requirements, although retaining every event indefinitely would create a storage problem in a long-running service. If the history needed to be durable or the number of events became large, I’d reconsider whether an in-memory structure was appropriate.

He nodded and ended the exercise.

I closed the editor feeling exhausted.

The Interviewer Asked Why I Hadn’t Refused

Before ending the call, Alex asked me something unexpected.

He wanted to know why I’d agreed to delete the original implementation when I could have adapted it.

I told him he’d explicitly asked for a rewrite, and I’d assumed he wanted to evaluate how I approached the new requirement.

He said that was partly true, but he hadn’t required me to discard the working code. He’d asked whether I’d be comfortable rewriting it, and I’d agreed without discussing the cost.

I thought back to the conversation.

He was right.

I’d been so focused on following the interviewer’s instructions that I hadn’t explained why deleting the implementation might be unnecessary. In a real project, I would have preserved the working version, added tests for the new behavior, and refactored incrementally.

Alex asked what I’d do differently if the same situation occurred during a production change.

I told him I’d first identify which parts of the existing implementation could be reused. I’d write tests for the historical query requirement, change the data model, and keep the previous behavior working throughout the refactor.

He asked why I hadn’t done that during the interview.

I hesitated.

Then I told him the truth.

I’d failed eleven interviews in less than three months, and I’d become reluctant to challenge anything an interviewer asked me to do. I was worried that questioning the instruction would make me look difficult or unwilling to adapt.

Alex listened.

He said he’d seen candidates become overly cautious during interviews, especially when they’d been searching for work for a long time. He also said that experienced engineers were expected to question expensive changes when a safer approach was available.

We talked for another few minutes about how technical interviews differed from normal engineering work.

Then the call ended.

I Thought I’d Failed Again

I spent the evening replaying the exercise. The code had worked, but I’d made an avoidable mistake and hadn’t finished all the tests. I’d also admitted that I’d been rejected eleven times, which I immediately regretted because I worried it made me sound desperate.

I opened my spreadsheet and added notes about the exercise.

The most important observation wasn’t about TreeMap or binary search. It was that I'd agreed to discard working code without asking whether the rewrite was necessary.

At my previous job, I’d pushed back against changes that introduced unnecessary risk. I’d argued for smaller deployments, better tests, and incremental migrations. Yet during the interview, I’d abandoned those habits because I was afraid of disappointing someone who controlled the hiring decision.

That realization bothered me more than the failed test.

I’d spent eighty-one days preparing to demonstrate my engineering skills, and the interview process had gradually changed how I behaved. I was becoming more willing to follow instructions I didn’t fully agree with, even when my professional experience suggested a better approach.

I didn’t know whether Alex had intended to test that.

But I knew I hadn’t handled the situation the way I would have at work.

The Recruiter Called Two Days Later

Hannah said the engineering team wanted to move forward.

I asked whether Alex had provided feedback.

She said he’d been impressed by my technical reasoning and appreciated that I’d recovered from the implementation mistake without becoming defensive. He’d also mentioned our discussion about rewriting working code.

I asked whether that had been a concern.

She said he’d viewed it as a useful conversation about how I approached technical decisions under pressure. The team wanted to schedule a final interview with the Engineering Manager.

I was relieved, although I tried not to assume the process would end with an offer.

The final interview took place the following week. The manager asked about production incidents, technical disagreements, and how I handled changing requirements. I described a project where a business team had requested a major change shortly before release, and we’d negotiated a smaller implementation that met the immediate need without destabilizing the system.

He asked how I’d persuaded the team.

I explained the technical risks, the alternatives we’d considered, and how we’d divided the work into smaller changes. I also acknowledged that the original request hadn’t been unreasonable; the problem was the amount of risk involved in delivering it under the proposed deadline.

The manager seemed interested in the details.

We spent the remaining time discussing the team’s architecture and the challenges they expected the new engineer to handle.

Three days later, Hannah called with an offer.

I accepted.

The Twelfth Interview Didn’t Teach Me a New Algorithm

I don’t think deleting the code was a particularly good way to evaluate an engineer. The exercise could have tested the same design skills without requiring a candidate to discard a working implementation under time pressure. I also don’t know whether Alex would have evaluated me differently if I’d refused the rewrite.

What made the interview memorable was how quickly I’d abandoned my normal engineering judgment.

During those eighty-one days, I’d become increasingly focused on passing interviews rather than demonstrating how I actually worked. I memorized answers, practiced coding exercises, and tried to anticipate what each interviewer wanted to hear.

Some of that preparation was necessary. I’d made genuine technical mistakes during earlier interviews, and studying helped me correct them. I became better at explaining concurrency, database behavior, and system design trade-offs.

But I’d also become less comfortable saying that a requirement was unclear or that a proposed approach might be unnecessarily risky.

In production, those questions matter.

A senior engineer who silently accepts every instruction can create problems just as easily as someone who argues about every decision. The difficult part is knowing when to challenge an assumption and how to do it without turning the conversation into a contest.

I still have the coding exercise from that interview.

A few weeks after starting the new job, I recreated the problem on my own laptop. I implemented the original version, added the historical query requirement, and refactored the code incrementally while keeping the tests passing.

It took less time than the interview rewrite.

That didn’t prove I should have refused Alex’s instruction. It simply confirmed that I’d had a reasonable alternative and hadn’t taken the time to discuss it.

I kept both implementations.

The first reminds me of what I wrote when I was trying to pass an interview. The second reminds me of how I would have approached the same problem if nobody had been watching the clock.

I still practice coding problems before interviews, and I still make mistakes when someone asks me to explain an unfamiliar requirement under pressure. That hasn’t changed.

But when an interviewer asks me to throw away working code, I now ask what problem we’re trying to solve before I reach for the delete key.

Resources for Senior Backend Engineers

If you’re preparing for Java and backend engineering interviews, my Senior Java & Spring Boot Engineering OS covers concurrency, transaction management, PostgreSQL, and production debugging. For architecture interviews, the Senior & Staff System Design Interview OS focuses on distributed systems, reliability, and explaining engineering trade-offs under pressure.

I also write about production engineering, system design interviews, and software engineering careers on Substack. If you’re interested in practicing realistic architecture scenarios, you can request access to the ProdRescue System Design Lab private beta.

I Failed 11 Software Engineer Interviews. The Twelfth Asked Me to Delete My Code was originally published in Engineering Under Pressure on Medium, where people are continuing the conversation by highlighting and responding to this story.

I spent 58 days studying Java, system design, and distributed systems. The problem wasn’t that I couldn’t answer the questions. It was what happened when someone challenged my answers.

The interviewer closed my code editor with twenty minutes left in the session. I thought we’d finished early because my solution had passed the tests, but he hadn’t even looked at the final implementation. He leaned toward the camera, opened his notebook, and asked me whether I knew why the interview had become difficult.

I was confused. We’d spent forty minutes implementing an in-memory cache with expiration, and I’d answered every question he asked about concurrency and memory usage. There had been a disagreement about one design decision, but I’d explained my reasoning and believed the conversation was going reasonably well.

He told me my solution was technically defensible. Then he said he’d stopped evaluating the code fifteen minutes earlier because he wanted to see how I responded when someone disagreed with me.

I remember staring at the screen, trying to understand whether that was supposed to be feedback or another interview question. I’d spent almost two months wondering why companies kept rejecting me after technically strong interviews. Now someone was telling me that the most important part of the assessment had happened while I thought we were discussing a cache.

Seven Interviews in 58 Days

I’d started looking for a Senior Backend Engineer position after leaving a company where I’d worked on Java services, database-heavy applications, and production systems that occasionally behaved like they’d been designed by people who disliked sleep. I had several years of experience, and I was comfortable discussing the kind of problems that rarely appear in coding tutorials. I’d investigated connection pool exhaustion, fixed transaction boundaries, and spent enough time reading PostgreSQL execution plans to recognize when an innocent-looking query was about to ruin someone’s afternoon.

The first company rejected me after a coding interview. I wrote a working solution, but I ran out of time before handling an important edge case. The interviewer pointed it out, and I tried to explain how I’d fix it rather than implementing the correction. The feedback said my solution lacked completeness, which seemed reasonable even though I thought the core approach had been sound.

The second rejection came after a system design interview. I was asked to design an event-processing service, and I proposed Kafka before clarifying the expected throughput or operational constraints. The interviewer questioned whether the system needed Kafka at all, and I spent several minutes defending the choice. Looking back, I’d been more interested in explaining the technology than understanding the problem.

The third company rejected me after a behavioral round. The Engineering Manager asked about a technical disagreement, and I described a situation where I’d argued against a database migration because I believed it introduced unnecessary risk. I explained the technical details carefully, including the locking behavior and the potential impact on production traffic.

The manager asked how the disagreement had been resolved.

I said we’d eventually followed my recommendation.

He asked what I’d learned from the experience, and I told him it had reinforced the importance of understanding database behavior before approving production changes. He thanked me and moved on to another question.

The rejection arrived four days later. The recruiter said the team had concerns about collaboration and wanted someone who demonstrated stronger cross-functional communication.

I thought the feedback was unfair.

I’d prevented a risky deployment, and the company seemed more interested in how politely I’d disagreed than whether my concerns had been correct. I complained about it to a friend, who asked whether I’d explained what the other people involved had been trying to achieve.

I said their deadline had been unrealistic.

He suggested that wasn’t quite the same thing.

I Started Preparing for Interviews Like They Were Exams

After the fourth rejection, I changed my preparation routine. Every morning, I solved a coding problem before checking email. In the afternoon, I reviewed system design topics, and in the evening, I practiced explaining production incidents from my previous jobs.

I created documents covering Java concurrency, JVM memory management, database isolation levels, Redis caching strategies, and message delivery guarantees. I could explain the difference between at-least-once and at-most-once delivery without opening a browser. I could also describe several approaches to distributed locking, although I occasionally wondered whether I’d ever encounter a real system that needed half the complexity interviewers seemed to enjoy discussing.

The preparation helped me answer technical questions more confidently. During the fifth interview, I explained how I’d investigate a slow Spring Boot API and walked through the metrics I’d examine before changing configuration. The interviewer challenged my assumptions about database connection pooling, and I explained why increasing the pool size could make an overloaded database perform worse.

He asked whether there were circumstances where increasing the pool size would help.

I said there were, but only if the database had capacity and the application was unnecessarily restricting concurrency. He asked how I’d establish that, and I described the measurements I’d collect.

The conversation continued for another fifteen minutes. I thought it had gone well because I’d defended my reasoning with technical evidence.

The company rejected me after the next round.

The sixth interview involved a coding exercise with concurrent requests. I implemented the solution using synchronization and explained why the shared state needed protection. The interviewer asked whether I’d considered a different approach using immutable data structures.

I said the suggested approach would introduce unnecessary complexity for the requirements. He asked me to compare the two implementations anyway, and I spent several minutes explaining why mine was simpler.

The recruiter later told me the team had concerns about how I approached alternative solutions.

I was annoyed.

I thought interviewers wanted engineers who could make decisions and explain their reasoning. Apparently, some of them also wanted candidates who were willing to reconsider those decisions every time someone suggested something else.

By the seventh interview, I’d started expecting technical discussions to become arguments.

I didn’t notice that expectation changing the way I behaved.

The Seventh Interview Started With a Cache

The company built infrastructure software for business customers. Its backend services were written primarily in Java, and the engineering team maintained systems that handled substantial request volumes. The recruiter said the role required strong problem-solving skills and the ability to work independently on complex technical problems.

The first interview was with a Staff Engineer named Michael. He was friendly, spoke slowly, and seemed more interested in how I approached problems than how quickly I could produce code. We spent twenty minutes discussing my previous experience before moving into a live coding exercise.

He asked me to implement an in-memory cache with expiration.

The initial requirements were straightforward. The cache needed to support get, put, and removal operations, and entries should expire after a configurable duration. He said I could use standard Java libraries and should explain my decisions as I worked.

I started with a ConcurrentHashMap and stored each value alongside an expiration timestamp. On reads, the implementation checked whether the entry had expired and removed it if necessary. I explained that expired entries could remain in memory until accessed unless we introduced a cleanup mechanism.

Michael asked whether I considered that acceptable.

I said it depended on the workload and memory constraints. For a small cache with bounded usage, lazy expiration might be sufficient. For a long-running service with many keys that were rarely read again, we’d need an eviction strategy to avoid retaining expired entries indefinitely.

He nodded.

Then he asked what would happen if two threads attempted to update the same key simultaneously.

I explained that ConcurrentHashMap provided thread-safe map operations, but that wouldn't automatically make a sequence of operations atomic. If the cache needed conditional updates or compound state transitions, we'd need to define those semantics explicitly.

He asked me to add a computeIfAbsent operation that avoided duplicate loading when multiple threads requested the same missing key.

I modified the implementation and discussed how the loader should behave if it threw an exception. We also talked about whether the expiration timestamp should be calculated before or after the value was loaded.

Everything felt normal until Michael asked whether I’d considered using an existing caching library instead of building the implementation ourselves.

I said that in production, I’d probably use Caffeine unless there was a specific reason to implement a cache from scratch.

He asked why.

I explained that production caching involved more than thread-safe storage. We’d need to consider eviction policies, expiration semantics, memory usage, statistics, and behavior under concurrent access. A mature library would already handle many of those concerns.

Michael said he agreed, but he wanted to explore a scenario where the team had decided to maintain a small custom cache.

I told him that decision would need a strong justification.

He smiled and asked me to assume the decision had already been made.

I said I’d still question it.

That’s when the conversation changed.

I Thought We Were Debating Architecture

Michael asked what I’d do if the team had good reasons for keeping the implementation simple. Perhaps the cache was used in only one service, held a small number of entries, and didn’t need advanced eviction policies. Maybe introducing another dependency would create more maintenance work than the cache itself.

I explained that those constraints made sense, but I’d still prefer an established library because concurrency bugs were difficult to detect. I mentioned that even a small cache could develop subtle problems around expiration and loading behavior.

He asked whether I could imagine a situation where the custom implementation was the better choice.

I said it was possible, but unlikely.

He asked me to describe one.

I repeated that a small cache with limited requirements might be manageable, although I wouldn’t recommend it without understanding the operational risks.

Michael stopped typing.

He looked at me for a moment and asked whether I thought he’d suggested something unreasonable.

I told him I didn’t think the idea was unreasonable, but I believed it introduced unnecessary risk.

He asked why I kept returning to that conclusion when he’d already narrowed the requirements.

I started explaining concurrency again.

He interrupted me.

He said he understood the technical concerns and wasn’t asking me to abandon them. He wanted to know whether I could evaluate a decision within the constraints he’d provided, even if it wasn’t the choice I’d make independently.

I felt myself becoming irritated.

I’d spent weeks being rejected after technical interviews, and now I was being challenged for refusing to endorse an implementation I didn’t believe was appropriate. I thought the whole point of hiring a senior engineer was to bring judgment to technical decisions.

I told him that senior engineers shouldn’t agree with an approach simply because someone more experienced suggested it.

Michael said he agreed.

Then he asked whether I thought agreeing and understanding were the same thing.

I didn’t answer immediately.

He closed the code editor.

We still had twenty minutes left.

The Feedback I Hadn’t Expected

Michael told me the implementation was mostly correct and that my technical reasoning had been sound. He wasn’t concerned about my understanding of concurrency or expiration. What concerned him was that I’d treated every alternative he introduced as something I needed to defeat.

I told him I’d been trying to explain the risks.

He said he’d understood the risks after my first explanation. He’d continued changing the constraints because he wanted to see whether I’d adapt my recommendation when the problem changed.

Instead, I’d kept defending the original conclusion.

He asked whether I’d noticed that he’d agreed with several of my points.

I thought about the conversation and realized he had. He’d acknowledged the risks of custom caching, agreed that mature libraries were useful, and accepted that concurrency required careful handling. But each time he introduced a narrower scenario, I’d returned to the same argument.

Michael said that senior engineers often worked with incomplete information and competing priorities. A good technical decision wasn’t always the most sophisticated or theoretically safest option. Sometimes the team needed a small, understandable solution that met the actual requirements without creating unnecessary maintenance work.

I agreed with that.

He asked why I hadn’t approached the exercise that way.

I didn’t have an immediate answer.

After a moment, I told him I’d been rejected from several interviews recently and had become overly focused on proving that my decisions were technically correct. I said I hadn’t realized how defensive I’d sounded until he explained what he’d been evaluating.

Michael listened without interrupting.

He told me that technical confidence was valuable, but it became difficult to work with when every discussion turned into a contest. He said the engineers he trusted most were comfortable changing their minds when new information appeared.

We spent the remaining time discussing how I’d approach the cache differently.

I explained that I’d begin by clarifying the expected number of entries, expiration behavior, memory limits, and operational requirements. If the cache was small, isolated, and unlikely to grow, a custom implementation might be reasonable. I’d still document the concurrency assumptions and add tests for expiration and duplicate loading.

Michael nodded.

He said that was the discussion he’d been trying to have.

The interview ended a few minutes later.

I didn’t know whether I’d passed.

For once, I wasn’t particularly interested in guessing.

I Went Back Through My Previous Rejections

That evening, I opened the spreadsheet I’d been maintaining since the beginning of the search. I read the feedback from the third interview, where the Engineering Manager had questioned my collaboration skills. Then I looked at the notes from the sixth company, which had raised concerns about how I evaluated alternative solutions.

The comments had bothered me because they seemed vague.

Now I wondered whether I’d been ignoring a pattern.

I thought about the database migration story I’d told during the third interview. I’d focused on the fact that my technical recommendation had been correct. I hadn’t explained why the Product Manager wanted the migration completed quickly or how we’d worked together to find a compromise.

I remembered the sixth interview, where I’d dismissed an alternative concurrency approach because I believed my implementation was simpler. I hadn’t explored whether the alternative might have advantages under different requirements.

None of those situations proved that the companies had rejected me for the same reason.

But I could see how my behavior might have created a similar impression.

I’d been treating technical interviews as opportunities to demonstrate certainty. When an interviewer challenged an answer, I assumed they wanted me to defend it. If they suggested another approach, I felt pressure to explain why mine was better.

That habit had probably developed over years of working in environments where engineers were expected to justify every decision. During production incidents, hesitation could be expensive, and confidence sometimes helped teams move quickly.

But confidence wasn’t the same as refusing to reconsider.

I had become so worried about looking uncertain that I was making it difficult for interviewers to have a normal technical conversation with me.

The Rejection Arrived Anyway

Three days after the cache interview, the recruiter emailed to say the company wouldn’t be moving forward. She thanked me for my time and said the team had decided to pursue another candidate.

I asked whether Michael had provided feedback.

She said he’d appreciated my technical knowledge but had concerns about collaboration and adaptability during the exercise.

I wasn’t surprised.

I also wasn’t particularly angry.

For the first time during the search, I understood what the feedback referred to. I could remember the exact moments when I’d dismissed alternative approaches without exploring them. I could also remember how uncomfortable I’d felt when Michael challenged my reasoning.

I replied to the recruiter and thanked her for the opportunity.

Then I sent Michael a short message through LinkedIn.

I told him I’d appreciated the discussion and that his feedback had helped me recognize something I’d been missing in previous interviews. I didn’t ask him to reconsider the decision or explain why I’d behaved the way I had. I simply thanked him for being direct.

He replied the following day.

He said he was glad the conversation had been useful and wished me luck with the search.

That was the end of it.

The Next Interview Wasn’t Easier

The next company asked me to design a service that processed customer events and updated account state. The interviewer was a Principal Engineer who had spent several years working on distributed systems. He introduced failure scenarios throughout the discussion and challenged nearly every design decision I made.

Early in the interview, I proposed using an asynchronous workflow for processing events. He asked whether synchronous processing might be simpler.

My first instinct was to explain why asynchronous systems were better suited to handling variable workloads.

Instead, I asked what latency requirements the customers had and whether the upstream service could tolerate waiting for confirmation.

He explained that most requests needed a response within two hundred milliseconds, but the business operation itself could complete later. We discussed the difference between acknowledging receipt and confirming completion, then explored which parts of the workflow needed durable state.

Later, I suggested using a message broker to decouple processing stages. The interviewer asked whether the team could implement the same behavior using a database-backed work queue.

I didn’t immediately dismiss the idea.

We compared the approaches based on expected throughput, operational complexity, recovery behavior, and the team’s existing infrastructure. I explained that a database-backed queue might be sufficient at modest scale, particularly if the team already operated PostgreSQL reliably and wanted to avoid another distributed component.

The interviewer challenged that conclusion too.

He asked what would happen if processing volume increased significantly or if workers needed independent scaling. We discussed how the design might evolve and which measurements would justify introducing a dedicated broker.

The conversation lasted seventy minutes.

I made mistakes during it.

At one point, I overlooked a failure scenario involving an operation that had committed successfully before the worker crashed. The interviewer pointed it out, and I acknowledged the problem before adjusting the design.

I didn’t try to explain why my original approach had been reasonable.

I fixed it.

The recruiter called two days later to schedule a final interview.

The Final Interview Felt Like a Conversation

The Engineering Manager asked about my previous projects and how I handled technical disagreements. I described the database migration I’d discussed during an earlier interview, but this time I explained the business context before describing the technical problem.

The Product Manager had been trying to meet a customer deadline. The engineering team was concerned about the migration’s impact on production traffic, and I’d initially argued against the proposed schedule. We eventually agreed on a staged rollout that reduced the risk while allowing part of the feature to ship on time.

The manager asked what I’d do differently.

I said I’d present the trade-offs earlier and spend more time understanding why the deadline mattered. My technical concerns had been legitimate, but I’d made the conversation harder by treating the schedule as an engineering mistake rather than a business constraint we needed to work around.

He asked whether I’d ever changed my mind during an architecture discussion. I described a project where I’d initially favored introducing a message broker, but another engineer had suggested using a simpler database-backed workflow. After reviewing the workload and operational requirements, we’d chosen the simpler approach.

The manager asked whether that decision had worked.

I said it had worked for the original requirements, although the team later revisited the architecture when processing volume increased. I explained what we’d learned and why the initial decision hadn’t necessarily been wrong just because the system eventually needed to evolve. We spent the rest of the conversation discussing the team’s current challenges. I left the interview feeling tired but comfortable. The company made an offer the following week. I accepted.

I Still Disagree With Some of Those Interviewers

I don’t think every rejection was fair. Some interviewers asked vague questions and seemed frustrated when candidates interpreted them differently. Others introduced requirements late in an exercise and treated the resulting design changes as evidence of poor judgment.

I’ve also encountered interviewers who confused confidence with arrogance and disagreement with a lack of collaboration. A candidate can challenge an idea respectfully and still be a good teammate. Senior engineers sometimes need to push back when a decision introduces serious production risk, even when that makes the conversation uncomfortable.

But Michael hadn’t asked me to agree with him.

He’d asked me to consider a different set of constraints.

I’d spent most of the interview explaining why my original recommendation was better, even after the problem had changed. My technical knowledge hadn’t disappeared, but I’d made it harder for him to understand how I’d work with other engineers.

That distinction mattered.

I still prepare carefully for technical interviews. I review Java concurrency, database transactions, distributed systems, and the kinds of production failures that don’t appear in clean architecture diagrams. I want to be able to explain my reasoning clearly, especially when an interviewer challenges it.

The difference is that I no longer assume every challenge requires a defense.

Sometimes the interviewer has information I don’t have. Sometimes they’re testing whether I can adapt to new requirements. Occasionally, they’re simply wrong, and the right response is to explain why without turning the discussion into a personal contest.

I still have the notes from Michael’s interview.

They include the cache implementation, the concurrency questions, and the feedback about adaptability. I also wrote down the moment he closed the editor because I hadn’t realized how much of the interview I’d spent arguing about a decision he wasn’t asking me to defend.

I wish I’d recognized the pattern earlier.

It might have saved me several rejections, although I can’t know how those companies would have evaluated me if I’d behaved differently. What I do know is that I became better at technical interviews when I stopped treating every disagreement as a threat to my competence. The Java questions didn’t become easier. I just became more willing to listen before answering.

Resources for Senior Backend Engineers

If you’re preparing for Java and backend engineering interviews, my Senior Java & Spring Boot Engineering OS covers concurrency, transaction management, PostgreSQL, and production debugging. For architecture interviews, the Senior & Staff System Design Interview OS focuses on distributed systems, reliability, and explaining technical trade-offs under pressure.

I also write about production engineering, system design interviews, and software engineering careers on Substack. If you’re interested in practicing realistic architecture scenarios, you can request access to the ProdRescue System Design Lab private beta.

I Got Rejected From 7 Software Engineer Interviews. One Interviewer Finally Showed Me Why was originally published in Engineering Under Pressure on Medium, where people are continuing the conversation by highlighting and responding to this story.

I spent 72 days trying to prove I was worth hiring as a Senior Engineer. One question about my previous paycheck made me realize the company and I had been negotiating two completely different jobs.

The recruiter asked for my previous salary eleven minutes after telling me I’d passed the final interview. I’d spent nearly a month speaking with engineers, completing a coding exercise, and defending architectural decisions in front of two people who had considerably more experience than I did. The Engineering Director had said my background was exactly what the team needed, and the recruiter had already started discussing possible start dates.

Then she asked what I’d earned at my previous company. I told her I preferred to discuss compensation based on the responsibilities of the new position and the range we’d agreed on during our first conversation. She laughed politely and said she understood, but the compensation committee needed my salary history to prepare the offer.

I reminded her that she’d advertised the position at $145,000 to $175,000. We’d discussed my expectation of $160,000 before the first technical interview, and she’d confirmed it was within budget. She said none of that had changed, although she still needed the number.

I gave it to her.

There was a short silence before she asked whether the amount included bonuses. I told her it didn’t, and she said she’d get back to me after speaking with the compensation team.

The offer arrived three days later.

It was $128,000.

I Had Already Been Rejected Five Times

My job search had started in February, after I’d decided to leave a backend engineering position where I’d spent several years working with Java, Spring Boot, PostgreSQL, and distributed systems. I had enough production experience to apply for senior roles, but I wasn’t under the impression that every company would agree with my assessment. Some organizations expected senior engineers to lead projects independently, while others seemed to want someone who could design an entire platform, manage a team, and occasionally perform minor miracles with Kubernetes.

The first rejection came after a live coding interview. I’d implemented the main functionality correctly but missed an edge case involving concurrent updates. The interviewer asked how I’d prevent two requests from overwriting each other’s changes, and I started discussing application-level synchronization before considering whether the database could enforce the necessary constraint.

I knew the answer afterward, which made the rejection more irritating. I’d worked with optimistic locking before, but under interview pressure, I’d reached for a complicated solution to a problem that already had a reasonable one.

The second company rejected me after a system design round. I designed a notification service, discussed queues and retries, and explained how I’d handle temporary failures. The interviewer kept asking about customer preferences, and I realized too late that I’d designed the delivery infrastructure without properly considering when messages should be sent in the first place.

The third rejection came after a behavioral interview. The Engineering Manager wanted examples of cross-team leadership, and I described a production migration where I’d handled most of the technical work. He asked how I’d influenced other teams, and I struggled because I’d been responsible for implementation rather than organizational coordination.

That feedback was useful, even if I didn’t particularly enjoy receiving it.

By the fourth rejection, I’d started keeping a spreadsheet. I tracked interview stages, salary ranges, technical questions, and the reasons companies gave for rejecting me. The document helped me prepare, although it also made the entire process feel like a particularly unpleasant performance review conducted by strangers.

The fifth company took twenty-three days to reject me. I’d completed the coding round and spoken with the Engineering Manager, but the team eventually chose someone with more experience in its cloud infrastructure. The recruiter apologized for the delay and said she’d enjoyed working with me.

I thanked her.

Then I opened another job posting.

The Sixth Company Looked Different

The sixth opportunity came from a recruiter named Melissa. She contacted me about a Senior Backend Engineer position at a company building software for financial services businesses. The engineering team was expanding, and they needed someone comfortable with transaction processing, asynchronous workflows, and production reliability.

The job description mentioned Java, Spring Boot, PostgreSQL, Kafka, and AWS. I’d worked with most of those technologies, and the responsibilities sounded closer to my actual experience than several previous positions. More importantly, the advertised salary range was $145,000 to $175,000, which made the role financially attractive.

During our first conversation, Melissa asked about my compensation expectations. I told her I was targeting around $160,000, depending on the responsibilities and overall package. She said that was comfortably within the approved range and that the company wasn’t looking to hire at the bottom of the band.

I asked whether the role was definitely classified as Senior Engineer.

She confirmed it was.

That mattered because I’d already encountered companies advertising senior positions while evaluating candidates against intermediate-level compensation bands. I didn’t want to spend another month interviewing only to discover that the actual budget had never matched the job description.

Melissa assured me the position had been approved.

We scheduled the first technical interview for the following Tuesday.

The Technical Interviews Were Better Than I Expected

The first interviewer was a Staff Engineer named Andrew. He asked about my previous work with transaction processing and wanted to understand how I’d handled failures in asynchronous systems. We discussed a service where RabbitMQ messages triggered database updates, and he asked what happened if the database transaction committed but the consumer crashed before acknowledging the message.

I explained how we’d designed the processing operation to tolerate duplicate delivery. We discussed unique operation identifiers, database constraints, and the importance of making the business state transition idempotent. Andrew challenged a few assumptions, but the conversation felt like an architecture review rather than an examination.

The next round was a coding exercise involving account transfers. I needed to implement the business logic, validate account states, and ensure that concurrent requests couldn’t produce inconsistent balances. The interviewer introduced a scenario where two transfers attempted to debit the same account simultaneously.

I explained the trade-offs between optimistic and pessimistic locking, then implemented a version using database transactions and a locking strategy appropriate for the exercise. We discussed deadlock avoidance, transaction boundaries, and how the implementation would behave under higher load.

The interviewer said he’d enjoyed the discussion.

Two days later, Melissa called to say I’d passed.

The third round involved system design. The Engineering Director asked me to design a payment-processing workflow that could survive partial failures across multiple services. I started by clarifying the requirements, particularly whether the system needed immediate confirmation or could tolerate asynchronous completion.

We discussed duplicate requests, retries, and the difference between a failed operation and an operation whose outcome was unknown. I explained why blindly retrying a timed-out payment request could be dangerous without a stable idempotency key and a way to recover the authoritative result.

The director asked how I’d investigate a situation where customers were reporting duplicate charges despite the service returning errors. I described how I’d correlate request identifiers, payment-provider responses, database records, and message-processing logs before deciding whether the duplicates were real or merely duplicate notifications.

He nodded and said the team had encountered similar problems.

For the first time during the search, I felt that my production experience was being evaluated on its own terms.

The Final Interview Made Me Think an Offer Was Coming

The final conversation was with the Engineering Director and a Product Manager. They wanted to understand how I handled disagreements, estimated complex work, and communicated technical risks to people who didn’t spend their days reading logs.

The Product Manager described a situation where a customer had requested a feature that would require changing several services. The engineering team believed the work would take six weeks, but the commercial team had promised delivery in three. She asked what I’d do if I were responsible for the backend implementation.

I explained that I’d first identify which parts of the feature were essential for the customer and which could be delivered later. I’d also want to understand the technical risks, particularly whether the change affected existing transaction behavior or required a database migration. If the full scope couldn’t be delivered safely, I’d propose a smaller release with clear limitations rather than quietly accepting a deadline I didn’t believe.

She asked what I’d do if leadership insisted on the original deadline.

I told her I’d document the risks, present realistic alternatives, and help the team make an informed decision. I’d worked in environments where engineers were expected to solve every scheduling problem through overtime, and I didn’t think that was a sustainable substitute for planning.

The director seemed comfortable with the answer.

We spent the final fifteen minutes discussing the team’s current problems. They wanted to reduce incident frequency, improve deployment confidence, and make it easier for engineers to understand how transactions moved between services.

I asked whether the company had dedicated time for reliability work.

The director said it did, although urgent customer commitments occasionally disrupted those plans. He described several improvements already underway, including better tracing and a gradual effort to reduce dependencies between services.

The conversation ended after seventy minutes.

The next morning, Melissa called and said the engineering team wanted to move forward.

I thought the difficult part was over.

The Salary Question Came After Everything Else

Melissa sounded pleased when she told me I’d passed. She said the Engineering Director had been particularly impressed by my experience with production failures and that the team believed I could contribute quickly.

Then she asked about my previous compensation.

I’d earned $105,000 at my last company. That salary had been established several years earlier, before I’d taken on additional responsibilities and gained more experience with complex backend systems. It also reflected the compensation practices of a different organization, which was one reason I hadn’t considered it particularly relevant to the new role.

I explained that my previous salary was lower than the range we’d discussed, but I was targeting $160,000 because of the responsibilities and market level of the position.

Melissa said she understood.

She asked whether the $105,000 included bonuses, stock, or other benefits. I told her it was the base salary and that the company hadn’t offered meaningful equity compensation.

She said she’d submit the information to the compensation committee.

I didn’t expect the offer to match my exact target automatically. I understood that companies had internal salary structures and that compensation depended on experience, interview performance, and the scope of the role.

But we’d discussed the range before I’d invested nearly a month in the process.

I assumed the offer would at least fall within it.

Three days later, Melissa sent the compensation details.

The base salary was $128,000.

There was a modest annual bonus and a standard benefits package, but the guaranteed compensation was $17,000 below the advertised minimum.

I read the email twice.

Then I called her.

The Recruiter Said the Offer Was a Significant Increase

Melissa explained that the compensation committee had reviewed my experience, interview feedback, and previous salary. The team was enthusiastic about hiring me, but the committee believed $128,000 was an appropriate starting point.

I asked why the offer was below the advertised range.

She said the published range represented the broader compensation band and that individual offers depended on internal leveling.

I reminded her that the position had been advertised as Senior Backend Engineer and that she’d confirmed the approved range during our first conversation.

She acknowledged that we’d discussed it.

Then she said the proposed salary represented an increase of more than twenty percent over my previous base compensation.

I asked what that had to do with the value of the new position.

Melissa explained that the company considered previous compensation as one input when evaluating offers. She said the committee also wanted to maintain internal equity and avoid placing new hires too high within the band.

I understood the internal equity argument. If existing engineers with similar responsibilities were earning substantially less, the company had a legitimate compensation problem to address.

But I couldn’t understand why my previous employer’s salary decision should determine what this company was willing to pay for work it had already evaluated.

I asked whether the engineering team had recommended a different level.

Melissa said the technical feedback supported the senior classification.

I asked whether the role’s responsibilities had changed.

She said they hadn’t.

Then I asked whether the company would have offered more if I’d previously earned $150,000.

She didn’t answer directly.

Instead, she said the compensation committee considered each candidate individually.

That was the moment I stopped thinking of the offer as a misunderstanding.

I Asked the Engineering Director a Question HR Couldn’t Answer

I emailed the Engineering Director and thanked him for the interviews. I explained that I was interested in the position but concerned about the difference between the advertised compensation range and the offer.

He agreed to speak with me the following afternoon.

I told him the offer was $128,000, despite the published range starting at $145,000. He seemed surprised and asked whether I’d discussed the difference with Melissa.

I said I had.

He explained that engineering managers provided hiring recommendations, but compensation decisions were handled by HR and finance. He said he’d supported hiring me at the senior level and hadn’t been aware of the final number before it was sent.

I asked whether the team would expect me to perform the same responsibilities described during the interviews.

He said yes.

The role involved owning backend services, participating in architectural decisions, helping improve production reliability, and supporting less experienced engineers.

I asked whether someone hired at $128,000 would have different responsibilities from someone hired at $160,000.

He said the responsibilities would be determined by the engineering level rather than the individual’s salary.

That answer made sense from an organizational perspective.

It also confirmed that the company was asking me to perform the same job for substantially less compensation than we’d discussed.

The director said he’d speak with HR and see whether there was room to adjust the offer.

I thanked him.

For the next two days, I tried to decide what number I’d be willing to accept.

My Savings Were Making the Decision More Complicated

I’d been looking for work for seventy-two days. My savings were shrinking, and I’d already spent money on expenses I hadn’t expected when the search began. Every additional month without income made the next interview feel more important than the previous one.

The difference between $128,000 and $160,000 was $32,000 per year before taxes. That wasn’t a small amount, especially when I considered future raises and how long I might remain at the company.

But $128,000 was still more than I’d earned previously.

I could accept the offer, start earning again, and potentially negotiate a raise after demonstrating my value. Several friends suggested that approach because they knew how much the search had been affecting me.

One friend told me that a twenty-two percent increase was a good outcome after being unemployed.

I understood his reasoning.

Another asked whether I was prepared to lose the offer over a salary disagreement when I had no competing offer.

That question bothered me because I didn’t have a confident answer.

I’d spent weeks trying to convince companies that I was a capable senior engineer. Now a company wanted to hire me, and I was considering walking away because the compensation process felt unfair.

I wondered whether I was being stubborn.

I also wondered how I’d feel six months later if I accepted the offer and discovered that other engineers performing similar work had been hired at substantially higher salaries.

I couldn’t know what anyone else earned.

But I knew what the company had advertised and what we’d discussed before the interviews.

Those were the facts I kept returning to.

The Revised Offer Was Still Below the Range

Melissa called on Friday afternoon. She said the Engineering Director had advocated for an adjustment and that the compensation committee had approved a revised offer of $138,000.

She sounded pleased.

I thanked her for the effort and asked whether the company could reach $150,000. That was below my original target, but it was within the advertised range and reflected a compromise I could accept.

Melissa said she’d already pushed as far as she could.

She explained that $138,000 was the maximum approved amount and that the company needed an answer by Monday.

I asked whether there was an opportunity to revisit compensation after six months.

She said the company conducted annual performance reviews and that salary adjustments depended on business conditions and individual performance. There wasn’t a guaranteed six-month review.

I asked whether a signing bonus could help bridge the difference.

She said the company wasn’t offering one for the position.

I thanked her and said I’d think about it.

That weekend was unpleasant.

I opened the offer several times, compared the compensation with my expenses, and looked at the job description again. The engineering work still interested me, and the people I’d interviewed with seemed capable.

I didn’t think the company was necessarily a bad employer.

But I was uncomfortable with how the compensation conversation had unfolded. The range had been presented as approved, my expectations had been confirmed, and the offer had fallen below the minimum only after the company learned my previous salary.

I couldn’t prove that salary history was the deciding factor.

The timing and the recruiter’s explanation made it difficult to ignore.

I Turned Down the Offer on Monday

I called Melissa before lunch and told her I appreciated the revised offer but wouldn’t be accepting it.

She asked whether I’d reconsider if the company could provide additional flexibility around remote work or vacation. I told her those benefits were valuable, but they didn’t resolve the compensation difference.

She sounded disappointed and said the engineering team had been excited about hiring me.

I believed her.

That was what made the decision difficult.

I’d enjoyed the technical interviews and thought I could do the work well. I wasn’t rejecting the company because the engineers had treated me badly or because the role was uninteresting.

I was declining because the compensation process had changed the terms of a conversation we’d started almost a month earlier.

After the call, I sat at my desk and stared at the spreadsheet.

Five rejections, one offer declined, and seventy-two days without a new job.

I wasn’t particularly proud of how the numbers looked.

For the rest of the afternoon, I questioned the decision.

The Next Company Asked About Salary on the First Call

Two weeks later, I spoke with another recruiter about a Senior Backend Engineer role. The company built infrastructure software for business customers and needed someone with experience designing reliable Java services.

The recruiter asked about my salary expectations during our first conversation.

I said I was targeting $155,000 to $165,000, depending on the role’s responsibilities and the overall package.

He confirmed that the range was compatible with the position.

Then he asked whether I was comfortable sharing my previous salary.

I said I preferred to keep the discussion focused on the new role and its compensation band.

He said that was fine.

We moved on to my technical background.

The interview process took three weeks. I completed a Java coding exercise, discussed database performance with a Staff Engineer, and participated in a system design interview about processing customer transactions across multiple services.

I made a few mistakes.

During the coding round, I initially overlooked an edge case involving transaction retries. The interviewer pointed it out, and we discussed how the application should behave when the database operation succeeded but the client received a timeout.

I explained the failure scenario, corrected the implementation, and added a test.

The interviewer seemed satisfied.

The Engineering Manager asked about production incidents, technical disagreements, and how I approached unfamiliar systems. I described the work I’d actually done and tried to avoid turning every answer into a performance.

The company made an offer at $158,000.

I accepted.

I Don’t Think Every Company Uses Salary History the Same Way

Looking back, I can’t say whether the first company’s compensation committee would have offered me more if I’d refused to disclose my previous salary. They might have made the same decision based on internal budgets, leveling policies, or other factors I couldn’t see.

I also can’t know whether accepting $138,000 would have been a mistake. The role might have provided excellent experience, and the company might have increased my compensation later.

Those possibilities don’t change what happened during the process.

I’d spent weeks demonstrating my technical experience against a role with an advertised salary range. The company evaluated my coding ability, system design judgment, and production experience before deciding it wanted to hire me.

Then the compensation conversation shifted toward what I’d earned somewhere else.

That was difficult to reconcile with the way the technical interviews had been conducted.

The experience also made me think about how much information candidates are expected to provide during hiring. Companies ask about previous projects, difficult decisions, mistakes, employment gaps, and sometimes compensation history. Candidates are expected to answer clearly while knowing relatively little about how the organization evaluates those answers.

I don’t think every recruiter who asks about salary history is trying to underpay someone. Some are following established processes, and others may be working within policies they didn’t create.

But candidates should understand that the number they provide can become part of the negotiation, even when the new role has different responsibilities and a published compensation range.

I still keep notes from that job search.

The sixth company has the longest entry because I recorded every stage, the original salary discussion, the first offer, and the revised amount. I also wrote down the questions I wished I’d asked before agreeing to the technical interviews.

I haven’t deleted those notes.

The experience changed how I discuss compensation, but it didn’t make me better at Java or system design. I’d already demonstrated those skills during the interviews.

What changed was my willingness to ask for clarity before investing weeks in a hiring process.

I still prepare for coding rounds, architecture discussions, and questions about production failures. I want to demonstrate that I can do the work, and I understand that companies need to evaluate candidates carefully.

I also want to know whether we’re discussing the same job at the same compensation level.

After seventy-two days of interviews, that seemed like a reasonable thing to establish before anyone asked me to write another line of code.

Resources for Senior Backend Engineers

If you’re preparing for Java and backend engineering interviews, my Senior Java & Spring Boot Engineering OS covers transaction management, concurrency, PostgreSQL, and production debugging. For architecture interviews, the Senior & Staff System Design Interview OS focuses on distributed systems, reliability, and explaining engineering trade-offs under pressure.

I also write about production engineering, system design, and software engineering careers on Substack. If you’re interested in realistic system design practice, you can request access to the ProdRescue System Design Lab private beta.

I Passed 6 Software Engineer Interviews. Then HR Asked Me for My Last Salary was originally published in Engineering Under Pressure on Medium, where people are continuing the conversation by highlighting and responding to this story.

I spent 67 days fixing my technical answers, rewriting my résumé, and wondering why companies kept disappearing after the final round. One phone call made me question the entire search.

The recruiter called at 6:12 p.m., nearly an hour after I’d given up waiting for her. She sounded uncomfortable, which was unusual because she’d been cheerful throughout the interview process. I’d completed four rounds for a Senior Backend Engineer position, including a Java coding assessment and a system design interview that had gone surprisingly well. The hiring manager had even asked whether I could start before the end of the month.

She told me the company wouldn’t be moving forward. I asked whether the engineering team had raised any concerns, expecting another explanation about leadership experience or architectural judgment. Instead, she said the decision had been made after the reference checks, and she wasn’t authorized to share the details.

I sat at my desk for several minutes after the call, looking at the names I’d provided. One belonged to a former Engineering Manager, another to a Staff Engineer I’d worked with for nearly two years, and the third to a colleague who’d helped me investigate several difficult production incidents. I trusted all three, or at least I thought I did. The possibility that someone had said something negative about me hadn’t occurred to me until that evening.

What bothered me was that this wasn’t the first company to reject me after a promising final interview. It was the eighth rejection in sixty-seven days, and I was running out of explanations that made sense.

The First Month Wasn’t Particularly Alarming

I’d started looking for a new position after leaving a backend engineering role where I’d spent several years working on Java, Spring Boot, PostgreSQL, and asynchronous processing systems. I wasn’t expecting the market to be easy, but I had enough production experience to believe I could compete for senior positions. I’d handled incidents, reviewed architecture proposals, helped junior engineers, and spent more nights than I wanted debugging services that behaved perfectly in staging.

The first rejection came after a coding interview. I misunderstood part of the requirement, built a solution around the wrong assumption, and spent the final fifteen minutes trying to repair it. The interviewer was polite, but I knew I’d made a mistake before the call ended. I wrote down what happened and moved on, assuming the next interview would go better.

The second company rejected me after a system design round. They’d asked me to design a platform for processing large batches of customer events, and I’d spent too much time discussing Kafka before establishing the business requirements. When the interviewer introduced delayed events and conflicting updates, my design became increasingly complicated. The feedback said I needed to improve how I clarified constraints, which was difficult to argue with.

By the third interview, I was preparing more carefully. I practiced explaining transaction boundaries, database locking, and failure recovery without turning every answer into a lecture. I also started recording the questions I’d struggled with, because I didn’t want to keep making the same mistakes under different circumstances.

That approach seemed to work. I reached the final round at the third company, had a productive conversation with the Engineering Director, and received positive feedback from the recruiter. Then the company decided to hire someone with more experience leading cross-team initiatives.

I was disappointed, but I understood the decision. Someone else had been a stronger match, and there wasn’t much I could do about that.

The fourth rejection was less clear. I’d completed the technical interviews, discussed salary, and provided references when the recruiter requested them. A week later, she emailed to say the team had decided to pursue another candidate. I asked for feedback and received a polite response that didn’t explain anything.

I didn’t think much about the references at the time.

That was probably my first mistake.

I Was Getting Better at Interviews and Worse at Getting Hired

By the fifth interview, I could explain most of the technical topics companies were asking about without needing to rehearse every sentence. I knew how to discuss optimistic locking, PostgreSQL query plans, Spring transaction management, and the operational consequences of asynchronous messaging. I also understood that a good system design interview involved asking questions before drawing boxes, something I’d learned after embarrassing myself during the second rejection.

My confidence improved during the technical rounds, but the results didn’t. Companies kept telling me the engineering feedback was strong, then rejecting me after the final conversation. Sometimes the explanation involved leadership experience, and sometimes the recruiter said another candidate was a better fit. A few companies stopped responding altogether, which was especially irritating after they’d spent weeks asking me to make time for interviews.

I started wondering whether there was something wrong with the way I presented myself. Perhaps I sounded too confident, or maybe I wasn’t demonstrating enough ownership when discussing previous projects. I watched recordings of mock interviews, practiced answering behavioral questions, and asked a friend to challenge my explanations whenever I became vague.

He told me I sounded like someone who’d spent too much time preparing for interviews. My answers were technically accurate, but I kept adding details that nobody had asked for. He said I needed to explain what I’d actually done instead of trying to demonstrate that I understood every possible failure mode.

I tried to follow his advice. During the sixth interview, I described a production incident involving a Spring Boot service that had been exhausting its database connection pool. I explained how we’d initially suspected slow queries, discovered that requests were holding connections during external HTTP calls, and changed the transaction boundaries after verifying the failure behavior.

The interviewer seemed satisfied. He asked how we’d tested the change, and I explained the integration tests and gradual rollout we’d used to avoid introducing another incident. We spent another twenty minutes discussing related problems, and I left the call feeling that I’d finally communicated my experience clearly.

The company rejected me eleven days later.

The recruiter said the technical feedback had been positive, but the hiring team had decided not to proceed. I asked whether there was a specific concern, and she said she couldn’t provide additional details.

I added another row to my spreadsheet.

The Seventh Company Asked for References Before the Final Interview

The seventh opportunity came through a recruiter who’d contacted me about a Senior Java Engineer position at a financial technology company. The role involved maintaining payment services and improving the reliability of asynchronous workflows. The salary was reasonable, and the Engineering Manager seemed genuinely interested in my experience with production incidents.

After the second technical round, the recruiter asked me to provide three professional references. I sent the same names I’d used during previous applications because those people had worked closely with me and understood the systems I’d helped maintain. I assumed the company would contact them only if it was seriously considering an offer.

A few days later, I completed the final interview. The Engineering Director asked about technical disagreements, project ownership, and how I’d handled situations where my recommendations weren’t accepted. I described a migration where I’d raised concerns about a database change that could introduce locking problems during peak traffic.

The director asked whether the team had followed my recommendation. I explained that we’d eventually agreed on a safer rollout after reviewing the risks together. He seemed satisfied with the answer, and the interview ended with a discussion about the team’s current architecture.

The rejection arrived the following week. The recruiter thanked me for my time and said the company had decided to move forward with another candidate. I asked whether the reference checks had raised any concerns, but she said she couldn’t discuss the internal evaluation process.

That was the first time I seriously considered whether my references might be affecting the outcome.

I contacted the Staff Engineer I’d listed and asked whether any companies had called him. He said two recruiters had reached out, and he’d spoken positively about my technical skills and production experience. He also mentioned that one recruiter had asked several questions about how I handled disagreements with managers.

I asked what he’d said.

He told me he’d described me as someone who cared deeply about technical correctness and occasionally needed reminding that business constraints mattered too. He said he’d also explained that I was dependable during incidents and willing to take responsibility when things went wrong.

That sounded reasonable, although I wondered how it might have been interpreted by someone who’d never worked with me.

I thanked him and ended the call.

The Eighth Rejection Finally Made Me Ask an Uncomfortable Question

The eighth company was the one whose recruiter called me at 6:12 p.m. I’d passed the technical interviews, discussed salary, and received encouraging feedback from the Engineering Manager. The team wanted someone who could take ownership of several Java services and help improve production reliability, which matched the work I’d been doing for years.

After the rejection, I contacted my former Engineering Manager. His name was Robert, and we’d worked together during a difficult period when the team had been under pressure to deliver several projects simultaneously. We’d disagreed about deadlines and technical priorities, but I’d believed we’d ended our working relationship professionally.

I asked whether he’d been contacted by any recruiters.

He said he’d spoken with three companies.

I asked what they’d wanted to know.

He explained that most questions concerned my technical abilities, reliability, and communication. He’d told them I was a capable backend engineer who understood production systems and could investigate difficult problems independently.

Then he mentioned that some recruiters had asked whether he’d hire me again.

I asked how he’d answered.

Robert was quiet for a moment before saying he’d told them it would depend on the role and the team. He believed I was technically strong, but he thought I sometimes struggled when project priorities changed unexpectedly. He also said I could become frustrated when management decisions conflicted with my technical recommendations.

I didn’t respond immediately.

We’d discussed those disagreements before, and I knew he hadn’t invented them. There had been meetings where I’d become irritated because I believed the team was accepting unnecessary production risk. I’d argued strongly about deployment deadlines and occasionally made it obvious that I thought a decision was foolish.

But hearing Robert describe those situations as a reason he might hesitate to hire me again was different.

I asked whether he’d told recruiters about the projects I’d delivered successfully or the incidents I’d helped resolve.

He said he had.

Then he added that reference checks were supposed to provide a balanced assessment.

I understood his point, but I also realized I’d made an assumption that had never been tested. I’d listed Robert because he’d been my manager and could verify my responsibilities. I hadn’t actually asked whether he felt comfortable recommending me for another senior engineering role.

That was an important distinction.

I Had Chosen References Based on Their Titles

After speaking with Robert, I looked at the reference list I’d been sending to companies. I’d selected people with impressive job titles because I thought recruiters would take their opinions seriously. An Engineering Manager and a Staff Engineer seemed more credible than colleagues who’d worked beside me every day.

What I hadn’t considered was whether those people had the clearest understanding of my work or would provide the kind of reference I expected.

Robert had managed a team of engineers and was responsible for delivery schedules, staffing decisions, and performance reviews. His experience working with me was shaped by those responsibilities. He remembered the technical disagreements because they had affected his job, even when the underlying engineering concerns were legitimate.

The Staff Engineer had worked more closely with me on architecture and production incidents. He’d seen me investigate failures, review code, and help other engineers understand difficult problems. His assessment was more focused on technical judgment, although he also remembered occasions when I’d become frustrated during disagreements.

Neither perspective was necessarily dishonest.

The problem was that I’d treated professional references as a formality. I’d assumed that people who respected my technical abilities would automatically recommend me enthusiastically, regardless of how they viewed other aspects of my work.

I called another former colleague named Daniel. We’d worked together on a payment processing service for almost two years, and he’d been involved in several of the incidents I discussed during interviews. I asked whether he’d be comfortable serving as a reference and whether he had any concerns about recommending me.

He said he’d be happy to help.

Then he asked why I was suddenly worried about references.

I explained what had happened.

Daniel listened and said something I hadn’t expected. He told me Robert’s comments weren’t entirely surprising because we’d had several tense meetings during the final months of the project. He also said the team had respected my technical judgment, even when my communication could have been better.

I asked whether he’d mention those disagreements if a recruiter asked.

He said he wouldn’t pretend they hadn’t happened. But he’d explain the circumstances and describe how I’d worked with the team to resolve them.

That answer made me more comfortable than a promise to say only positive things.

I Changed the Way I Prepared for Reference Checks

For the next application, I asked each potential reference whether they felt comfortable giving a strong, honest recommendation for the specific kind of role I was pursuing. I explained the responsibilities, the seniority level, and the aspects of my experience the hiring team was likely to evaluate.

I didn’t ask anyone to hide problems or invent achievements. I wanted to know whether they genuinely believed I was a good fit and whether they could discuss my work with enough context to make their assessment useful.

One former colleague declined because we hadn’t worked together closely enough in recent years. I appreciated the honesty and removed him from the list. Another said he’d be happy to provide a reference but wanted to review the projects we’d completed together so he could give accurate examples.

I also stopped using Robert as a reference for roles where I needed someone to speak confidently about my technical leadership. He’d been honest about his reservations, and I didn’t want to put either of us in an awkward position by continuing to list him without discussing those concerns.

That didn’t mean I could erase his perspective. A future employer might still ask for a previous manager or contact someone independently where permitted. I needed to be prepared to discuss my professional relationships honestly rather than assuming a different reference list would solve every problem.

I also worked on the issue Robert had raised.

During interviews, I began explaining technical disagreements with more attention to how I’d communicated, what alternatives I’d offered, and whether I’d helped the team reach a workable decision. I stopped describing situations as though the main objective had been proving that my technical assessment was correct.

The change felt uncomfortable at first.

I was used to talking about production incidents in terms of symptoms, root causes, and fixes. Discussing the human side required admitting that I could be technically right and still handle a disagreement poorly.

That was harder than explaining PostgreSQL locking.

The Ninth Interview Was Different

The ninth company was a smaller SaaS business hiring a Senior Backend Engineer for its transaction platform. The first interview was with an Engineering Manager who asked about my experience maintaining production services. We discussed Java, Spring Boot, database performance, and the operational challenges of processing asynchronous events.

The technical rounds went well. I completed a coding exercise involving concurrent updates and participated in a system design interview about handling delayed and duplicate messages. The Staff Engineer challenged several assumptions, and I explained the trade-offs without trying to turn every answer into a demonstration of how much I knew.

During the final interview, the Engineering Manager asked about a disagreement I’d had with another engineer. I described a situation where we’d argued about deploying a database migration before a busy trading period. I’d believed the change introduced unnecessary risk, while the project manager was concerned about missing a customer deadline.

I explained that my initial communication had been too confrontational. I’d focused on the technical danger without presenting a practical alternative, which made the discussion less productive. We eventually agreed on a staged rollout with additional monitoring, but the process had taken longer than necessary because I hadn’t framed the problem well.

The manager asked what I’d learned.

I told him that raising a risk was only part of the job. A senior engineer also needed to help the team make a decision under real constraints, even when the available options were imperfect.

He nodded and moved on.

A few days later, the recruiter requested references.

This time, I sent the names of people who’d worked directly with me on the responsibilities the company cared about. I’d spoken with each of them beforehand, and they understood the role and felt comfortable providing an honest assessment.

The company completed the checks and scheduled a final conversation about compensation.

I received an offer the following week.

I accepted.

I Still Don’t Know What Happened at Every Company

It’s tempting to look back at those sixty-seven days and conclude that my references were responsible for all eight rejections. That would be a convenient explanation, particularly because it would mean my technical performance had been better than the results suggested.

But I don’t know that.

Several companies rejected me before requesting references. Others had legitimate reasons to prefer candidates with different experience. I made mistakes during coding interviews, struggled with system design questions, and occasionally failed to communicate my work clearly.

Even the eighth rejection didn’t prove that Robert’s comments had been the deciding factor. The recruiter said the decision followed the reference checks, but she didn’t explain which concerns mattered or how the hiring team evaluated them.

What I do know is that I’d spent weeks trying to improve the parts of the interview process I could see. I studied Java, practiced architecture discussions, rewrote my résumé, and rehearsed behavioral questions. I treated references as paperwork that happened after the important decisions had already been made.

That assumption was wrong.

A professional reference is another person’s account of what it was like to work with you. It includes technical ability, but it can also include communication, reliability, judgment, and how you behave when things become difficult. Those details may matter considerably to a company hiring someone who will influence architectural decisions and work across teams.

I still think Robert could have described some situations differently. I also recognize that he experienced our disagreements from a perspective I didn’t fully understand at the time. We were responsible for different things, and the same meeting could look very different depending on which responsibilities mattered most to you.

I haven’t spoken with him since that conversation.

I don’t particularly enjoy remembering it, but I no longer assume that someone will recommend me simply because we worked together for several years.

Before listing a reference now, I ask whether they’re comfortable recommending me for the position. I explain the responsibilities and give them an opportunity to decline. If they have concerns, I’d rather hear them directly than discover them through a rejection email after spending a month interviewing.

I still have the spreadsheet from those sixty-seven days. The entries contain technical questions, salary ranges, interview feedback, and notes about what I wanted to improve. The eighth company has a longer comment than the others because I added everything I learned after the reference checks.

The ninth entry says offer accepted.

For a while, I wanted to delete the earlier rows. They reminded me of a period when I’d spent almost every day wondering whether I was good enough to work as a senior engineer.

I kept them.

They remind me that technical interviews reveal only part of what companies are trying to understand. The rest often comes from conversations about how you work, how you handle disagreement, and whether people who know you professionally would choose to work with you again.

I wish I’d understood that before the eighth rejection.

It would have saved me several uncomfortable phone calls, although I’m not sure I would have been ready to hear the answers any earlier.

Resources for Senior Backend Engineers

If you’re preparing for technical interviews involving Java, Spring Boot, PostgreSQL, and real production problems, my Senior Java & Spring Boot Engineering OS covers backend architecture, transaction management, concurrency, and production debugging. For system design interviews, the Senior & Staff System Design Interview OS focuses on distributed systems, reliability, scalability, and explaining technical decisions under pressure.

I also write about production debugging, system design interviews, and engineering careers on Substack. If you’re interested in realistic system design practice, you can request access to the ProdRescue System Design Lab private beta.

I Failed 8 Senior Software Engineer Interviews. Then I Found Out What My References Were Saying was originally published in Engineering Under Pressure on Medium, where people are continuing the conversation by highlighting and responding to this story.

For 54 days, I thought my biggest problem was failing technical interviews. Then a company offered me the job, and I discovered something I hadn’t considered during the entire search.

The recruiter called at 4:36 on a Tuesday afternoon and told me the engineering team wanted to make an offer. I was standing in a supermarket, holding a carton of milk, and trying to remember whether I’d already paid my electricity bill. After nine rejections in less than two months, I had imagined this conversation enough times that hearing it happen felt strangely ordinary.

She told me the base salary was $118,000. The company would send the contract that evening, and they wanted me to start within three weeks. I thanked her, stepped outside because the supermarket was too noisy, and asked whether I could speak with the Engineering Manager one more time before accepting.

There was a pause. She asked whether something was wrong with the offer, and I said the compensation was fine. I just had a question about the team’s on-call rotation that nobody had answered clearly during the interviews.

She said she’d arrange a call.

I hung up and looked at the milk in my hand. I’d finally received an offer for a Senior Backend Engineer position, and instead of feeling relieved, I was trying to figure out why everyone had avoided telling me how often engineers got paged at night.

The First Rejection Had Been Easy to Explain

I’d started looking for a new job after leaving a backend engineering position that had become increasingly difficult to enjoy. The work involved Java, Spring Boot, PostgreSQL, and a collection of internal services that had grown considerably more complicated than anyone originally intended. I was comfortable with the technology, although I knew my system design skills needed work if I wanted to move into a stronger senior role.

My first interview was with a fintech company. The coding exercise involved implementing a transaction history endpoint, and I made a stupid mistake while handling pagination. I noticed it near the end, tried to correct it too quickly, and introduced another bug.

The interviewer was polite. He gave me time to explain what had gone wrong, but I could tell I hadn’t demonstrated the level of care the company expected. The rejection arrived two days later, and I didn’t spend much time arguing with it.

The second interview was harder to accept. I completed the coding round, discussed database indexing with a Staff Engineer, and reached the final system design interview. They asked me to design a notification platform capable of handling millions of messages per day, and I spent too much time discussing Kafka partitions before establishing what delivery guarantees the business actually required.

The interviewer kept asking what happened when a customer changed their notification preferences while messages were already queued. I answered, but I hadn’t designed the system around that requirement, so every new constraint made the architecture uglier. By the end, I was adding components to solve problems created by components I’d introduced twenty minutes earlier.

The feedback said I needed to improve how I clarified requirements before proposing a solution.

That one was fair too.

I wrote the feedback in a spreadsheet and started preparing more carefully.

By the Fourth Interview, I Was Practicing Answers I Didn’t Believe

The next few weeks became repetitive. I woke up, checked LinkedIn, submitted applications, answered recruiter emails, and spent evenings reviewing topics I hadn’t thought about since university. I practiced Java concurrency questions while eating dinner and watched system design explanations at twice their normal speed because there never seemed to be enough time.

One interviewer asked how ConcurrentHashMap worked internally. Another wanted to discuss garbage collection tuning, even though the role involved building REST APIs for an internal business application. A third asked me to design a distributed rate limiter and seemed annoyed when I asked whether the limits were per customer, per API key, or per IP address.

I started treating every question as something I should already know.

When I failed an interview, I’d spend the following evening studying the exact topic I’d struggled with. That seemed sensible until I realized I was preparing for the previous company’s interview instead of the next one.

My notes became ridiculous. I had pages about Java memory models, PostgreSQL execution plans, Kubernetes readiness probes, Kafka consumer rebalancing, and Redis eviction policies. Some of it was useful, but I was collecting technical information faster than I could turn it into practical understanding.

During the fourth interview, a Staff Engineer asked me to describe a production incident I’d personally investigated. I started explaining a database connection pool problem, then interrupted myself to mention metrics, tracing, transaction isolation, and the importance of identifying the root cause before changing configuration.

He stopped me.

“Can you tell me what actually happened?”

I realized I’d spent almost three minutes describing how a competent engineer should investigate an incident without explaining what I’d done during mine.

I started again.

The service had been timing out during peak traffic. We’d initially suspected slow SQL queries, but traces showed that some requests were holding database connections while waiting for an external service. We’d changed the transaction boundaries, tested the failure behavior, and deployed the fix gradually.

The interviewer nodded and asked why I hadn’t started with that.

I didn’t have a good answer.

The Fifth Rejection Hurt More Than the Others

The fifth company was a software business with around two hundred employees. The role matched my experience closely, and the recruiter had been unusually clear about the interview process. There would be a Java coding round, a system design discussion, and a final conversation with the Engineering Manager.

I passed the first two.

The final interview was with a manager named Laura. She asked about my previous work, how I’d handled technical disagreements, and what kind of engineering environment helped me perform well. We spent almost an hour discussing a difficult migration I’d worked on and how the team had managed the risks.

At the end, she asked whether I had any questions.

I asked about the team’s architecture and how technical decisions were reviewed. She gave thoughtful answers, and I left the call feeling confident enough to tell a friend that I thought an offer was coming.

Four days later, the recruiter called.

The company had chosen another candidate.

I asked for feedback, expecting something about leadership experience or system design. Instead, the recruiter said the team had liked me but believed the other candidate was a slightly better fit for the company’s current priorities.

That was all.

I stared at my laptop after the call, looking at the notes I’d taken during the interviews. There wasn’t a technical mistake I could identify or a particular question I needed to study. I’d done reasonably well, and someone else had done better.

For the first time, I wondered whether I was wasting my time trying to improve every interview.

My Bank Account Was Becoming Part of the Interview

By the sixth week, I was checking my finances more often than I wanted to admit. I had enough savings to keep looking, but each passing week made the search feel less like a professional decision and more like a problem that needed an immediate solution.

I started applying to positions I would have ignored earlier. Some offered less compensation than I wanted, while others involved technology I hadn’t used extensively. I told myself I was being flexible, although I knew the real reason was that I was getting nervous.

A recruiter contacted me about a Senior Backend Engineer role at a company that provided infrastructure for online businesses. The salary range was reasonable, the technology matched my experience, and the job description mentioned ownership of production services.

I scheduled the first interview.

The Engineering Manager was named Peter. He was friendly, spoke quickly, and seemed genuinely interested in my experience with payment systems and asynchronous processing. He explained that the company had grown faster than expected and needed engineers who could handle complex production problems without constant supervision.

I asked how the team organized its work.

He said they were a small group with considerable autonomy. Engineers were encouraged to take ownership, make decisions, and move quickly when customers needed something.

That sounded attractive.

I had spent enough time working in organizations where every small change required several meetings, and the idea of a team that trusted experienced engineers was appealing.

Peter asked about a production incident I’d handled. This time, I told the story directly. I explained what had failed, what evidence we’d gathered, which assumptions had been wrong, and how we’d verified the fix.

He seemed satisfied.

The technical interview went well too.

The System Design Interview Was Almost Enjoyable

The Staff Engineer asked me to design a service that processed customer events and updated account balances. The system needed to handle duplicate delivery, temporary database failures, and delayed messages from upstream services.

I started by clarifying the business requirements.

We discussed which operations needed strong consistency, how events were identified, and what the system should do when a message couldn’t be processed. I suggested a relatively simple architecture built around durable operation records and explicit state transitions.

The interviewer challenged the design, but the conversation felt collaborative. When he introduced a failure scenario involving a database commit followed by a consumer crash, we discussed how the application would recover without applying the same business operation twice.

He asked whether I’d introduce Kafka.

I said I’d consider it if the workload required its capabilities, but I wouldn’t choose it solely because the system processed events. We needed to understand throughput, retention, replay requirements, and the team’s operational experience before making that decision.

He smiled and said the company already used Kafka extensively.

I laughed and told him that was useful information, although it didn’t change the reasoning behind the design.

We finished the interview discussing monitoring and incident recovery. He said the team had been working on improving observability because engineers were spending too much time reconstructing failed workflows from logs.

I told him that sounded familiar.

The recruiter called the next day to schedule a final interview.

For the first time in weeks, I felt as though I was being evaluated on the work I’d actually done rather than my ability to remember answers from a technical interview guide.

Nobody Wanted to Talk About On-Call

The final interview was with Peter again, joined by another Engineering Manager. We discussed the team’s current priorities, including a migration from several older services to a more consistent platform architecture.

The conversation was productive until I asked about production support.

I wanted to know how many engineers participated in the on-call rotation, how often incidents occurred, and what happened when someone was paged outside working hours. Those questions mattered because the job description emphasized production ownership, and I’d worked in teams where that phrase meant very different things.

Peter said everyone shared responsibility for keeping the platform reliable.

I asked how frequently engineers were on call.

He said it depended on the team.

The other manager explained that they were still improving the rotation and that engineers sometimes helped outside their assigned shifts when incidents required additional expertise.

I asked whether they had a dedicated incident commander or a formal escalation process.

Peter said the team was small enough that people generally knew whom to contact.

I didn’t love that answer, but I also didn’t want to turn the final interview into an argument about incident management. I’d worked in imperfect organizations before, and the company seemed to be making an effort to improve.

We moved on to compensation.

The recruiter called two days later with the offer.

The Engineer I Contacted Didn’t Tell Me What I Wanted to Hear

After receiving the offer, I looked through LinkedIn and found an engineer who’d worked at the company for nearly three years. We had a mutual connection, so I sent him a short message asking whether he’d be willing to answer a few questions about the engineering culture.

He replied that evening.

His name was Michael, and he’d left the company four months earlier. He said he was happy to talk, although he warned me that his experience might not reflect every team.

We spoke the following morning.

I asked about the backend architecture, the quality of the engineering team, and whether the company invested in improving its production systems. Michael said the engineers were generally capable and that the technical problems were interesting. He’d learned a great deal during his time there.

Then I asked about on-call.

He laughed.

“Did they tell you how it works?”

I explained what Peter had said.

Michael was quiet for a moment, then told me that the rotation had been difficult during his final year. Engineers were officially on call for one week out of four, but serious incidents often required help from people who weren’t scheduled. Some services had unclear ownership, and the same engineers were repeatedly contacted because they understood particular parts of the system.

I asked how often he’d been paged.

He said it varied, but there had been periods when he was interrupted several nights a week. He’d occasionally spent the morning recovering from an incident and then joined normal project meetings because deadlines hadn’t changed.

I asked whether the company compensated engineers for on-call work.

He said there was no separate on-call payment during his time there, although the company had discussed introducing one.

I thanked him for being candid.

Before we ended the call, Michael said something that stayed with me.

“The job itself was good. I just got tired of never knowing when I was actually finished working.”

I Asked the Hiring Manager for One More Conversation

Peter agreed to speak the following afternoon. I told him I was interested in the position and appreciated the offer, but I wanted a clearer understanding of the production support expectations before making a decision.

He seemed surprised by how specific my questions were.

I asked how many pages the team had received during the previous month, how often engineers outside the rotation had been contacted, and whether the company had a plan to reduce recurring incidents.

Peter said he didn’t have the exact numbers available.

He explained that the team had experienced a difficult period during a recent migration, but he believed the situation was improving. He also said the company valued engineers who were willing to help when production systems needed attention.

I agreed that production ownership was part of senior engineering work. I’d responded to incidents outside normal hours before, and I understood that some problems couldn’t wait until morning. But I wanted to know whether the company treated those interruptions as exceptional events or simply accepted them as part of normal operations.

Peter said the organization was still working toward a more sustainable model.

I asked whether the company could share its current on-call policy.

He said there wasn’t a formal document that covered every team.

That answer made the decision harder.

I liked the engineering work, and I believed I could contribute. The compensation was good, the interviewers had been thoughtful, and the company was dealing with problems I knew how to solve.

But I’d spent months looking for a job, and I was about to accept a position without understanding one of its most important working conditions.

I Asked for Two Days to Think

The recruiter agreed to extend the offer deadline. I spent the next evening reviewing my finances, looking at the job description, and trying to separate what I knew from what I feared.

The company hadn’t lied to me. Peter had acknowledged that the on-call process needed improvement, and Michael had been careful to explain that his experience might not reflect the current situation.

Still, the lack of clear answers bothered me.

I had been so focused on passing technical interviews that I’d barely considered what I should be evaluating in return. During the first nine rejections, I treated every company as an opportunity I needed to earn. I’d studied their technology, researched their architecture, and prepared answers to questions I thought they might ask.

I rarely spent the same amount of effort understanding whether the job would be good for me.

That seemed ridiculous when I finally noticed it.

I had spent years learning how to identify risks in distributed systems. I’d challenge an architecture that relied on undocumented assumptions, unclear ownership, or recovery procedures that existed only in someone’s head.

Yet I was considering accepting a job where the on-call expectations were explained almost entirely through vague assurances.

I didn’t know whether the company would be a bad place to work.

I knew I didn’t have enough information to feel comfortable accepting the offer.

I Declined It

The recruiter called on Friday afternoon. I thanked her for the offer and explained that I wouldn’t be accepting because I couldn’t get comfortable with the production support expectations.

She sounded disappointed.

She asked whether compensation was the issue and said the company might have some flexibility. I told her the salary was reasonable and that increasing it wouldn’t resolve my concerns about the working environment.

She asked whether I’d reconsider if Peter could provide more information.

I said I appreciated the offer, but I’d decided to continue my search.

After the call, I sat at my desk for a while.

I’d spent fifty-four days trying to get a Senior Backend Engineer offer. I’d failed coding interviews, struggled through system design rounds, and watched recruiters disappear after promising feedback.

Now I’d rejected the first offer that felt genuinely attainable.

I wasn’t sure whether I’d made the right decision.

My bank account certainly didn’t think so.

The Next Interview Felt Different

Two weeks later, I interviewed with a smaller software company that maintained backend systems for business customers. The Engineering Manager explained the team’s architecture, the services I’d be responsible for, and the main technical problems they wanted to solve during the next six months.

When he asked whether I had questions, I asked about production incidents.

He told me the team had a four-person on-call rotation, shared the previous month’s incident statistics, and explained how engineers were compensated for additional work. He also described a recurring database performance issue they were trying to eliminate.

I asked whether engineers were expected to join normal meetings after spending the night handling an incident.

He said they were encouraged to take recovery time and that the manager was responsible for adjusting delivery expectations when incidents disrupted planned work.

I didn’t know whether the company always followed those practices.

But the manager had concrete answers, and he didn’t seem uncomfortable discussing the problems.

The technical interviews were challenging. I made mistakes, asked questions, and explained my reasoning without trying to sound like I’d memorized a system design textbook.

The company made an offer three weeks later.

The salary was slightly lower than the previous one.

I accepted.

I Still Think About the Offer I Turned Down

I don’t know whether the first company improved its on-call rotation. It might have become an excellent place to work, and I might have enjoyed the role despite the uncertainty. Michael’s experience was only one perspective, and Peter had seemed sincere about wanting to improve the engineering environment.

I also know that rejecting the offer was a risk.

I had been unemployed long enough that another month without income mattered. There was no guarantee the next company would hire me, and I couldn’t predict whether I’d regret the decision.

But the experience changed how I approached interviews.

For fifty-four days, I’d treated rejection as evidence that I needed to become a better candidate. Sometimes that was true. I’d made technical mistakes, struggled to communicate clearly, and occasionally prepared for the wrong things.

Other times, the company simply preferred someone else.

What I hadn’t considered was that passing an interview didn’t automatically mean I should accept the job.

I still prepare carefully for technical rounds. I review Java, practice system design, and think through production incidents I’ve handled. I want interviewers to understand what I can contribute, and I don’t expect companies to hire me simply because I’ve worked with their technology before.

But I also ask about the parts of engineering work that rarely appear in job descriptions.

I want to know who gets called when a service fails at midnight, how the team handles recurring incidents, and whether managers change delivery expectations when production work consumes an engineer’s week.

Those answers tell me something about the job I’m actually applying for.

I still have the spreadsheet from those fifty-four days. The first nine entries are marked rejected, with notes about technical questions, interview feedback, and the mistakes I wanted to avoid repeating.

The tenth entry says offer declined.

For a while, I considered changing it because seeing those words after so many rejections made me uncomfortable. I’d worked hard to receive an offer, and the idea of turning one down felt almost irresponsible.

I left it as it was.

The interview had gone well. The company wanted to hire me, and I’d finally demonstrated the technical experience I’d been struggling to communicate for weeks.

That part of the process had been a success.

I just didn’t want the job badly enough to ignore what I’d learned about it.

Resources for Senior Backend Engineers

If you’re preparing for technical interviews involving Java, Spring Boot, PostgreSQL, and real production problems, my Senior Java & Spring Boot Engineering OS covers the engineering decisions behind reliable backend systems. For architecture interviews, the Senior & Staff System Design Interview OS focuses on distributed systems, scalability, failure handling, and explaining technical trade-offs under pressure.

I also write about production debugging, system design interviews, and engineering careers on Substack. If you’re interested in practicing realistic system design scenarios, you can request access to the ProdRescue System Design Lab private beta.

I Got Rejected From 9 Software Engineer Jobs. The Worst Interview Was the One I Passed was originally published in Engineering Under Pressure on Medium, where people are continuing the conversation by highlighting and responding to this story.