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
I write the constraints first. If they fit on a Post-it, so should the design. I ask myself, "would I build this on a hack-day?" If the answer is no, I scale it back. And sometimes I explain my design to a non-engineer friend. If they get lost, I've probably 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.