|
Hey Reader, Welcome back to Guided Growth where we talk about the skills that accelerate your career beyond just writing great code. This is The Unwritten Rules #2: a 4-part series where I share the career rules that exist but nobody shared them with you.
Last quarter, I interviewed 11 candidates for a senior backend role. I asked all of them: "Design a URL shortener." 7 out of 11 gave me the same answer. Same structure. Same buzzwords. Same diagram that looked like it came from the same YouTube video. "Read-heavy system. NoSQL database. Base62 encoding. Redis cache. Load balancer. Scale horizontally." It's a correct answer. On paper. But when I can predict what you'll say next, it tells me you borrowed this knowledge. You didn't build it. One candidate, let's call him Rohan, started differently: "Before I design anything, how many URLs per day are we expecting? And is this a public tool like Bitly or an internal tool for a marketing team?" Two questions. That's all it took. Because the design for 1,000 URLs a day is completely different from 100 million. Most candidates skip this step and jump straight to drawing boxes. It's like a kid who memorizes "7 × 8 = 56" but can't figure out how many chocolates to buy for 7 friends who each want 8. Three things tell me you learned from videos, not from building: You over-engineer from the start. Microservices for 500 users. Kafka for a system that doesn't need event streaming. You can't answer "why." Why Redis and not Memcached? Why NoSQL and not Postgres? If you pause, I know you picked it from a template. You never mention failure modes. Real systems break. Builders know this because they've seen it happen. My advice: build the thing after you watch the video. That one weekend project teaches more than 10 tutorials. When I ask "why Redis?" you'll say "because I tried without it, and the latency was terrible." That answer can't be faked. Know someone preparing for system design interviews? Forward this to them. That's The Unwritten Rules #2. Next Thursday: the non-coding question I ask every candidate and the answer that decides everything. Thanks, Abhishek The Guided Growth |
Ex-Google | Stanford LEAD | Ex-Founder | Sr. Engineering Manager. Career systems for engineers who want FAANG offers, faster promotions, and leadership roles. 650+ interviews conducted, 1,100+ engineers mentored. Read by 178,000+ engineers across platforms.
Hey Reader, I study every single day. You might assume I have a free hour somewhere. I don't. My workday is full, and my evenings have calls. So I don't look for a free hour. A book I am reading right now says it in one line. You don't need more time. You need better systems. The book is How to Be Good at Life, by my friend Ben Meer. I am part way through it, and it has 40+ systems like the one I am about to show you. You can get it here. Here is my system. It has 3 slots. The gap after...
Hey Reader, Two weeks ago I posted: build your exit on day one. This is the day it paid off for me. I had joined Flipkart a few months earlier. I was not looking. I was still learning where things were. A Google recruiter messaged me on LinkedIn. Then called. Would I interview? They offered me two months to prepare Most people take it. I had a reason not to. I had a medical procedure booked about three and a half weeks out. Recovery would take time, and I was not going to cut it short for...
Hey Reader, Over the last two weeks I posted how WhatsApp works, in four blocks. This is what I see when I ask someone to build it in an interview. I sit on the other side of that table often. What follows is a composite. Not one person. A pattern. It does not matter what I ask Design WhatsApp. Design a parking lot. Design a URL shortener. The question changes. The failure does not. The candidate nods. Then, inside the first two minutes: load balancer. Database. Cache. Queue. Each word is...