Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Reverse Engineer Their Own Code
Transcript
- Lucas: So there's this moment in every senior engineer's career where they stop being judged on how much new code they write, and start being judged on how well they understand the code that already exists. Luna: And that shift — it's subtle, but it's the difference between a mid-level engineer and someone who's promo-ready. Lucas: Exactly. And the skill that makes that shift visible is something I don't think gets taught enough. It's reverse engineering your own work. Not security reverse engineering — just the ability to look at something you built six or twelve months ago, and explain why you made every decision you made, what you'd do differently, and what assumptions you got wrong. Luna: I've heard hiring managers call this the 'explain your own ghost' test. Can you talk about code you wrote that you haven't touched in months, as if it were someone else's? Lucas: That's a great name for it. And it comes up in a few places. One is system design interviews — the kind where they ask 'tell me about a time you designed a system that had to scale.' But the real test happens in promotion packets. At one of the big five — I'll just say it's a company known for its logistics — a senior engineer I know included a section in his promo packet titled 'Reverse Engineering a Legacy Module.' He'd built a pricing engine two years earlier. The team was considering a rewrite because nobody understood it. He volunteered to spend a week documenting it — not just the flow, but the trade-offs. He found three assumptions that no longer held. That one week of reverse engineering saved his team three months of rewrite. Luna: So the skill isn't just about answering interview questions. It's a career differentiator. And it's something you can practice now, before you even get the interview. Lucas: Right. Here's the exercise I'd recommend. Pick one piece of code you wrote that you're proud of — but that you haven't looked at in at least six months. Open it up. Before you read a single line, write down what you expect to find. What's the entry point? What data structures did you use? What was the most brittle assumption? Then read it. I guarantee you'll find at least one thing that surprises you. Luna: And that surprise — that's gold. That's the kind of insight that makes you look thoughtful in a code review or a promo packet. Lucas: Let's get specific. Suppose you wrote a service that processes user uploads and resizes images. Six months later, you open it up. You might realize you hardcoded a timeout value that's too short for the new file sizes your users are sending. Or you built a caching layer that's actually making things slower because you didn't account for cache invalidation patterns. That's the kind of thing that, if you document it, shows real engineering maturity. Luna: And if you're prepping for a FAANG interview, this is exactly the kind of story that stands out in a behavioral round. Not 'I built X,' but 'I revisited X, understood its weaknesses, and improved it.' Lucas: Exactly. Let me give you a framework. Three steps. Step one: Reconstruct the context. What was the business problem? What constraints did you have? Step two: Identify the key assumptions. What did you assume about traffic, data size, latency, failure modes? Step three: Audit those assumptions against reality today. Which ones held? Which ones didn't? That third step is where the insight lives. Luna: And you can do this with any project. It doesn't have to be a production system. A side project works just as well — maybe even better, because there's less ego involved. Lucas: Yeah, side projects are perfect for this. No one's going to judge you for finding flaws in your own side project code. And the practice of articulating those flaws clearly — that's a skill that transfers directly to the interview room. Luna: I want to push back a little though. Isn't there a risk of over-engineering this? Like, spending too much time documenting old code when you should be building new things? Lucas: It's a fair concern. The key is to treat it as a focused exercise, not a habit. Spend one or two hours on one piece of code. That's it. The goal isn't to document everything — it's to practice the muscle of stepping back and seeing your own work objectively. That muscle is what interviewers are testing when they ask 'tell me about a time you had to make a trade-off.' Luna: So let's say I do this exercise. I find three assumptions that were wrong. What do I do with that information? Lucas: First, you fix them if it's worth fixing. But even if you don't, you write a short postmortem — just for yourself. A few paragraphs. What did I assume? What actually happened? What would I do differently? Then you have a story for interviews that's real, specific, and demonstrates growth. That's way more compelling than a hypothetical answer about 'I would have tested more.' Luna: And if you're aiming for a promotion, that same postmortem can go into your promo packet as evidence of technical judgment. Lucas: Exactly. Look, I had a colleague at my last company who did this religiously. Every quarter, he'd pick one of his old projects and write a one-page retrospective. After two years, he had eight pages of concrete examples of how his thinking had evolved. His promo packet practically wrote itself. Luna: That's a powerful habit. And it's something anyone can start today, regardless of where they are in their career. Lucas: And if today's conversation gave you something usable — a specific exercise, a new way to think about your own code — that's exactly why we do this show. We keep it ad-free because we want the content to be the focus. If you find value in it and want to support us, you can buy us a coffee at buy me a coffee dot com slash fexingo. No pressure, just a way to keep these episodes coming. Luna: Yeah, it's a small gesture that goes a long way in keeping the show independent. And totally optional. Lucas: So back to the framework. The third step — auditing assumptions — that's where most people stop. But there's a fourth step that separates the really good engineers from the great ones. Luna: What's that? Lucas: You take the insight from your reverse engineering and you generalize it. You don't just fix your own code — you write a best practice guide for your team. You create a checklist. You say 'Hey, in this project, we assumed X. Going forward, let's add a test that catches when X stops being true.' That's the difference between fixing a bug and improving the system. Luna: So it's not just about personal growth — it's about raising the bar for everyone around you. Lucas: Exactly. And that's the kind of impact that gets noticed at FAANG. When you're up for senior staff, they want to see that you've improved the engineering culture, not just your own output. Luna: Let's talk about how this plays out in an interview setting. If I'm in a system design round and I mention that I reverse-engineered my own code, how do I frame it without sounding like I'm bragging? Lucas: You frame it as a learning story. 'I wrote this service, and when I came back to it six months later, I realized I'd made some assumptions that didn't hold. Here's what I learned.' That's humble, concrete, and shows self-awareness. Interviewers love that. Luna: And it's a lot more interesting than 'I designed a system that could handle a million requests per second.' Lucas: Exactly. Anyone can claim they built something scalable. But the ability to critique your own work — that's rare. And it's exactly what you need to do in a code review when someone questions your approach. If you've already thought about the weaknesses, you can respond calmly instead of getting defensive. Luna: So this skill is also a soft skill in disguise. It builds emotional resilience. Lucas: Completely. And it's a skill you can demonstrate even without being in an interview. Every time you open a pull request, you can include a note that says 'I revisited this module and found that assumption X no longer holds. Here's my proposed fix.' That kind of proactive communication is what gets you labeled as a senior engineer. Luna: I've seen engineers get promoted just by being the person who knows the system best — not because they wrote the most code, but because they could explain what the code does and why. Lucas: That's the reputation you want. And building that reputation starts with the habit of reverse engineering your own work. So here's a challenge for our listeners: before the end of this week, pick one piece of code you wrote at least six months ago. Spend 30 minutes on it. Write down what you find. Then ask yourself: if I were interviewing this engineer, would I be impressed? Luna: And if the answer is no, that's not failure — that's information. It tells you exactly what you need to work on. Lucas: Right. Because the goal isn't to have perfect code. The goal is to be an engineer who understands their own work well enough to improve it. And that's a skill that pays off in every interview, every promo cycle, and every code review. Luna: Well said. I'm going to try this myself this weekend. I have a side project I haven't touched in a year. Lucas: Let me know what you find. I bet there's at least one assumption in there that will surprise you.