Latest / The Career Change Podcast with Fexingo: Switching Fields, Bootcamps, and Reskilling / How Bootcamp Grads Can Build a Portfolio That Hires Want to See
Transcript
- Lucas: You've built a dozen projects in bootcamp — a weather app, a to-do list, a clone of some popular site. Your GitHub is green with commits. But when you send that link to a hiring manager, you get crickets. What gives? Luna: I think we've all been there. The instinct is to show everything you can do. But that's not what hiring managers actually want. Lucas: Exactly. So let's talk about the one project that matters. I'm Lucas. Luna: And I'm Luna. Welcome back to The Career Change Podcast. Today, we're going to argue that more projects is not the answer. Depth over breadth. Lucas: I want to start with a story. A few months ago, I talked to a bootcamp grad named Priya. She had six projects on her GitHub — a weather app, a blog engine, a chat app, a task manager, an e-commerce site, and a clone of Trello. Luna: That sounds like a textbook bootcamp portfolio. Did she get interviews? Lucas: Not really. She was getting generic rejections. So we talked, and I asked her: 'Which of these projects actually solved a real problem for someone other than you?' She paused, and said, 'None.' Luna: That's the crux. Hiring managers see a lot of tutorial projects. They want to see that you can identify a problem, plan a solution, and iterate based on feedback. Lucas: Right. So Priya changed tack. She reached out to a local food bank that needed a way to schedule volunteer shifts. It wasn't a flashy project — no machine learning, no microservices. But it was real. Luna: And she had to deal with real constraints. The food bank ran on old computers. They needed something simple, accessible, and reliable. Lucas: Exactly. She built a single-page app with plain JavaScript and a simple back end. She wrote tests, documented her decisions, and shipped it. Then she wrote a thorough README that walked through the problem, her approach, the challenges, and the outcome. Luna: That README is key. It's not just a description of the app. It's a case study that shows how you think. Lucas: Let's break down what that README should include. First, the problem statement — in plain language. 'The food bank had 50 volunteers and a paper schedule. Shifts overlapped, no-shows were common, and the coordinator spent hours on the phone.' Luna: That immediately tells the reader you understand business context, not just code. Lucas: Second, your approach. 'I interviewed three coordinators to understand their workflow. I built a prototype in a weekend, then tested it with five volunteers for two weeks.' That's research, prototyping, and user testing — all in one sentence. Luna: Third, the technical choices and trade-offs. 'I chose a simple stack because the site needed to work on old browsers. I used local storage instead of a database because the coordinators didn't have a server. I wrote integration tests because the scheduler logic was the most critical path.' Lucas: That shows maturity. You're not just using tools because they're cool. You're making deliberate trade-offs. And fourth, the outcome. 'The coordinator reduced scheduling time from 8 hours to 30 minutes per week. Volunteer no-shows dropped by 40% within a month.' Luna: Numbers. Always include numbers if you can. It makes the impact concrete. Lucas: Priya got three interviews from that one project. She accepted an offer at a mid-sized SaaS company. The hiring manager told her: 'Your portfolio showed me you can take a vague problem and ship something useful. That's what we need.' Luna: So the question for our listeners is: what real problem can you solve this weekend? It doesn't have to be a nonprofit. It could be a tool for a friend's small business, a script that automates something tedious in your current job, or even a better way to organize your own job search. Lucas: Let's get specific. Say you're in retail and you're tired of manually reconciling inventory. Build a simple app that scans barcodes with your phone and updates a Google Sheet. That's a real problem, and you can document the whole process. Luna: Or if you're in a customer service role, build a dashboard that shows common complaint categories. Pull data from a mock API. Show that you can design for a user who needs quick insights. Lucas: The scale doesn't matter. What matters is that you can articulate the problem, the decisions, and the result. That's what demonstrates the skills that actually matter on the job: communication, empathy, and judgment. Luna: And let's be honest, building a real project is also way more motivating than following another tutorial. Lucas: A hundred percent. Which reminds me — if today's advice was useful to you, and you'd like to see more episodes like this stay free and ad-free, listener support is what makes that possible. You can find us at buy me a coffee dot com slash fexingo. No pressure, just a way to keep the show going for people who are making career moves. Luna: Yeah, it really helps. And we appreciate everyone who has supported so far. Now, back to portfolios — one more thing I want to add. Lucas: Go for it. Luna: Your GitHub profile README is prime real estate. Use it to summarize your best project in a couple of lines, link to the full case study, and include a screenshot or two. It's the first thing many recruiters see. Lucas: Great point. And don't forget to pin your strongest project to the top of your profile. Make it impossible to miss. Luna: So to recap: pick one real problem, build a solution, document your thinking, and show the impact. One project done well beats a dozen clones every time. Lucas: Next week, we'll talk about how to talk about that project in an interview without sounding like you're reading a script. Until then, find a problem and start building.