I've been the technical interviewer for over 200 developer candidates at two different companies over the past five years. I've reviewed several hundred GitHub profiles. I want to tell you what I actually notice and what I don't — because most portfolio advice is written by people who haven't recently been on the hiring side.
What I Look At First
I open GitHub and I look at contribution activity first. Not the green squares — the actual recent commits. I want to see that you're writing code consistently, not that you had a burst three years ago. If the last commit to any project was more than six months ago, I'm paying attention to why.
Then I pick one or two pinned repositories and I open them. I'm not reading the code first. I'm reading the README. A good README tells me: what does this project do, why did you build it, how do I run it, and what technical decisions did you make? If the README is three lines and says "A todo app", I've already learned something about how you communicate and document your work.
The Portfolio Mistake I See Most Often
Too many projects, none of them finished, none of them deployed. Ten repos with names like "learning-react-2024", "practice-api", "todo-app-1", "todo-app-2". These projects demonstrate that you started things but not that you can ship things, and shipping things is what the job is.
Three projects, each deployed and working, each with a README that explains technical decisions, is dramatically stronger than twenty tutorial clones.
What "Interesting Projects" Actually Means
The best projects solve a real problem that you or someone you know actually had. Not "I built a todo app to learn React" but "I built a tool that automatically fetches my electricity usage data and sends me a weekly text summary because I kept forgetting to check it." The second one tells me: you identified a real problem, you had the initiative to build a solution, and you followed through to something you actually use. That's exactly what I'm hiring for.
Code Quality Signals
I look at commit history on interesting projects. A single "initial commit" with 2,000 lines of code followed by nothing tells me you don't use Git as a development tool. Commit history showing iterative development — small commits with clear messages, refactoring commits, bug fix commits — tells me you work the way professional developers work.
I also look at whether there are tests. Not whether the test coverage is perfect — whether testing is present at all as a concern. Some tests, even simple ones, demonstrate awareness.
The One Thing That Differentiates Above Everything Else
Evidence that you've thought about your technical decisions. I'm not looking for perfect decisions — I'm looking for deliberate ones. A PR description or a README section that says "I chose X over Y for this reason" is more impressive than code that happens to use the right library without any evidence that you chose it over the alternatives.
This is also what you should talk about in interviews. Not "I built a React app" but "I built a React app and chose Zustand for state management instead of Redux because the simpler API fit a project of this scale." That sentence tells me more about your engineering judgment than an hour of trivia questions.
