Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Practice System Design Drills
Transcript
- Lucas: If you've been following along with our FAANG prep episodes, you know the coding rounds get most of the attention. But there's another part of the loop that actually filters out more senior candidates: the system design round. Luna: And that's the one where a lot of people freeze. You're not solving a well-defined problem with test cases—you're designing something from scratch under time pressure. Lucas: Exactly. So today I want to talk about how engineers at places like Google and Meta actually drill for that round. Not just reading books or watching lectures, but doing structured, repeatable practice that builds fluency. Luna: Give me the weekly rhythm. What does a disciplined prep schedule look like? Lucas: The engineers I've coached who did best set aside two to three sessions per week, each about ninety minutes. One session is a solo whiteboard warm-up where they sketch a design for a known problem like 'design a URL shortener' or 'design a chat system'—but they time themselves. Forty-five minutes to get a diagram and a rough API, then fifteen minutes to write down what they'd improve. Luna: So the timer is key. It simulates the real pressure. Lucas: Right. The second session in the week is a mock interview with a peer. They swap roles—one person plays the candidate, the other plays the interviewer asking clarifying questions and pushing on trade-offs. The third session, if they can fit it, is a review: they take a past design doc from their own work and explain the architecture out loud as if to a new teammate. Luna: I like that last one. It ties preparation to real experience instead of abstract problems. Lucas: Exactly. And here's a number that stuck with me: an engineering director at one of the big cloud providers told me that internally, they tracked candidates who did at least three full mock system design interviews before their onsite. Those candidates passed the round at a rate roughly forty percent higher than the baseline. Luna: Forty percent is huge. But I wonder—how do people find good mock partners? Not everyone has a friend who's also prepping. Lucas: There are online communities—some on Discord, some on Blind—where engineers pair up. The trick is to find someone who's at least as experienced as you, ideally someone who's already passed a system design round. Even one session with a senior engineer can expose blind spots you'd never catch solo. Luna: What about junior engineers? If you're two or three years in, you might not have deep distributed systems experience. Can you still practice effectively? Lucas: Absolutely. In fact, I'd argue it's even more valuable for juniors because it forces you to learn concepts you don't use day-to-day. Start with the basics: load balancers, caching layers, database replication. You don't need to design a global payment system on day one. Pick a simple problem, draw it out, and then read one blog post about how a real company solved the same problem. Luna: So the drill isn't about coming up with the perfect design. It's about building the vocabulary and the thinking pattern. Lucas: Exactly. And that thinking pattern is what interviewers evaluate. They want to see you ask clarifying questions, identify constraints, and make reasonable trade-off decisions. One engineer I worked with used a very simple framework: first understand the requirements, then estimate the scale, then define the data model, then sketch the system components. Every single drill, same sequence, until it became automatic. Luna: That reminds me of how athletes drill fundamentals. You run the same play until you don't have to think about it. Lucas: That's exactly the analogy I use. And there's one more thing that strong candidates do that weaker ones skip: they write a one-page design document after each drill. Not a novel—just a summary of their decisions, what they'd change, and what they couldn't figure out in time. Over a few weeks, they build a little library of their own thinking. Luna: And that becomes material for the review session we talked about earlier. You can look back and see how your approach matured. Lucas: Right. And frankly, it also helps with confidence. When you sit down in the actual interview and the interviewer says 'design a news feed,' you've already drawn that diagram three times in the last month. It doesn't feel new. Luna: So if someone listening wants to start today, what's one concrete action they can take tonight? Lucas: Set a timer for forty-five minutes. Open a blank document or grab a whiteboard. The problem: 'design a URL shortener.' Don't look anything up. Just start writing down your assumptions and drawing boxes. When the timer goes off, take five minutes to note what was hardest. Then tomorrow, find a partner and do the same problem as a mock. Luna: That's actionable. I like that it doesn't require any special tools. Lucas: Nope. Just time and willingness to be uncomfortable. And that discomfort is exactly what the drill is meant to reduce. Luna: You know, talking about practice sessions and building a routine… it makes me think about how this show itself stays consistent. We put out episodes every day, and it's only possible because a small group of listeners chips in monthly. Lucas: Yeah, it's a good parallel. The show is ad-free, listener-supported, and a handful of people who find value in it contribute at buy me a coffee dot com slash fexingo. That support is what keeps us drilling into topics like this. Luna: Right. And it lets us stay independent, focused on practical advice without any sponsor pressure. Lucas: Exactly. So back to the preparation strategy—the key takeaway is that system design is a skill you can build deliberately. It's not magic and it's not just innate talent. The candidates who pass are the ones who put in the structured reps. Luna: And who treat the drill like a rehearsal, not a test. Lucas: Exactly. So set that timer tonight. We'll be back next episode with another deep dive.