Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Think in First Principles
Transcript
- Lucas: You know, I was prepping for a system design interview last week — not for myself, just to refresh how I teach it — and I kept noticing something. Almost every candidate jumps straight to a known architecture. They say 'let's use a load balancer, some microservices, a cache layer.' It's like they're assembling Lego according to the box art. Luna: Right — they're pattern-matching, not designing. Lucas: Exactly. And that's fine for a junior interview. But at the senior level, the thing that separates good from great is something called first-principles thinking. It's a term Elon Musk made famous, but FAANG senior engineers use it every day, especially when the usual patterns don't fit. Luna: Musk's version is 'boil it down to the fundamental truths and reason up from there.' But what does that actually look like in a code review or an architecture decision? Lucas: Let me give you a concrete example. A few years ago, a team at Google was working on a routing algorithm for Google Maps — the part that figures out the fastest path from point A to point B. The standard approach was to use a variant of Dijkstra's algorithm with some heuristics. It worked fine, but it was getting slow as the map data grew. Luna: So they just threw more servers at it? Lucas: That's the analogy-driven move. But instead, one engineer asked: 'What is the fundamental constraint here?' The answer wasn't CPU or memory — it was that the graph had too many nodes to explore. So they decomposed the problem: 'What do we actually need to know to determine the fastest route?' The fundamental truth is that you only need to consider nodes that are geometrically plausible — not every intersection in the entire city. Luna: So they used a spatial index or something like that? Lucas: More radical. They redesigned the graph itself. They created a hierarchy of roads — highways first, then arterials, then local streets — and only expanded into lower levels when necessary. That's a first-principles move: instead of optimizing the algorithm, they changed the data structure to reflect the physical truth that most trips use major roads. Luna: And it saved how much compute? Lucas: I've heard the internal talk that describes a 15 percent reduction in overall compute cost for that service. Which, at Google scale, is millions of dollars. But the real win was that the routing became faster without adding more hardware. Luna: Fifteen percent is huge. But I want to push back a little — first-principles thinking sounds great in theory, but in practice, most engineers don't have the time or the safety to question everything from scratch. How do you actually do this in a two-week sprint? Lucas: Fair. And I think the key is to use first principles selectively. You don't apply it to every ticket. You apply it when you're stuck, or when a pattern isn't working, or when the cost of getting it wrong is high. The way to start is to ask 'why' three times. Why do we use a message queue here? Because we need async processing. Why async? Because the downstream is slow. Why is it slow? Because it's doing a full table scan. Now you're at a first principle: the real issue is the query, not the architecture. Luna: I like that. A former Amazon engineer once told me that in his team, they had a rule: before proposing any solution, write down the problem in one sentence without using any technology words. No 'microservice', no 'database', no 'API'. Just the core need. Lucas: That's brilliant. Because if you say 'we need a real-time dashboard', you're already thinking in solutions. But if you say 'we need to know, within five seconds, how many users are on the site', now you're thinking in first principles. Then you can ask: what are the atomic facts? There are users, they generate events, we need to count those events quickly. That might lead you to a streaming system, but it might also lead you to a simple counter in Redis. Luna: And that counter might be all you need for weeks, not a full Kafka pipeline. That's the pragmatic win. Lucas: Right. And there's a deeper point here: first-principles thinking is also a career lever. Senior engineers are expected to challenge requirements, not just implement them. When you go into a design review and say 'I think the fundamental assumption here is wrong', that gets attention. But you have to back it up with reasoning from first principles. Luna: So how do you practice it? It's not like you can flip a switch. Lucas: You can practice in small ways. Next time you're in a stand-up and someone says 'we need to add a cache', ask: 'What is the actual latency we're trying to fix? What's the source of the slowdown?' Most of the time, the answer reveals that caching isn't the right fix — it's a bad query or an N-plus-one problem. Luna: And that saves you the complexity of cache invalidation, which is famously one of the hard problems in computer science. Lucas: Exactly. Another practice is to do 'pre-mortems'. Before you start a project, imagine it failed six months from now. What went wrong? That forces you to identify the critical assumptions — the first principles — that could break. Luna: I've seen that work. A team I knew was building a new recommendation engine. They did a pre-mortem and realized they were assuming user behavior would stay the same post-launch. That assumption was false — users changed their behavior because the recommendations changed. So they built in a feedback loop from day one. Lucas: That's a perfect example. The first principle was: 'Recommendations influence behavior, so we need to measure the delta.' Not 'build a model and ship it.' Luna: So what's the biggest mistake engineers make when trying to use first principles? Lucas: They go too deep too fast. They try to reason from physics or math when the problem is at the system level. You don't need to question the speed of light to design a payment system. You need to question the business rules: 'Is this transaction really irreversible? Must it be synchronous?' Those are the first principles for that domain. Luna: Domain-specific first principles. I like that. It's not about being a philosopher — it's about being a clear thinker. Lucas: Exactly. And the best engineers I've worked with have that ability to zoom out, find the atomic constraints, and then zoom back in with a solution that fits. It's a superpower. Luna: Speaking of superpowers, if today's conversation gave you something usable, a handful of listeners help keep this show ad-free. You can find us at buy me a coffee dot com slash fexingo. Just a small way to support the work if it's helped you. Lucas: Yeah, it's entirely listener-funded, no ads, no sponsors. And every contribution, no matter how small, helps us keep making episodes like this one. We really appreciate it. Luna: Absolutely. So, back to first principles — what's one actionable takeaway for someone listening right now? Lucas: Pick one problem you're facing today — maybe a slow endpoint or a confusing requirement. Write down the problem in one sentence without any tech jargon. Then list the three fundamental truths about that problem. Then ask: 'Given those truths, what's the simplest possible solution?' Chances are, it's different from what you first assumed. Luna: And if it's the same, at least you know you've reasoned through it. That confidence shows in interviews too. Lucas: Absolutely. First-principles thinking is a habit, not a talent. The more you practice, the more natural it becomes. And it's one of those skills that pays dividends across your entire career. Luna: Thanks for listening, Lucas. And thanks to everyone who supports the show. Lucas: See you next time.