Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Use System Design Interview Frameworks
Transcript
- Lucas: So, you're in a FAANG system design interview and the prompt is just... 'Design YouTube.' Where do you even start? Luna: That blank page moment is terrifying. I've seen candidates freeze for a full minute. Lucas: Right. And the worst thing you can do is dive straight into drawing boxes and arrows. What the interviewers actually want is a structured framework. Luna: There's a four-step method that a lot of senior engineers at Google and Meta teach. Can we break it down? Lucas: Absolutely. Step one: clarify requirements. You have to narrow the scope. 'Design YouTube' is impossible in 45 minutes. So you ask — are we focusing on video upload, streaming, or both? What's the monthly active user target? Luna: That's where most candidates slip. They assume they know what's being asked. Lucas: Exactly. One engineer I know used a concrete example: he said 'for this exercise, let's design a URL shortener like TinyURL.' And he walked through the steps. Luna: Let's use that as our running example. Step two is estimation — you need to size the system. Lucas: Yeah. For TinyURL, you'd estimate: how many new URLs per day? Let's say 100 million. Then writes per second — that's about 1,160. Reads? Probably 100 times that, so 116,000 reads per second. And storage: if each entry is 500 bytes, that's 50 gigabytes per day, about 18 terabytes per year. Luna: Those numbers are concrete enough to impress, but they also drive the design. If writes are low, you don't need a super complex write path. Lucas: Step three: data model and API design. For TinyURL, you need a simple relational table — short_key, long_url, created_at, user_id. Or you could use a key-value store. The API is straightforward: POST to create, GET to redirect. Luna: But here's where the framework gets interesting. You have to justify your choices. Why a relational DB versus NoSQL? Lucas: Right. And that leads to step four: the deep dive. Once you have the skeleton, interviewers pick one component and ask you to go deeper. For TinyURL, they'll ask about the key generation algorithm — how do you generate a unique six-character string? Luna: That's the part that separates senior from junior. You can talk about base-62 encoding, or using a distributed ID generator like Snowflake. Lucas: And you should also discuss collision handling. Base-62 with a counter avoids collisions if you use a single database, but that's a single point of failure. So you'd move to a range-based approach — each server gets a block of IDs. Luna: One thing I've noticed: candidates often skip the trade-off discussion. For example, using a hash like MD5 truncated to six characters — that has collisions, so you need a retry mechanism. Lucas: That's exactly the kind of depth interviewers want. They want to see you weigh options. Do you prefer simplicity with a single writer, or complexity with higher availability? Luna: Let me bring in a counterexample. I once had an interview where the prompt was 'design a chat system.' I started with requirements, estimation, data model — but the interviewer kept asking, 'what about latency?' and I hadn't planned for that in my framework. Lucas: So the framework isn't rigid. You have to adapt. For a chat system, latency is critical, so you'd spend more time on the deep dive around WebSockets and message ordering. Luna: Exactly. The framework gives you a starting point, but the real skill is knowing where to flex. I've seen senior engineers skip estimation altogether if the system is well-known, because the numbers are common knowledge. Lucas: On the other hand, estimation can be a signal. If you can quickly calculate that YouTube needs to store 500 hours of video per minute, you've already shown you understand scale. Luna: Right. So the framework is more of a mental checklist. Requirements, estimation, data model, deep dive. You don't have to follow it linearly; you can loop back. Lucas: And one more thing — always leave time for the deep dive. If you spend 30 minutes on the first three steps, you won't have time to show your depth. So budget your 45 minutes wisely. Luna: Speaking of time, I'm realizing we spend a lot of unpaid hours preparing these episodes. And actually, a handful of listeners help keep the show ad-free through buy me a coffee dot com slash fexingo. Lucas: Yeah, it's a small group, but it's what lets us dive into topics like this without worrying about sponsors. Really appreciate those folks. Luna: Totally. Okay, back to frameworks — do you have a favorite mnemonic for remembering the steps? Lucas: I use 'RED' — Requirements, Estimation, Deep dive. But that skips the data model. So maybe 'REND' — Requirements, Estimation, data model, Deep dive. Luna: That works. I'll try to remember that. Let's practice with another example quickly — design a news feed. Lucas: Okay, step one: requirements. Is this a pull-based feed like Twitter, or algorithmic like TikTok? Let's assume Facebook-style — friends' posts in reverse chronological order. Luna: Step two: estimation. For 1 billion active users, each with 200 friends on average, you're looking at a fan-out of 200 writes per post. But reads are even higher. Lucas: Good. Step three: data model. You need a post table, a user table, and a feed table. But the key design decision is push versus pull — do you pre-compute feeds or generate them on read? Luna: And that leads to the deep dive: the fan-out service. You'd discuss using a message queue, handling hot users with millions of followers, and caching strategies. Lucas: Precisely. And that's the value of having a framework. It keeps you from forgetting something like estimation, which directly influences whether you choose push or pull. Luna: One last tip: practice out loud. I've coached people who could write great designs but froze when they had to explain them verbally. Lucas: Absolutely. The framework is as much about communication as it is about engineering. If you can walk an interviewer through your thought process step by step, you're already ahead of most candidates. Luna: Alright, that's a solid takeaway. Next episode, maybe we can talk about how to handle the follow-up questions when the interviewer throws a curveball. Lucas: I like that. And in the meantime, if you're preparing for a system design round, try the REND framework on a few different prompts. It'll become second nature.