Coffee Chat #17: Building Evidence of Your Work is the Key to Your Next Job

‍Q: Can you share a moment where a student’s project demonstrated meaningful growth and helped you understand how powerful these kind of experiences are?

A: During my first Build Project, we were working on a machine learning application for skin cancer detection using deep learning. One student was clearly struggling but never spoke up during class sessions. I could sense something was off, so I invited him to an office hour.

We started from square one – how to use Google Colab, basic Python libraries, and the fundamentals of how the models actually work. Turns out, he wasn’t comfortable asking what he thought were “basic questions” in front of everyone. Once we cleared those foundational doubts privately, he was more than up to speed in the next classes.

What really struck me was his final deliverable. The code quality and visualization analysis were professional-grade – reusable model classes, clean architecture… the whole package. This taught me something crucial: struggling doesn’t mean lacking potential. Sometimes students just need a safe space to ask the “obvious” questions.

The lesson here for students? Don’t let pride or fear stop you from asking. Every expert was once a beginner who asked a lot of questions. And for collaboration – if you see a teammate struggling, create that safe space for them. The best teams make it okay to not know something.

Q: We agree on how valuable it is for students nowadays to build a robust portfolio to showcase their work. From your experience leading Build Projects, how can they design solutions that demonstrate strong architectural thinking and make their work stand out to hiring managers?

A: I always start with this question: “What happens when this goes from 10 users to 10,000?” Most students write code that solves the immediate problem, which is fine for learning, but doesn’t prepare them for real-world systems.

I encourage students in my Build Project to think in layers – separate your data access from your business logic from your presentation. When you’re building even a small project, ask yourself: If I needed to swap out this database tomorrow, how much code would I need to rewrite? If the answer is “everything,” your architecture is too tightly coupled.

In my own work with multi-tenant systems, I’ve learned that good architecture isn’t about predicting the future perfectly – it’s about making changes easy when the future arrives. I share these real-world patterns with students: database schema isolation, proper use of ORMs, API design that can evolve without breaking existing clients.

The key is to build small projects with this mindset. Don’t try to build a massively scalable system right away. Build something simple, then deliberately break it by simulating growth. Add more users, more data, more features. See where it falls apart, then rebuild it better. That’s how you develop architectural thinking.

Q: Students often struggle when projects get complicated or don’t go as planned – especially in the software development field. What practical strategies help them deliver polished, high‑quality work even when they hit roadblocks? ‍

A: I typically teach them something I call “shrink the problem.” When something breaks and you don’t know why, don’t stare at the entire system. Isolate the smallest possible piece that reproduces the issue.

For example, if your API endpoint isn’t working, don’t debug the entire request flow at once. First, verify the route is registered. Then check if the handler is called. Then verify the database query works in isolation. Then check if the response is formatted correctly. Break it into tiny, testable chunks.

I also emphasize that debugging is detective work, not guesswork. Add logging, use a debugger, read error messages carefully – all the way to the end. I’ve seen students miss the solution because they only read the first line of an error that spans 20 lines. The answer is often in line 18.

For iteration, I share my own experience: I’ve abandoned projects because I scoped them too large. I once planned a fitness tracker with mobile apps, real-time updates, the whole package. Gave up after a few hours of scaffolding. The lesson? Start small, finish completely, then build the next small thing. Completed small projects teach you more than abandoned large ones.

When students hit a wall, I encourage them to explain the problem to someone else – even a rubber duck. Just articulating the issue out loud often reveals the solution. And if not, it makes it easier for teammates to help because you’ve clarified your thinking.

‍Q: As students begin showcasing their work, how should they use AI coding tools without compromising their ability to understand, explain, and stand behind their code?

A: This is the question on everyone’s mind right now. Here’s my take: AI coding tools are incredibly powerful, but they’re amplifiers – they amplify both your strengths and your gaps.

If you understand the fundamentals – data structures, algorithms, system design – AI tools help you move faster. They handle boilerplate, suggest patterns, catch syntax errors. You’re still the architect; the AI is just a faster keyboard.

But if you don’t understand the fundamentals, AI tools will write code you can’t debug, maintain, or explain in an interview. You’ll get something that “works” without understanding why, and when it breaks, you’re stuck.

My advice for students: Use AI tools, but follow this rule: Never accept code you don’t fully understand. If Copilot suggests something, read every line. Ask yourself: “Could I have written this?” If not, that’s your signal to learn that pattern first.

Use AI for learning, not just for completing assignments. Ask it to explain concepts, generate practice problems, review your code. But write the first draft yourself. Then use AI to refine it. That way, you’re learning by doing, not just by copying.

In interviews, some companies allow AI tools, some don’t. The ones that do are testing whether you can leverage AI effectively – that means knowing what to ask for, how to validate the results, and how to integrate it into your solution. That’s only possible if you have solid fundamentals.

‍Q: How can students combine formal education with self‑directed projects to build a strong, visible body of work?

A: I have both bachelor’s and master’s degrees, but honestly? Much of what I use daily I learned through self-directed research and building projects on my own time. Formal education gave me the foundational theory and structure, but the practical skills came from figuring out what I needed when I needed it.

Here’s the reality: Your degree teaches you data structures, algorithms, software engineering principles – the foundations that don’t change. But it can’t possibly teach you every framework, tool, or technology you’ll encounter in your career. Things move too fast.

The most valuable skill I developed wasn’t from any specific course – it was learning how to learn. When I needed to understand multi-tenant architectures or TypeORM patterns or how to optimize database queries, I researched, experimented, broke things, and rebuilt them. That habit of self-directed learning has been more valuable than any single class.

My advice: Use your formal education to build a rock-solid foundation in fundamentals. Really master data structures, algorithms, system design, and software engineering principles. Those are hard to learn on your own and they never go out of style.

But don’t wait for a class to teach you what you need. If you’re interested in backend development, start building APIs. If machine learning excites you, start experimenting with models. If you want to understand cloud infrastructure, spin up a server and break it. Supplement your coursework with real projects that solve real problems – even if those problems are just yours.

The students who thrive aren’t the ones who just complete assignments. They’re the ones who get curious about something in class and spend their weekend building a project around it. They’re the ones who see a tool mentioned in passing and go research it for themselves.

Think of your degree as the map and your self-directed learning as the journey. You need both. The map shows you the territory and the proven paths. But the actual journey – getting lost, finding your way, discovering shortcuts – that’s where the real learning happens.