Recently I interviewed a Senior Engineer. Strong candidate. Kafka? ✅ Redis? ✅ Microservices? ✅ Distributed systems? ✅ Then I asked: "You're building the inventory service for a flash sale. Only 1 item left in stock." Two users hit “Buy Now” at the exact same millisecond. Both requests pass the “is available?” check. Both create an order. Both deduct stock. Now you’ve sold 2 items when only 1 existed. How do you guarantee you never oversell — even with concurrent requests, client retries, and partial failures? "Just use a database transaction." Doesn’t fully solve it if both requests read `stock = 1` before either writes, or if the response is lost and the client retries. "Check stock before deducting." What happens when both checks happen at the same time? "Use Redis DECR and reject if it goes negative." What happens if Redis is down, or the decrement succeeds but the order is never persisted? Your turn: How would you design this inventory reservation API so concurrent buyers and retries never oversell the last item? There’s a specific distributed-systems concept behind this. And you’ll encounter it everywhere inventory, tickets, seats, coupons, and limited resources are involved.

Can anyone tell me if X will deduct tax on payout before submitting to my account ?

My manager said, “Be proactive.” So I proactively started looking for another job. Now HR wants to talk.

HTTPS just became ‘trust me, bro’ for unpatched Java.

Recently I interviewed a Senior Engineer. Strong candidate. AWS? ✅ S3? ✅ Microservices? ✅ Distributed systems? ✅ Then I asked: "You're building a document upload service using Amazon S3." A user uploads a 2 GB file. The upload succeeds, but your application crashes before saving the file metadata in the database. The user retries. Now the same file exists twice, and one copy has no database record. How do you guarantee that uploads remain consistent — even with concurrent requests, client retries, and partial failures? "Just upload the file, then save the metadata." What happens if the upload succeeds but the database transaction fails? "Use a database transaction." Can a database transaction roll back an object already written to S3? "Use a unique filename." What happens when the client retries with a new request ID, or two upload requests arrive simultaneously? Now you have orphaned objects, duplicate uploads, and inconsistent application state. Your turn: How would you design this upload API so retries don't create duplicate logical files, failed uploads can be recovered, and orphaned S3 objects can be cleaned up safely? There's a fundamental distributed-systems problem hiding behind this. And you'll encounter it everywhere files, databases, and external services must stay consistent.

What's harder to hire for: someone who can solve any LeetCode medium, or someone who can debug an unfamiliar production issue?

Database Interview: Two transactions. Transaction A: UPDATE accounts SET balance = balance - 100 WHERE id = 1; UPDATE accounts SET balance = balance + 100 WHERE id = 2; Transaction B: UPDATE accounts SET balance = balance - 200 WHERE id = 2; UPDATE accounts SET balance = balance + 200 WHERE id = 1; Both transactions work perfectly in isolation. Under concurrent traffic, one suddenly fails with a deadlock error. You add retries. The errors decrease, but don't disappear. Same database. Same queries. Same workload. What's the actual fix? And why can changing the order of two updates solve the problem? 🤔

Unpopular opinion: Retries can make a failing distributed system fail even harder. A service is already overloaded. Every caller retries. Traffic multiplies. The service gets slower, triggering even more retries. Sometimes the most resilient thing your service can do is fail fast. When should a backend service retry—and when should it stop?

My manager said, “You need more visibility.” So I turned on my webcam. Still no promotion.

Backend hot take: Caching is not automatically a performance optimization. It can introduce: Stale data Cache stampedes Invalidation bugs Extra infrastructure Another failure mode during an outage Sometimes a well-indexed database query is simpler, cheaper, and more reliable. Do engineers reach for Redis too quickly?

Unpopular opinion: A senior backend engineer who can explain every detail of HashMap internals but can't debug a production incident isn't as strong as we think. Knowing internals matters. But diagnosing unfamiliar failures, understanding trade-offs, and making safe changes under pressure matter more. What separates a genuinely senior engineer from someone who's just good at interviews?

Database Interview: Your Spring Boot API works perfectly in testing. Production traffic increases. Suddenly: API latency jumps to 10 seconds Database CPU is only 35% No slow query explains the delay Requests start timing out You increase the database connection pool size. Things get worse. You restart the application. Everything works again — temporarily. The database isn't overloaded. So what exactly is running out? And why can increasing the connection pool make a healthy database struggle? 🤔

Hot take: A poorly designed monolith is often easier to fix than poorly designed microservices. With microservices, one simple feature can involve: 4 network calls 3 retries 2 distributed tracing dashboards 1 incident nobody can explain We traded deployment complexity for operational complexity. When are microservices actually worth it?

Unpopular opinion: Adding an index is one of the most overused solutions to database performance problems. Sometimes the real problem is: A bad data model An inefficient query Fetching columns nobody needs An application making 100 unnecessary queries Not every slow query needs another index. Agree or disagree? 👇

Backend Interview: Your API has 3 replicas. Everything works perfectly. Then traffic increases. Suddenly, users receive this error: 401 Unauthorized But here's the strange part: Refresh the page → works. Call the API again → works. Same token. Same user. Same endpoint. Logs show no authentication failures from the identity provider. You restart one replica. The errors disappear. For a while. No database issue. No network outage. No expired tokens. What could cause this? 🤔 And why would restarting just one application instance temporarily fix the problem? Bonus: How would you prove your hypothesis without restarting anything?