Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Build Side Projects That Actually Get Noticed
Transcript
- Lucas: So there's this engineer at Google — let's call him Alex — who spent his weekends building a command-line tool that automatically generates REST API documentation from TypeScript type definitions. Luna: Right, because writing docs is the part everyone hates, but no one wants to admit it. Lucas: Exactly. And Alex didn't build it for fame. He built it because his team kept shipping endpoints with no docs, and it drove him crazy. So he spent maybe three weekends over two months, put it on GitHub with a solid README, and basically forgot about it. Luna: But then someone at Uber found it, right? Lucas: Yeah. An engineering manager at Uber was looking for exactly that tool for their API platform team. They found Alex's project, loved it, and a few months later Alex was interviewing for a staff role at Uber — partly because of the side project. Luna: That's the dream scenario. But I think most engineers build side projects that nobody ever sees. What made Alex's different? Lucas: Great question. I've been looking at this for a while, and I think there are three key factors. First, he solved a real pain — not a hypothetical one. He was the user. Second, he shipped something minimal but functional. Third, and this is the one people miss, he invested heavily in the README and documentation. Luna: The README. I've seen projects with 10,000 stars and a terrible README, and they're basically unusable. Meanwhile, a 200-star project with a great README often gets more traction in hiring conversations. Lucas: There's actually data on this. A 2025 survey of 200 engineering managers — I got this from a friend who runs a tech career coaching platform — found that projects with even 50 real users are four times more likely to be mentioned in promotion packets or job interviews than projects with 500 stars but no clear usage. Luna: So it's about adoption, not vanity metrics. Lucas: Exactly. And adoption doesn't need to be huge. Fifty people using your tool — that's enough. That's a few teams inside a company, or a small open-source community. The key is that those fifty people have a problem, and your tool solves it. Luna: But doesn't that put pressure on engineers to build something 'useful' right away? What about learning projects? Lucas: Learning projects are fine for learning. But if you want a side project to help your career, it needs to be useful to someone other than you. That doesn't mean it has to be a full product. It could be a script that automates a tedious task for your team, or a library that solves a common pattern. Luna: So internal tools count too. You don't have to build in public. Lucas: Absolutely. In fact, some of the most impactful side projects I've seen are internal tools that engineers build for their own team and then open-source later. The key is that they're solving a real friction point. Luna: I want to push back on the 'build in public' trend a bit. I've seen engineers spend more time tweeting about their build process than actually building. It becomes a content play, not an engineering play. Lucas: That's a fair point. Building in public can be a great networking strategy, but it's not the only path. If you're spending more time on the 'public' part than the 'build' part, you're probably diluting the signal. Luna: What about the opposite: engineers who refuse to share anything because they're worried about code quality or someone stealing their idea? Lucas: That's a mistake. The odds of someone stealing your idea and executing it better than you are very low. And even if they do, you've still built something. The bigger risk is that nobody ever sees your work. Luna: So what's the practical checklist? If an engineer wants to start a side project today that could actually help their career, what should they do? Lucas: First, identify a pain you personally feel at work. Something that takes you 15 minutes a day that could be automated. That's your low-hanging fruit. Luna: Then build the smallest possible version. What's the 'three-commit rule' I've heard about? Lucas: The three-commit rule is a heuristic: your project should be shippable in three meaningful commits. First commit: the skeleton — a README, a license, a basic structure. Second commit: the core functionality — it does the one thing it's supposed to do, even if it's ugly. Third commit: polish — error handling, a test or two, better docs. Luna: That's really concrete. I like that. Most engineers over-engineer early and never ship. Lucas: Exactly. The goal is to ship something that works, even if it's not beautiful. Then iterate based on feedback. The people who use it will tell you what to improve. Luna: And the README — you mentioned that's critical. What makes a good README for a side project? Lucas: Show, don't tell. Include a GIF or video of the tool working. List clear installation steps. Have a 'why' section that explains the problem. And most importantly, include a 'contributing' section that invites others to help. That signals maturity. Luna: You know, this conversation is exactly the kind of thing that makes me glad we can do these episodes without any ads. Quick honest thing — we keep this show running because a handful of listeners chip in through buy me a coffee dot com slash fexingo. That's literally what funds producing this many episodes. Lucas: Yeah, and we love it. It means we can talk about whatever we think is actually useful, not what a sponsor wants us to talk about. If you've gotten something out of this episode, that's the place. Luna: So back to side projects. Lucas, you mentioned the README. What about the project name and branding? Does that matter? Lucas: It matters more than people think. A memorable, descriptive name helps. 'DocGen' is better than 'api documentation generator tool-v2'. But don't spend a week on naming. Spend 15 minutes. Luna: And what about choosing a license? I see so many projects with no license, which effectively means nobody can use them. Lucas: Huge mistake. If you want adoption, pick a permissive license — MIT or Apache 2.0. That removes legal friction. I'd say 80 percent of the side projects I see that could have been useful are dead because they have no license. Luna: Let's talk about timing. When should an engineer start a side project? Early in their career, or after they've established themselves? Lucas: Honestly, any time. But early career has a higher ROI because it builds your portfolio and your network. A junior engineer with a well-crafted side project can look like a mid-level to a hiring manager. Luna: But there's a risk of burnout. If you're already working 40 hours a week, adding a side project can be draining. Lucas: That's real. The trick is to set boundaries. Don't treat it as a second job. Treat it as a hobby that happens to have career benefits. If it stops being fun, take a break. The best side projects are ones you'd do anyway. Luna: So the bar is: does it spark joy? Lucas: Pretty much. The joy is what sustains you. And the joy usually comes from solving a problem you care about. Luna: One more thing: how do you actually get users? Posting on Hacker News feels like a lottery. Lucas: Don't rely on Hacker News. Instead, find the community that has the pain you're solving. If it's a tool for data engineers, post in the r/dataengineering subreddit or the Locally Optimistic Slack. If it's a front-end tool, share it in the React or Vue Discord servers. Targeted communities give you better feedback and more engaged users. Luna: And don't be afraid to share early. I've seen engineers wait until they have a 'perfect' v1, and by then they've lost motivation. Lucas: Right. Share a rough prototype. Ask for feedback. The first version of Alex's tool was literally just a Python script that printed Markdown. He shared it on a TypeScript Slack, got five comments, and that shaped the next version. Luna: So the takeaway is: find a real pain, build the smallest thing that solves it, write a great README, and share it in a targeted community. Lucas: That's exactly it. And remember: a side project doesn't have to change the world. It just has to change something for a few people. That's enough to change your career. Luna: Alright, next episode we're diving into how FAANG engineers approach technical writing — not just docs, but design docs and RFCs. That should be a good one. Lucas: Looking forward to it. See you next time.