The prompt was gentle: “Design a simple way to save user preferences.”
I should have sketched an in‑process cache with a periodic file dump.
Instead, I started drawing Kafka pipelines, multi‑AZ Postgres, and feature‑flagged rollouts.
Five minutes in, the interviewer’s polite smile said, “Buddy, please land the plane.”
Why I spiraled
- Over‑engineering is my comfort blanket. Give me a screwdriver and I’ll build a spaceship—because spaceships are fun.
- I forgot to ask the basics: How many users? How fast? What happens if it fails?
- I equated “impressive architecture” with “good answer.” Spoiler: they’re not the same.
The gut punch
Walking out, I felt the flush of embarrassment. I knew the real solution was twenty lines of code, not a conference talk.
That moment reminded me: my superpower can be my kryptonite if I don’t leash it.
How I keep myself honest now
- Write the constraints first. If they fit on a Post‑it, so should the design.
- Ask, “Would I build this on a hack‑day?” If the answer is no, scale it back.
- Invite a non‑engineer friend to listen. If they get lost, I’ve likely gone off the rails.
Over‑engineering will probably always tug at my sleeve.
But each time I catch it early, I trade rocket science for a working, lovable feature—and that’s the whole point.