Side Projects and Soft Skills in Interviews

Dev Leader Weekly 125

Jan 31, 2026

TL; DR:

Side projects help demonstrate learning
Soft skills are CRITICAL
Check out the live stream on Monday, February 2nd at 7:00 PM Pacific!

Beyond the Code

How often do you find yourself focusing purely on the technical details when you’re preparing for a software engineering interview? If you’re like most of us, you’re probably grinding LeetCode problems, sketching out system design diagrams, and making sure you can explain exactly how your favorite framework works under the hood.

I get it. I’ve been there. I’ve done that.

But as an engineering manager who has been hiring for over a decade, I’ve seen a recurring pattern: developers who can “nail” the technical rounds but still fail to land the offer. Usually, this happens because they miss the opportunity to showcase two critical areas: how they learn and grow, and the soft skills that make them a multiplier for a team.

Your Side Projects are a Narrative, Not Just a Repo

One of the biggest mistakes I see some developers make is assuming that the existence of a side project on a resume is the end of the story. If you got the interview, your project selection was decent enough to get you noticed, but the interview is where you actually have to sell the value of that experience.

To be clear: no, side projects are NOT a requisite for being qualified for a job. However, they can be an AWESOME way to showcase additional learning and experience that might not show up in your professional experience.

You can check out some of my thoughts on side projects in interviews in this video:

Focus on the “Stuck” and the “Unstuck”

When an interviewer asks about a project, don’t tell them it went perfectly smooth. If everything was easy, it’s honestly not that interesting to me as a hiring manager. I want to hear about where you got stuck and how you got unstuck.

This is your chance to demonstrate problem-solving focus and resourcefulness -- the core traits of an engineer. Explaining that you had to weigh multiple solutions before hitting your IDE or blasting prompts into ChatGPT shows me that you can think analytically and not just follow tutorials or vibe-code blindly.

The Value of “Reinventing the Wheel”

You’ve likely heard the advice “don’t reinvent the wheel,” but for side projects, reinventing the wheel is one of the best ways to understand complexity. If you built your own HTTP library or a custom game engine, talk about the appreciation you gained for the work that goes into big libraries. It shows you aren’t just a “copy-paste” developer; you’re someone who wants to know how the gears turn under the hood.

This isn’t necessarily the recommendation for building all software -- but it IS a cool opportunity to showcase that you wanted to dive into something and understand it. Curiosity is an awesome trait for an engineer.

Ask for the Interviewer’s Focus

Interviews can be vague, and system design or project walkthroughs are often left underdefined on purpose to see how you handle ambiguity. Before you dive into a 20-minute monologue about your database schema, stop and ask: “I have a lot to say about this project; is there anything in particular you’d like me to focus on?”.

Depending on the company, they might care about:

Design decisions: Why did you pick this specific tech stack over another?
Market research: If it was a product, how did you think about user needs?
Collaboration: Even on a side project, did you contribute to open source or work with a buddy? Highlighting teamwork is a massive value add because it’s a skill many juniors lack.

Leveraging Skills from Other Industries

If you are transferring from a different career path, you have an enormous leg up that many people overlook. You shouldn’t just be trying to compete on technical skills; you should be leaning into your lived work experience.

If you’ve dealt with customers, managed projects, or navigated difficult team dynamics in a past life, those are high-value indicators for a hiring manager. Especially for junior devs or folks trying to break into a dev role, while others are trying to prove they can write a function, you can prove you can deliver value to a business.

Why Soft Skills Trump Technical Depth

This might be a hot take, but in many cases, I value soft skills over technical depth.

If you have a candidate who is a technical “god” but is abrasive or impossible to work with, they can tank a team’s productivity from 100% down to nearly zero. As a manager, my goal is to create a multiplier effect where everyone makes those around them better. Multiplying anything by less than 1x means they’re taking away from overall team effectiveness. More on that in this Code Commute video:

The Friction of Coaching

Here’s the reality from the manager’s desk: It is much easier to coach a technical gap than a soft skill gap. If you don’t know a specific library, I can give you the time and resources to learn it. But if you lack self-awareness, struggle with active listening, or constantly blame others, that is significantly harder to fix.

In my career, I have observed that it’s absolutely possible to coach on people skills... But it’s significantly more time and effort. And that’s on BOTH sides -- the EM and the employee. Not to mention, while that coaching is happening, there could be a greater impact felt across the team.

Red Flags and Radical Accountability

During the interview, I am actively looking for red flags in how you talk about your past experiences.

Blaming others: If every failure in your past was someone else’s fault (a “dumb” teammate or a “bad” manager), that’s a signal you don’t take radical accountability.
Close-mindedness: If you insist there is only “one right way” to code and refuse to consider alternative perspectives, you’ll be a bottleneck for a collaborative team.

Practice “Showing Your Work”

When you ask for help or explain a problem, be ready to show what you’ve tried so far. This isn’t just for on-the-job communication; it’s vital for interviews. If you get stuck on a coding problem, don’t just stare at the board. Explain your investigation. Proving you’ve put in the effort before seeking a shortcut tells the interviewer you are diligent and self-driven.

It’s Not Always You: The Factor of Luck

I want to end this by reminding you that interviews are a skill, and like any skill, they require practice. But even if you do everything right -- if you represent your projects perfectly and showcase great interpersonal skills -- you might still get a rejection.

Sometimes it just comes down to bad luck. Someone else might have shown up that day with a slightly better-aligned set of niche experiences, or the hiring committee was split.

Don’t take it personally. You can only control what is in your power: your preparation, your curiosity, and your willingness to keep building. Focus on becoming the person who fits the role, rather than just looking for the shortcut to land the job.

Keep building, keep asking questions, and keep refining those “people” skills. They’ll take you further than any single line of code ever could.

Dev Leader Weekly

Discussion about this post

Ready for more?