Article

Migrating one service to Spring Boot 4 is a weekend project. Migrating sixty is a program — and programs fail in a specific way: every team independently rediscovers the same seven errors, burns a week each, and the “migration” becomes sixty snowflake upgrades with sixty subtly different outcomes. The fix is a discipline with an unfriendly name and a friendly result: solve every error once. When a team hits a migration error, the output isn’t a fixed service — it’s a permanent, automated fix that no other team ever has to think about again. Here’s the playbook. ...

“Detect a cycle in a linked list.” Everyone recites it: slow moves one step, fast moves two, if they meet there’s a cycle. Then the interviewer says “why can’t fast skip over slow?” and the room goes quiet. Then “find where the cycle starts” — and the memorized answer runs out. Floyd’s tortoise and hare is a two-minute algorithm with a twenty-minute understanding. Here’s the understanding. The shallow answer (and why interviewers hate it) The HashSet version works and every candidate knows it: ...

The symptom is always the same: heap usage climbs a little every day, GC reclaims less and less, and eventually someone sets a cron to restart the service at 3 AM. The heap dump shows nothing obviously wrong — no giant cache, no runaway collection. Just thousands of ordinary objects that should have died with their requests, all reachable through one path: Thread → ThreadLocalMap → Entry. This is the ThreadLocal leak, and it’s the quietest memory leak in Java. ...

Every message-driven system eventually meets its poison message: one malformed payload, one downstream bug, one record that will never process successfully — retried forever, burning CPU, and in the worst designs blocking every message queued behind it. The dead letter queue is the answer, but “just add a DLQ” hides three decisions: how many attempts before giving up, what counts as an attempt, and who gets woken up when something lands in the DLQ. Get any of them wrong and the DLQ is theater. ...

“How does HashMap work?” opens half of all Java interviews. Most candidates answer “array of linked lists, O(1) lookup” — and then the follow-ups start, and the room gets quiet. The interviewers aren’t testing whether you’ve memorized the structure. They’re testing whether you know why it’s built the way it is. Here are the questions that expose shallow knowledge, with the answers that don’t. Question 1: Why does HashMap mangle your hashCode? Everyone knows hashCode() feeds the map. Almost nobody asks what HashMap does to it first: ...