I've interviewed a lot of junior developers over the years. Some came with impressive portfolios and struggled with basic communication. Some came with modest portfolios and turned out to be exceptional hires. The difference was almost never technical skill — at the junior level, that's improvable. The difference was almost always how they approached problems they hadn't seen before.

This applies in both directions: if you're a founder hiring for the first time, this is what to look for. If you're a developer trying to stand out, this is what matters on the other side of the table.

Curiosity over fluency

The best junior developers I've worked with were relentlessly curious. They came to interviews with questions about how we built things, why we made certain decisions, what problems we were trying to solve. They didn't just answer questions — they engaged with them.

Framework fluency can be learned in a few months. Curiosity is harder to teach. Someone who genuinely wants to understand how things work will grow faster and contribute more than someone who knows the syntax but stopped asking why.

In interviews, I watch for whether someone asks follow-up questions or just gives answers. I notice whether they talk about side projects and personal learning with genuine enthusiasm or just as resume filler. I ask "what's the last thing you taught yourself?" — not to get a specific answer, but to see whether they're in the habit of learning.

Version control as a baseline

Git is table stakes. Not just "I've used GitHub to submit assignments" — actual working knowledge of how to branch, commit meaningfully, resolve a merge conflict, and understand what the history tells you.

This comes up because version control isn't just a tool — it's evidence of professional practice. Someone who has collaborated on a real codebase, managed branches, and written commit messages other people will read has worked at a higher level than someone who treats git as a save button.

Ask them to walk you through a recent commit history on one of their projects. What story does it tell? Are the commits meaningful or just noise? Can they explain why they made specific decisions?

Communication

The hardest part of junior developer work isn't writing code. It's navigating the gap between what you understand and what you don't, without spinning for two days on a problem that a single conversation would have resolved.

I want junior developers who ask for help when they're stuck — not after they've been stuck for three days, but after a reasonable effort of their own. I want them to be able to say "I've tried this and this, I think the problem is here, but I'm not sure — can you look at it?" That's a professional communication pattern that some developers never develop.

In interviews, I ask: "Tell me about a time you were stuck on something for a while. What did you try? When did you ask for help?" The answer reveals more about working style than any technical question.

What a good portfolio actually signals

A strong junior portfolio isn't about visual polish. It's evidence of completeness and intention.

I want to see: projects that actually work (not just screenshots), code that's readable and organized, some evidence of having received and incorporated feedback, and a brief explanation of what each project is and what it does.

What I'm less impressed by: a long list of tutorial projects from the same bootcamp, sites that look great but have no backend, projects where every repo is a fork with no meaningful commits.

The best signal is a personal project the developer built to solve a real problem they had. Not impressive in complexity — impressive in motivation. They saw something that needed to exist and built it.

The honest advice for developers

If you're a junior developer reading this: your portfolio matters less than your process. Be able to articulate how you think, what you don't know yet, and how you'd go about learning it. Be honest in interviews about the edges of your knowledge — trying to perform competence you don't have is immediately visible and always counterproductive.

The developers who grow fastest are the ones who ask good questions, communicate clearly, and stay curious long after they stop being "junior." Start building those habits now.