Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Prepare for System Design Interviews
Transcript
- Lucas: So you've got the coding round down, you can reverse a linked list in your sleep, and then the recruiter tells you the next round is system design. And if you're like most engineers I've coached — that's the moment your stomach drops. Luna: Yeah, it's the one where you can't just grind LeetCode. It's open-ended, it's vague, and it feels like the interviewer is looking for something you either have or you don't. Lucas: Exactly. And the worst prep advice I see on forums is — 'just read Designing Data-Intensive Applications' or 'memorise the blueprint for Twitter.' That's like saying you can prepare for a marathon by watching a documentary about runners. Luna: What's the better approach? Lucas: I've been collecting frameworks from senior engineers I've interviewed, and the one that keeps coming up is from an Amazon principal engineer — I'll call him Dan. Dan says the interview is really about four steps. Step one: clarify the scope. Most candidates dive straight into drawing boxes and arrows. They miss that the first job is to ask questions. Luna: Like what kind of questions? Lucas: Who are the users? Is this read-heavy or write-heavy? Do we need real-time updates or is eventual consistency fine? Dan says a strong candidate spends the first three to five minutes just narrowing the problem. For example, if they ask you to design a video platform — don't assume it's YouTube. Ask: are we talking short-form like TikTok or long-form like Netflix? That changes everything. Luna: Right, because the storage and delivery pipeline for a ten-second clip is radically different from a two-hour movie. Lucas: Step two: define the data model. Before you talk about servers or load balancers, figure out the core entities and how they relate. For a Twitter-like timeline, the entities are user, tweet, follow, and timeline. And the key relationship is that a user's timeline is populated by tweets from people they follow. If you can describe that in a few lines, you've already shown you can think structurally. Luna: And the interviewer can see if you're going to build something that actually works. Lucas: Step three: estimate scale. How many daily active users? How many tweets per second? How much storage per user? Dan says most candidates skip this or get it wildly wrong. But it's the step that determines which parts of your architecture matter. If you're building a system for ten thousand users, you don't need sharding. If you're building for a hundred million, you do. Luna: So it's not about getting the number exactly right — it's about showing you know how to reason about order of magnitude. Lucas: Exactly. And then step four is the actual deep dive. Here's where you talk about components — but you pick one or two and go deep. Don't draw every microservice. Pick the most interesting bottleneck. In a video platform, maybe it's the upload pipeline. Walk through: client sends a chunk, the API gateway receives it, it goes to an object store like Amazon S3, a message queue triggers a transcoding worker, the worker converts the video into multiple resolutions, and it stores the metadata in a database. That level of detail shows you understand real systems. Luna: I hear a lot of candidates memorising things like 'we'll use Redis for caching and Kafka for messaging' — but they can't explain why. Lucas: Right. And the interviewer will smell that a mile away. A better approach is to say, 'For a read-heavy workload like a social feed, I'd use a cache to reduce database load. I'd probably start with Redis because it supports complex data structures like sorted sets, which work well for ranking tweets by timestamp.' That shows you understand the trade-off, not just the buzzword. Luna: So the framework is: clarify, model, estimate, dive. But how do you actually practise that? You can't just read a book and expect it to stick. Lucas: That's the thing. The best practice is mock interviews with a peer who gives real feedback. But if you're on your own, pick a popular system like YouTube, Twitter, or Uber — and try to walk through the four steps out loud. Record yourself. You'll quickly notice where you get stuck. Most people get stuck on the estimation step, because they never had to think about numbers like 'ten thousand writes per second' before. Luna: And if you don't have a peer to practise with — which is a lot of people — there's another way to get that feedback. Lucas: Yeah, and I want to share something honest about that. A handful of listeners chip in monthly through buy me a coffee dot com slash fexingo, and that's literally what funds making episodes like this one — and the deeper resources we're working on. Luna: And it keeps us completely ad-free, so we can dive into frameworks like Dan's without worrying about selling you a course. Lucas: Exactly. We're not a giant media company — it's just a small team, and listener support is what keeps the lights on. Okay, back to practising system design. So you've walked through YouTube out loud. What's a common mistake people make? Luna: I'd guess they try to design the entire thing in thirty minutes. Lucas: That's the number one mistake. Dan says the best interviews are the ones where the candidate picks one component and goes three levels deep. For YouTube, instead of describing every service, talk about the upload pipeline in detail. Describe how you handle chunked uploads, how you verify the video isn't corrupted, how you generate thumbnails. That tells the interviewer you've actually thought about building something. Luna: And you can use that depth to showcase your experience with a specific technology — like how you've used FFmpeg for transcoding, or how you've worked with S3 event notifications. Lucas: Right. And that's the other hidden rule: the system design interview is as much about communication as it is about technology. The interviewer wants to see if you can lead a conversation. Can you ask clarifying questions? Can you pivot when you realise your initial approach is wrong? A lot of candidates freeze when the interviewer says 'what if we need to support a billion users?' and they don't know how to scale. Luna: So how do you handle that pivot gracefully? Lucas: You say something like, 'Okay, at that scale, our single database will be a bottleneck. Let me think about sharding. We could shard by user ID using consistent hashing, which minimises reshuffling when we add nodes. Then each shard handles a subset of users.' That's a confident pivot. You're not admitting failure — you're showing you can iterate. Luna: I think a lot of the anxiety comes from this idea that there's a 'right answer.' But in reality, interviewers are evaluating your thought process. Lucas: Exactly. And the best way to demonstrate that process is to use a framework like Dan's. Clarify, model, estimate, dive. If you follow that structure, even if you miss some details, the interviewer can follow your reasoning. And that's what gets you the hire. Luna: So for anyone listening who's prepping — what's the one concrete takeaway for today? Lucas: Pick one system you use every day, say Twitter or YouTube, and spend twenty minutes walking through the four steps out loud. Don't look at any reference. Just do it. You'll learn more from that twenty minutes than from three hours of passive reading. Luna: I'm going to try that myself. I've always dreaded the design round. Lucas: And that's the thing — the people who ace it aren't geniuses. They just have a process.