Latest / The Career Change Podcast with Fexingo: Switching Fields, Bootcamps, and Reskilling / How Bootcamp Grads Can Ace the System Design Interview
Transcript
- Lucas: So you've built a solid portfolio, you've nailed the behavioral rounds, you've even passed a couple of LeetCode-style coding assessments. But then you get an email that says, 'Next round: system design interview.' And if you're a bootcamp grad — let's be honest — that can feel like someone just asked you to build a skyscraper with toy blocks. Luna: It's the interview that scares people the most, especially when you don't have a computer science degree. I've heard it called 'the weed-out round for non cs folks.' Lucas: Right. And there's a reason for that reputation. Traditional system design questions were built for engineers who'd spent years designing large-scale distributed systems at companies like Google or Amazon. But here's the thing — that reputation is actually outdated. In 2026, most top tech companies have redesigned their system design interviews to test structured thinking, not obscure distributed systems trivia. Luna: And bootcamp grads actually have an edge there — if they approach it the right way. Because a lot of what makes a good system design interview is clear communication and making reasonable assumptions, not memorizing CAP theorem. Lucas: Exactly. So let's make this concrete. We're going to walk through one classic system design problem — designing a URL shortener, like TinyURL or bit.ly — and we'll do it the way a bootcamp grad should approach it. Four steps: clarify requirements, define the data model, estimate traffic, and sketch the data flow. Luna: Step one — clarify requirements. This is where most people fail because they jump straight to 'we need a database and a web server.' Instead, you ask: what are the core features? Shorten a URL, redirect a URL, maybe analytics? Lucas: Yeah, and you want to set scope. For a 45-minute interview, don't try to design a global distributed system with 99.999% uptime. Say: 'I'll focus on the core shortening and redirect flow. I'll assume we don't need user authentication or analytics for now.' That shows you can prioritize. Luna: Then step two — define the data model. This is where bootcamp grads shine because you've built CRUD apps. You know what a table looks like. For a URL shortener, you need a mapping from a short string — the 'slug' — to the original long URL. Plus maybe a created-at timestamp. Lucas: And you can propose something simple: a SQL table with columns — id, short_key, long_url, created_at. Primary key on id, unique index on short_key. The interviewer might ask about NoSQL, and you can say, 'For this read-heavy workload, I'd consider a key-value store like Redis for caching, but the primary store could be a relational database for consistency.' That shows you understand trade-offs without over-engineering. Luna: Step three — traffic estimates. You don't need to be exact. You just need a ballpark. Say: 'Assume we get 10 million new URLs per month and 100 million redirects per month. That's about 4 writes per second and 40 reads per second.' That's trivially small for a modern database. Lucas: But the interviewer might push back — 'What if we grow to 1 billion URLs?' Then you talk about horizontal scaling. But the key is you start small and grow. Too many candidates immediately design for Facebook scale and end up with a solution that's too complex to explain in 45 minutes. Luna: So step four — data flow. How does a redirect actually work? User clicks a short URL, the request hits a web server, server looks up the short key in a cache, if not found then queries the database, and returns a 301 redirect to the long URL. Simple. Lucas: And then you add details incrementally. 'I'd put a load balancer in front of multiple web servers. I'd add a caching layer — maybe Redis — to avoid hitting the database on every request. For the short key generation, I could use a base-62 encoding of an auto-increment ID, or I could use a hash function like MD5 and take the first 7 characters.' Each of those choices has trade-offs, and the interviewer wants to hear you talk about them. Luna: That's the real skill — articulating trade-offs. For example, using an auto-increment ID is simple and collision-free, but it reveals how many URLs you've created. A hash function is less predictable but has collision risk. There's no single right answer. Lucas: Exactly. And bootcamp grads often have an advantage here because you've built real apps with real constraints. You know what it's like to debug a slow query. You know that caching can cause stale data. You've seen trade-offs in practice, not just in theory. Luna: But what about the fear that you don't know enough about distributed systems? Like, what if they ask about consistent hashing or leader election? Lucas: Honestly, for most system design interviews at the mid-level, you don't need to know those. The interviewer primarily wants to see that you can break down a problem, ask questions, and make reasonable choices. If you can design a simple URL shortener with a cache and a load balancer, and explain why you made those choices, you're already ahead of maybe half the candidates. Luna: There's also a specific resource that's become the gold standard for bootcamp grads — the System Design Primer on GitHub. It's an open-source repository that breaks down exactly this kind of thinking. We'll put the link in the show notes. Lucas: It's a great starting point. But I'd add one thing: practice out loud. The biggest mistake I see is people reading through design documents silently, then freezing in the interview because they're not used to talking through their thought process. Find a friend, or even a rubber duck, and explain your design step by step. Luna: And if you don't have a friend who's into system design, there are mock interview platforms. Some are paid, but some are free. The key is getting comfortable with the format — the back and forth, the clarifying questions, the 'what if' scenarios. Lucas: Yeah, and that's actually a good moment to mention something. If you've gotten value from this show — if it's helped you think through a career move or a specific interview prep — we keep the podcast ad-free and accessible because of listener support. A couple of dollars a month at buy me a coffee dot com slash fexingo genuinely makes a difference. It's what allows us to do deep dives like this without sponsors. Luna: And we really mean that — even small contributions add up. It keeps the show independent and focused on what helps you, not on selling products. Lucas: Alright, back to system design. Let's talk about another classic problem — designing a chat system. This one comes up a lot. The key difference from a URL shortener is that you need real-time communication, which introduces challenges like maintaining persistent connections and handling message ordering. Luna: So where would you start with that? Same framework? Lucas: Same framework. Clarify requirements: one-on-one chat or group chat? Do we need message history? Do we need typing indicators? Then data model: you need a messages table with sender_id, receiver_id, timestamp, content. Then traffic estimates: assume 100 million daily active users, each sending 20 messages per day. That's 2 billion messages per day, about 23,000 writes per second. That changes the design significantly. Luna: And at that scale, you can't use a simple relational database for writes. You'd need something like a message queue and a distributed database. So now you're talking about Kafka, Cassandra, maybe Redis for real-time delivery. Lucas: Right. But again, you start simple. 'For MVP, I'd use a single database with indexes. As we grow, I'd partition by user ID and introduce a message queue for asynchronous processing.' The interviewer wants to see that you can scale incrementally, not that you know every detail of Cassandra's architecture. Luna: And that incremental mindset is something bootcamp projects naturally teach. You build a to-do app with a local database, then add a backend, then add caching. You've literally done scaling, even if it wasn't at Twitter levels. Lucas: Exactly. So the takeaway for anyone listening: don't let the term 'system design' scare you. It's not a test of obscure knowledge. It's a structured conversation about trade-offs. You have the skills to do that — you just need to practice the format. Start with the System Design Primer, do mock interviews, and remember to think out loud. Luna: And if you have a specific system design topic you'd like us to cover in a future episode — like designing YouTube or Uber — let us know on social media. We read those. Lucas: Absolutely. For now, good luck with the prep. You've got this.