What does it mean when a portfolio only shows design-heavy front-end projects?

A portfolio that only shows visual front-end work with no mention of the backend, data layer, or deployment tells you that the developer's experience may be primarily UI-focused. This is not inherently a red flag for a front-end role, but it becomes a concern when the role requires full-stack work. Probe the depth: ask about how data is fetched, where it is stored, how authentication works, and how the application is deployed. If the developer cannot answer these questions about their own projects, the back-end work was done by someone else or not done at all.

What does poor code quality in public repositories signal?

Public GitHub repositories with readable code, meaningful commit messages, and README documentation signal that the developer cares about the craft beyond just making things work. Public repositories with a single commit containing all code, no README, hardcoded credentials in source, or naming conventions like 'test2' and 'fixfinal' signal that the developer does not apply production-quality practices to their personal work. This is a reliable proxy for the code quality standard they will apply to professional work.

What is concerning about a portfolio with no recent work?

A portfolio where the most recent project is two or three years old raises questions: has the developer been working in roles where they cannot share work publicly, or have they not been active? There is a legitimate version of this (corporate roles with IP restrictions) and a concerning version (not shipping anything for years). The follow-up question is what the developer has been building or learning recently that is not represented in the portfolio. A developer who cannot describe recent learning or recent professional work may have stagnated.

What does it mean when a developer cannot explain why they made specific technical decisions?

A developer who can describe what they built but not why specific choices were made has limited ownership of the architecture. If the choices were made by a senior team member, that is fine, but the developer should know that and be able to describe what they learned from the experience. If the choices were made by the developer and they cannot explain the reasoning, it suggests the decisions were made without deliberate judgment. Technical decision explanations ('We chose PostgreSQL because we needed relational constraints and the team knew it' vs 'We chose PostgreSQL because it was default') reveal the depth of engineering thinking behind the work.

What does it mean when a portfolio only shows incomplete or unmaintained projects?

A portfolio of projects that are all described as 'in progress' or that have obvious quality issues (broken links, missing functionality) suggests difficulty completing work. Every developer has side projects that did not ship, but a portfolio that only shows unfinished work raises questions about the ability to bring work to completion in a professional context. The concerning version is when the developer cannot explain why projects were not completed. The neutral version is when the developer can articulate clear reasons (scope changed, client cancelled) and shows completed professional work even if personal projects are all experiments.

Hiring Developers, Freelancers, and AgenciesMay 23, 20266 min read

Red Flags in a Developer's Portfolio

Portfolio red flags are signals in a developer's presented work, explanations, and public code that suggest potential problems with code quality, professional judgment, communication, or fit for the role being evaluated. A portfolio assessment is one of the most information-dense parts of a hiring process because it shows actual output rather than claimed skills. Reading portfolios effectively requires knowing what absence of information signals as much as what presence signals.

Written by Yashveer Singh, founder of Yashveer Labs.

What you need to know

A portfolio shows actual output. Treat it as a code review, not a resume bullet list. What is there, what is missing, and how decisions are explained all matter.
Public GitHub repositories reveal real code quality habits better than any interview question about code quality.
An inability to explain why specific technical decisions were made suggests the developer did not own those decisions.
Only incomplete projects in a portfolio is a pattern worth probing. Ability to complete and ship is a core professional skill.
Mismatch between described role and portfolio depth (claiming back-end work but showing only front-end projects) is worth clarifying explicitly before investing more interview time.

The core argument

Hiring is easier when you read what is actually in front of you rather than what you want to see. A developer with a polished portfolio website may have template code behind the scenes. A developer with a sparse portfolio may have done serious work that is not publicly shareable. The portfolio evaluation is not about counting projects; it is about reading the signals in what is shown and asking the right follow-up questions about what is not.

The most reliable signal in a portfolio is code quality in public repositories. Not the quantity of code, not the number of stars, but the practices visible in the code: meaningful variable and function names, sensible file organization, evidence of error handling, and commit history that shows incremental progress rather than a single initial commit. Developers who write clean, well-organized code for their personal projects bring the same standards to professional work. Developers who treat their personal projects as throwaway code tend to treat professional code the same way when deadline pressure arrives.

The second most reliable signal is the quality of decision explanations. A developer reviewing their portfolio who can say "we chose this approach because of X constraint, considered Y alternative, and accepted Z tradeoff" demonstrates the kind of deliberate engineering thinking that produces good architectural decisions in professional work. Developers who can describe what they built but cannot explain the reasoning are either executing instructions from others (which is fine at junior level, less fine at senior) or making decisions without deliberate judgment.

Common mistakes (evaluators make)

Dismissing portfolios that lack visual polish. A developer who spent time on clean code and good architecture instead of a polished portfolio website may be a better hire than a developer with a beautiful site over template code. Evaluate the underlying work, not the presentation layer.

Not looking at commit history. A GitHub repository with all code in a single initial commit may be work that was developed privately and then made public. It may also be copied from another source. Looking at commit history reveals whether the developer actually built the project incrementally or published finished code.

Not checking if the portfolio work actually runs. Following the setup instructions in a README and verifying that the project works as described is a simple but revealing check. A developer who gives instructions that do not produce a working result either has not tested the instructions or does not prioritize documentation accuracy.

Treating "built with React" as equivalent to "built React Native with Bluetooth integration." Technology mentions in portfolio descriptions vary enormously in what they actually mean. A project "built with React" that uses a starter template and Redux Toolkit with minimal customization is different from a project that implements complex state management. Ask for the most technically challenging part of each project.

Not asking about failures. Projects that did not ship, architectural decisions that proved wrong, and approaches the developer would change retrospectively reveal more about engineering judgment than successful outcomes. Developers who have never made a decision they regret have either not made decisions or not reflected on them.

Where to start

Before the interview, spend 30 minutes on the portfolio. Read the project descriptions, open the most recent or most complex project's repository, look at the code and commit history, and prepare specific questions about the technical decisions visible. Arriving at an interview having actually reviewed the work produces a higher-quality conversation and signals respect for the candidate.

Ask about one specific technical decision in each project. "Why did you choose this database?" "What was the hardest part of this integration?" "What would you do differently now?" These questions separate developers who owned the technical decisions from developers who executed instructions. The quality of the explanation is the signal.

Check the consistency between described skills and demonstrated work. If a candidate lists a skill prominently on their resume, look for evidence of that skill in the portfolio. If it is not present, ask for examples of work using that skill that are not in the portfolio. Inconsistency between claimed skills and demonstrated work is not necessarily disqualifying but is worth understanding.

Frequently asked

Author

Why Yashveer Singh is the right hire here

The right hire for the work in this article is someone who has done it, written about it, and is willing to back it up with their name. That is me. Yashveer Singh. Founder of Yashveer Labs. New Delhi. The work I have shipped is on the homepage. The work I am writing about is the work I do. There is no mismatch between the page and the engineer behind it.

Start the conversation See the work DM on Instagram

Red Flags in a Developer's Portfolio

What you need to know

The core argument

Common mistakes (evaluators make)

Where to start

Related reading

Frequently asked

Why Yashveer Singh is the right hire here

Hiring Mistakes That Founders Repeat Endlessly

Hiring Offshore: The Real Tradeoffs Beyond Cost

Hiring Your First Engineering Manager: A Founder's Guide

How Recruiters Can Read a GitHub Profile Like a Hiring Manager