How to Evaluate Developer Portfolios

Every developer has a portfolio. Websites with screenshots, project descriptions, maybe some logos of impressive-sounding clients. But portfolios are marketing materials. They're designed to make people look good, not to give you the full picture.

Here's how to look deeper and actually figure out if someone can deliver.

What Portfolios Show vs. What You Need to Know

Portfolios show: what the finished product looked like.

They don't show: how it was built, how the project went, whether it's still working, whether the client was happy, what role the developer actually played, or how much was their work vs. their team's.

A beautiful screenshot tells you someone has design skills or good taste. It doesn't tell you they can architect a system, handle deadlines, communicate effectively, or write maintainable code.

Ask About Their Actual Role

This is the big one. "I worked on this project" could mean:

• I was the sole developer and did everything
• I led a team that built it
• I was one of five developers and built the login page
• I did freelance design work for the agency that built it
• I helped with bug fixes after someone else built the core

These are very different levels of involvement. Ask specifically: what was your role? What did you personally build? Who else worked on this?

There's nothing wrong with being part of a team. Most good work is collaborative. But you need to understand what skills you're actually evaluating.

Check If Projects Still Exist

Is that impressive app still running? Can you download it and try it? Is the website still live?

Dead projects aren't automatically disqualifying - clients shut things down, companies pivot, startups fail. But if someone's portfolio is full of links that 404, that tells you something. Either the work didn't stick, or it was too long ago to be relevant.

For projects that do exist: click around. Is it fast or sluggish? Does it work on mobile? Does it have obvious bugs? The current state reflects what was delivered, at least partially.

Look for Relevant Experience

A developer who's built ten e-commerce sites is more prepared for your e-commerce project than someone who's built ten portfolio websites. Experience in your specific domain matters.

This doesn't mean you should reject anyone without exact experience. Good developers can learn. But when evaluating portfolios, weight projects that are similar to yours more heavily.

Also look at tech stack overlap. If you need a React app and their portfolio is all WordPress sites, there's a learning curve you're paying for.

Ask for References

The portfolio shows you the output. References tell you what it was like to get there.

Ask to speak with past clients. Not the ones the developer cherry-picked for their testimonials page, but actual people who worked with them recently on projects similar to yours.

Questions to ask references:

• Did the project finish on time and on budget?
• How was communication?
• How did they handle problems or disagreements?
• Would you work with them again?
• What's one thing you wish had gone differently?

If a developer won't provide references, or the references sound rehearsed, that's a signal.

Code Samples and GitHub

For technical evaluation, look at their code. Many developers have public GitHub profiles with open-source contributions or personal projects.

You don't need to understand the code yourself. But you can get someone technical to take a look. Are the commits regular? Is there documentation? Does the code have tests? Is it organized logically?

If there's no public code, ask if they can share samples from past projects (with client permission) or a private repo they can walk you through. Developers who are proud of their code usually have something to show.

The Complexity Test

Pretty marketing sites are easy. Complex systems with multiple user roles, payment processing, integrations, and real-time data are hard.

Look at the complexity of portfolio projects:

• Do they have user authentication and accounts?
• Do they involve payment processing?
• Are there integrations with third-party services?
• Is there an admin backend?
• Do they handle real-time updates?
• Are there multiple user types with different permissions?

The more checkboxes you can tick, the more evidence you have that they can handle complex requirements.

Communication Signals

How they present their portfolio tells you something about communication skills.

Is the portfolio itself well-organized? Are descriptions clear and specific, or vague and jargony? Do they explain problems they solved and decisions they made, or just list features?

The best portfolio descriptions tell stories: what the client needed, what challenges came up, how they were solved, what the outcome was. This shows they can think about their work from a client's perspective.

Age and Relevance

Technology moves fast. A project from 2018 might as well be from another era. Check when projects were completed.

If someone's most impressive work is five years old, what have they been doing since? Maybe they've been working on confidential projects they can't show. Maybe they've been maintaining rather than building. Maybe they've been out of the industry. Ask about it.

Red Flags

• All projects look similar (they might have one trick)
• No projects have live links (nothing worked well enough to stay online)
• Can't or won't give references (unhappy clients)
• Vague about their actual contribution (inflating their role)
• Everything is from years ago (might be rusty)
• Only personal projects, no client work (might struggle with real requirements and feedback)

What Actually Matters

Portfolios are one input, not the whole picture. Use them to filter candidates, then dig deeper.

The questions that really matter are:

• Have they built something similar to what you need?
• Can they show that it worked and that clients were happy?
• Do they communicate clearly?
• Does their code (if you can see it) meet professional standards?

If you can't answer those questions from the portfolio alone, that's fine. That's what discovery calls, references, and technical assessments are for. The portfolio is just the starting point.