Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Use Side Projects to Stand Out
Transcript
- Lucas: You hear this advice everywhere — 'build side projects, contribute to open source' — but what actually moves the needle when a FAANG recruiter looks at your GitHub? I think the answer has shifted in the last couple of years. Luna: Because everyone has a side project now, right? It's not a differentiator just to have one. Lucas: Exactly. When I started this show, maybe one in three applicants had a live project they could talk about. Now it's more like two out of three. So the bar isn't 'do you have a project' — it's 'does your project teach me something about how you think?' Luna: That's a higher bar. Give me a concrete example. Lucas: I was talking to a senior engineer at Amazon last week — let's call her Priya. She was on a hiring panel for a senior backend role. One candidate had a repo with a personal website, a to-do app tutorial, and a clone of a popular chat app. All looked clean, but nothing showed original thinking. Luna: Standard leetcode plus tutorials. I've seen that. Lucas: Right. Then another candidate had a single project — a small open-source library for parsing configuration files. It had maybe 2,000 stars on GitHub. The code was readable, he had thorough documentation, and he'd written a short blog post explaining a design trade-off he made. That project got him the interview. Luna: What was the trade-off he wrote about? Lucas: He chose a recursive descent parser over a generated one because he wanted the library to have zero dependencies. That's a systems-thinking decision. It showed he understood maintainability and user experience, not just syntax. And the blog post made it easy for the interviewer to evaluate his communication skills before the call. Luna: So the project itself matters less than the signals it sends. What signals are hiring managers actually looking for? Lucas: I've heard recruiters talk about three signals. First: depth — did you solve a real problem, not just follow a tutorial? Second: craftsmanship — is the code well-structured, tested, documented? Third: learning posture — can you articulate why you made certain choices, especially trade-offs? Luna: That third one is the one most people miss. You can have a great repo but if you can't talk about it, the signal dies. Lucas: Absolutely. And I'd add a fourth that's becoming more important in 2026: evidence of collaboration. Even a solo project can show this if you have a CONTRIBUTING.md file, or if you've accepted pull requests from strangers, or if you've engaged in issues. Luna: Because FAANG teams are highly collaborative. They want to see that you can communicate about code. Lucas: Yeah. So the question becomes: if you're a mid-career engineer without a standout project, what do you do? Do you build something from scratch, or can you rescue an existing project you already have? Luna: I think most people underestimate the value of polishing an existing project. A lot of old repos are full of good ideas that just need documentation and testing. Lucas: That's exactly what Priya told me. She said the candidate who got the interview had actually forked an abandoned library, cleaned it up, added tests, and wrote a migration guide. That's more impressive than building something new because it shows you can work with legacy code — which is most of what senior engineers do. Luna: Right. And it's faster. You don't have to come up with a novel idea. Lucas: So let me give listeners a practical framework I call the 'three-week project rule.' If you start a side project today, give yourself exactly three weeks to reach a point where you can show it to another engineer. If you can't get it to that stage in three weeks, the scope is too big. Luna: I like that. Because the goal isn't to build a production system — it's to create a conversation piece. Lucas: Exactly. And the conversation is the real interview. If your project sparks a ten-minute discussion about trade-offs, testing strategy, or how you'd scale it, you've already won half the battle. Luna: What about people who are already employed and don't have time? A lot of our listeners are working full-time. Lucas: You don't need hours per day. Even thirty minutes a day for three weeks gets you to about ten hours total. That's enough to build a small utility, write a README, and add basic tests. The key is consistency, not intensity. Luna: And you can use that project even if you're not targeting FAANG. Every tech company evaluates engineers on similar signals. Lucas: Right. But I want to address one misconception: side projects aren't just for junior engineers. For senior roles, they can be even more powerful because they demonstrate breadth outside your day job. Priya told me the senior hire they made had a side project that was a monitoring dashboard for his home server. Nothing fancy, but it showed he cared about observability — which was directly relevant to the team's needs. Luna: So it's not about building something impressive — it's about building something that signals a specific strength. Lucas: Yes. And I think that's the core insight. Instead of asking 'What project should I build?' ask 'What signal do I want to send?' If you want to show you're strong at API design, build a thin wrapper around a public API. If you want to show testing discipline, write a project with 90% test coverage and a CI pipeline. Luna: That's a much more targeted approach than the typical 'build a chat app' advice. Lucas: And honestly, that advice is outdated. Every bootcamp graduate has built a chat app. It doesn't distinguish you. But a well-crafted tool for something niche — like a library for validating CSV files — that can stand out because it shows you identified a real pain point. Luna: I want to push back a little though. Isn't there a risk that hiring managers see a side project and think you're just doing interview prep, not genuine engineering? Lucas: That's a fair concern, and it comes down to authenticity. If the project looks like a tutorial clone, it will read as interview prep. But if you can point to real users — even if it's just twenty people on GitHub — that changes the narrative. Real users mean real requirements, real bugs, real feedback. Luna: So the bar is: someone, somewhere, has used it for something. Lucas: Right. Even if it's just your teammates. I once interviewed a candidate who built an internal CLI tool for his team at a non-tech company. That was his side project. He talked about how he gathered requirements from colleagues, handled edge cases, and iterated based on feedback. That story was more powerful than any open source contribution. Luna: Because it showed user empathy and collaboration. Which is exactly what FAANG wants. Lucas: So here's my concrete takeaway for this episode: if you're preparing for a FAANG interview in the next six months, pick one small project — something that can be built in three weeks — and make it excellent. Write the tests. Write the docs. Write a blog post about one trade-off you made. That one project will do more for your interview than ten half-finished ones. Luna: And if you already have a project, spend a weekend polishing it. A great README and a clean commit history can transform how that repo reads. Lucas: You know, it's funny — we're asking listeners to invest time in their careers, and I think that's exactly the kind of thing that keeps shows like this going. A couple of dollars a month is genuinely what keeps these episodes ad-free and independent. If you've found today's conversation useful, you can support us at buy me a coffee dot com slash fexingo. Luna: It's a small gesture that adds up. And it lets us keep digging into these specific, practical angles instead of chasing clickbait. Lucas: Exactly. And back to the project framework — I want to add one more signal that I think is underrated: your project's evolution. If you have a commit history that shows you refactored, added features, and fixed bugs over time, that tells a story of growth. Hiring managers love seeing that. Luna: So it's not just the final state. The trajectory matters. Lucas: Absolutely. I'd recommend keeping your project public and making regular commits, even if they're small. A repo that shows activity over six months is more compelling than one that was pushed in a weekend and never touched again. Luna: And if you're worried about privacy or IP, remember you can always build something unrelated to your day job. The key is to demonstrate the skills, not the domain. Lucas: Right. So to wrap up: side projects still work as a differentiation tool, but only if they're built with intention. Focus on depth over breadth, craftsmanship over features, and storytelling over code dump. If you do that, you'll give yourself a real edge. Luna: And if you want to go deeper, we'll link to that blog post Priya shared — it's a great example of how to write about a trade-off. We'll put it in the show notes. Lucas: Good idea. Next episode we'll talk about how to prepare for a FAANG engineering promotion — a topic that's surprisingly different from the interview process. See you then.