Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Read Code Faster
Transcript
- Lucas: Luna, when you were starting out as a developer, what percentage of your day do you think you spent actually reading code — versus writing it? Luna: Oh, I'd guess maybe 30 percent reading, 70 percent writing — at least that's how it felt. Lucas: Right, and that's the common intuition. But a study of engineers at Google found the exact opposite: top engineers spend about 70 percent of their time reading code and only 30 percent writing it. Luna: Wow, that's a complete flip. And it makes sense — you can't write good code if you don't understand the system you're working in. Lucas: Exactly. And you know, this is a skill that's rarely taught. We learn to write code in school, but we never really learn how to read it efficiently. So today I want to talk about how to get better at reading code — especially in large codebases like the ones at FAANG. Luna: Before we dive deeper — and this is totally related — a couple of dollars a month from listeners is genuinely what keeps these episodes ad-free and focused on practical skills like this. If you've gotten something useful out of the show, you can support it at buy me a coffee dot com slash fexingo. Lucas: Yeah, it really makes a difference. We keep the show focused on what actually helps engineers, and listener support is why we don't have to run ads. Luna: So back to reading code — what's the first thing you do when you open a new codebase? Lucas: I start by reading the README and the design documents. Most engineers skip this because they want to dive right into the code. But without context, you're just guessing what the code is supposed to do. Luna: I've definitely been guilty of that. Jumping straight into a file and trying to trace through the logic. Lucas: And it's slow. A better approach is to start at the entry point — like the main function or the controller — and then follow the execution path top-down. You trace the flow of a single feature, ignoring everything else. Luna: So you're reading like a debugger, almost. Stepping through the program mentally. Lucas: Exactly. And you take notes. I use a text file where I map out the sequence of calls. After you've traced one path, you have a skeleton of the system. Luna: What about when you need to understand a specific function? Like a utility that's used everywhere. Lucas: That's where grep comes in. I search for where the function is defined — not just called. Then I look at its inputs and outputs before I read the body. A lot of times you can understand what it does just from the name and the types. Luna: Types really help. In a strongly typed language, the type signature tells you half the story. Lucas: Right. And then for the body, I read the tests first. Tests tell you what the function is supposed to do in edge cases. That's often clearer than the implementation itself. Luna: I've heard that some senior engineers at Amazon say they spend the first week of a new project just reading code — not writing a single line. Lucas: That's a great practice. Onboarding to a large codebase, it's tempting to try to contribute immediately. But taking the time to read deeply pays off. You avoid writing code that doesn't fit the architecture. Luna: What about reading code in a pull request? That's a different context — you're reviewing, not learning. Lucas: For code review, I focus on the diff first. But I also open the broader file to see context. Sometimes a change looks weird because you don't see the function it's modifying. Luna: And you read the description and the linked issue before looking at the code, right? Lucas: Absolutely. The description tells you the intent. If the code doesn't match the intent, that's the biggest red flag. Luna: One thing I struggle with is reading legacy code. It's dense, no tests, weird variable names. Lucas: Legacy code is its own beast. I approach it by looking at the version control history. I use git blame to see who wrote each line and when. That helps me understand why something exists. Luna: And you can see if it was a quick fix or a deliberate design choice. Lucas: Exactly. Also, I look for comments or commit messages. Sometimes they explain the reasoning. If there's no comment, I assume it's a hack. Luna: Another technique I've seen is to run the code with debug prints or a debugger to trace execution. That's more active reading. Lucas: That's a great point. Sometimes reading statically isn't enough. You need to see it in action. For complex logic, I'll add a temporary log statement and run a test. That tells me exactly which branches execute. Luna: So it's almost like you're treating the code as data to be explored, not text to be consumed. Lucas: Right. And there's a meta skill here: building a mental model of the codebase. The more you read, the more you build a map. And the map helps you navigate faster next time. Luna: I think a lot of engineers feel pressure to be fast — to produce code quickly. But reading code is an investment that makes you faster in the long run. Lucas: It's like the old saying: 'Slow is smooth, smooth is fast.' Taking the time to read thoroughly means you make fewer mistakes and write code that integrates better. Luna: And it's a skill you can practice. Every time you open a new file, you can deliberately apply one of these techniques. Lucas: One more thing: reading code from open-source projects is a great way to learn. You get to see how experienced engineers structure large systems. Pick a project you use and read the source. Luna: That's a good homework assignment for our listeners. So to wrap up, the key takeaways: start with design docs, trace execution paths, use grep and git blame, read tests first, and run the code if you're stuck. Lucas: And remember that reading code is a skill you can improve. It's not something you're born good at. Practice it deliberately. Luna: Great episode, Lucas. I'm definitely going to start reading code more intentionally. Lucas: Same here. Thanks, Luna.