Why Portfolio Evaluation Is Different for Remote Hires
For in-office hires, a portfolio is supplementary to an interview. For remote hires, the portfolio is often the most verifiable evidence of what the candidate can actually do - more reliable than interview performance, which can be rehearsed, and more objective than reference checks, which are filtered.
A strong portfolio evaluation takes 20-30 minutes per candidate and prevents the most common expensive mistake in remote hiring: paying for 90 days of onboarding before discovering the candidate's actual skill level doesn't match their claimed experience.
The Portfolio Evaluation Checklist
Step 1: Live production URLs (5-10 minutes)
Ask for 3-5 live URLs of work the candidate built or contributed to significantly. Open each one.
Check:
- Is it actually live and functional? A portfolio full of 404s or "under maintenance" pages is a red flag.
- Does the performance suggest professional development? (PageSpeed Insights gives a fast read.)
- What can you see in the browser developer tools? Network tab reveals: what technologies they used (Next.js server responses, REST or GraphQL API calls, authentication headers), whether there's error handling, and whether the code is minified/optimized (production build) or raw (dev mode).
A candidate who has shipped production applications that real users depend on is meaningfully more reliable than one with only personal projects.
Step 2: GitHub profile (10 minutes)
Visit their GitHub profile directly. Check:
Commit history heatmap. A genuine developer has commits across 50+ weeks per year. A developer who built something 2 weeks before applying has a spike pattern. These are visually distinct and immediately obvious.
Code quality in public repos. Open their most recently active non-tutorial repository. Read 200 lines of code. Are functions meaningful? Is there structure? Any comments? Any tests? This takes 5 minutes and tells you more than a 30-minute interview.
Contribution to external repos. Check the "Contributions" tab - do they have merged PRs to other repositories? This reveals real code review experience and the ability to work within someone else's codebase conventions.
Step 3: Implementation interview (10 minutes)
For 2-3 portfolio items, ask:
- "What was the hardest technical problem you solved in this project?"
- "What would you do differently if you built it today?"
- "How does [specific feature] work at the implementation level?"
A developer who built something can answer these with specificity and appropriate nuance. A developer who listed someone else's work cannot - the answers become vague and non-specific quickly.
Portfolio Red Flags at a Glance
| Signal | What It Means |
|---|---|
| All tutorial project names (TodoMVC, WeatherApp, etc.) | No original problem-solving experience |
| GitHub commit spike 2 weeks before applying | Created GitHub account for job search |
| Production URLs return 404 | Never maintained or never deployed |
| Can't explain implementation of own project | Listed someone else's work |
| No tests anywhere across any project | Does not test habitually |
| All repos private, no take-home offered | Cannot verify claims |
| Repos all in same technology from 1 course | Narrow training, not diverse experience |
Get candidates with verified portfolios from F5's screening process or see how F5 vets candidates before the shortlist.
Frequently Asked Questions
What should I look for in a remote developer's portfolio? Live production URLs with real users, consistent GitHub commit history over 18+ months, and the ability to discuss implementation details of their own work.
How do I evaluate a developer's GitHub profile? Commit consistency over time (not a spike), code quality in public repos (read 200 lines), and contributions to external repos (PRs to other projects).
How do I verify a developer actually built what they claim? Ask specific implementation questions: "What was the hardest technical problem?" and "What would you do differently?" Genuine builders answer with specificity; those who listed others' work cannot.
What are the signs of a weak developer portfolio? Tutorial projects, single-spike GitHub history, 404 production URLs, inability to discuss implementation, and no tests across any project.
What makes a strong developer portfolio? Live production applications with real users, 18+ months of consistent commits, at least one non-trivial technical problem solved, and PR participation in external repos.
How does F5 evaluate portfolios? Reviews 3-5 examples, visits live URLs, checks GitHub quality and history, asks specific implementation questions. Candidates who can't discuss their portfolio in detail are not presented.
Should I always ask for a GitHub profile? Yes, for technical roles. Treat no public code presence the same as a designer with no portfolio - claims are unverifiable.