Explaining the things people pretend to understand · Page 6

How to decide where each request goes without treating the load balancer like a magic box in the diagram.

The useful part of CAP starts when parts of the system stop seeing each other and you need to decide whether to wait or keep responding.

How to think about scale by starting with what breaks first and why.

How to answer questions about reliable systems without falling into empty promises, pretty numbers without context, or architecture theater.

What idempotency is, why it matters in distributed systems, and how to implement it so unstable networks do not corrupt data.

When to use a queue instead of a synchronous call, what the main patterns mean, and why that changes the architecture in production.

How to investigate broken code with order, hypothesis, and a clear next step under uncertainty.

How to separate technical release from feature exposure without using flags as a crutch for a bad release process or deploys as the only product lever.

How to decide between rolling back, turning things off, degrading, or containing a bad release with operational clarity.

How to distinguish these three concepts without buzzwords and explain the role of each one clearly in a real context.

How to investigate a real production problem with a clear process for evidence, containment, and communication.

In frontend interviews, a strong answer does not stop at debounce. It talks about request concurrency, UI states, client-side cost, and experience trade-offs.

How to organize event names, conventions, and properties without turning analytics into bureaucracy that nobody can maintain.

How to choose metrics that help engineering make decisions and avoid pretty dashboards with no usefulness.

How to investigate a bug in a disciplined way and reduce noise while you test hypotheses.

How to think about frontend testing strategy without becoming hostage to too many mocks, too many clicks, or too little confidence.

How to think about on-call in a sustainable way, with better signals, process, and learning instead of reactive heroics.

A more serious way to improve Largest Contentful Paint without randomly compressing whatever file is nearby.

Not every kilobyte deserves a fight. What matters is the real cost of that JavaScript on the user's path.

How to see the full path between writing code, validating it, packaging it, releasing it, and operating it without treating deploy like magic.

How to separate different kinds of slowness so you can attack the right layer.

How to build dashboards that actually guide product and engineering decisions instead of just showing pretty numbers in a weekly review.

How to turn an incident into useful learning instead of blame, empty process, or polished corporate filler.

How to make timing failures easier to understand by making ordering, concurrency, and shared state visible.