Sample reportBuilt from invented material, not a real person's information
A portfolio review for a fictional career-changing frontend developer
Frontend developer · Junior · Updated 2026-09-17
A complete illustrative portfolio review with a score, five dimensions, evidence, risks and follow-up questions. The candidate, measurements and results are fictional; this is not a real user report or a hiring prediction.
The fictional candidate in this sample
A fictional applicant moving from another occupation into frontend development, with a budgeting app, a personal recreation of an internal dashboard and an open-source accessibility contribution.
What to look at
- Illustrative score: 74/100. The example shows how measured evidence can support a portfolio claim.
- The main missing context is the previous career and reason for changing roles.
- A useful first edit is explaining the state-management choice and its trade-offs.
Pass range
11 to the top band
Pass band from 70
4/5 dimensions in the pass band · Role fit 7/10
The sample shows a useful habit of measuring performance, but technology choices and the career-change story need clearer evidence.
Five dimensionsOut of 20 · pass line 14
- Technical depth13
- Impact and results14
- Distinctiveness14
- Structure and storytelling16
- Readability and completeness17
Role fitThe example addresses frontend performance and accessibility and describes deployed work. Collaboration and testing evidence are missing, so the document does not yet show how the candidate would share responsibility for a team codebase.
4 things to do before you submit
High 2 · Medium 2- 1
Explain the previous careerHigh
- Describe its duration, responsibilities and the practical problem that led to software development.
- 2
State the reasons for three tool choicesHigh
- Add one line each for state management, styling and build tooling: the problem, choice and accepted trade-off.
Now“It is popular”Better“Six screens shared the same data; I accepted extra setup code to keep updates consistent.” - 3
Move the accessibility contribution earlierMedium
- Give this contribution a visible place and include comparable checks or review evidence.
- 4
Replace opening promises with factsMedium
- Explain the previous work and what the candidate can now build rather than promising future growth.
Evidence by dimension
Summary
- This fictional portfolio is reviewed for a junior frontend engineering role.
- It supports its performance claims with before-and-after measurements of initial rendering and layout shift, and includes a merged accessibility contribution.
- The main gaps are the reasoning behind state-management choices and the explanation of the move from a previous career.
- All scores, measurements and observations on this page are illustrative sample data, not results from a real candidate.
Technical depth
1 to pass band13/20The tool list is complete, but most selection criteria are absent. Measuring performance while leaving architecture choices unexplained creates a gap in the story.
EvidenceThe state-management choice is explained only as popular and well documented.
BenchmarkIllustrative assessment: the reasons and trade-offs need more evidence.
SuggestionFor each major tool, state the problem it solved and the trade-off accepted.
Impact and results
In pass band14/20Before-and-after values and screenshots support the performance changes. Only two projects include measurements; the accessibility contribution stops at a general improvement claim.
EvidenceThe fictional example states initial render time of 3.4 → 1.9 seconds and layout shift of 0.18 → 0.02, with developer-tool screenshots.
BenchmarkIllustrative assessment: results are supported more clearly here than in the accessibility section.
SuggestionAdd comparable before-and-after accessibility checks and describe their limits.
Distinctiveness
In pass band14/20The budgeting app and dashboard are familiar project types. The accessibility contribution provides a more individual story, but it is easy to miss at the bottom.
EvidenceThe accessibility section has only four lines at the end of the example document.
BenchmarkIllustrative assessment: the differentiating evidence needs a more visible position.
SuggestionMove the contribution earlier and connect it to the perspective gained in the previous career.
Structure and storytelling
In pass band16/20Each project follows a consistent problem, attempt and result structure, with summary cards to guide the reader.
EvidenceThe budgeting app starts with scrolling becoming choppy as its list grows, then describes the attempts and outcome.
BenchmarkIllustrative qualitative assessment: the structure is clear. No population percentile has been measured.
SuggestionReplace the opening promises with facts about the previous role and what the candidate can now build.
Readability and completeness
In pass band17/20Sentences are short, images are consistent and the fictional portfolio has working deployment links.
EvidenceThe example assumes all three deployment links respond and match their screenshots.
BenchmarkIllustrative assessment: presentation is a strength; this is not a measured percentile.
SuggestionAdd useful alternative text to images, especially in a portfolio that discusses accessibility.
Strengths & risks
Strengths
Biggest strengthThe sample pairs screenshots with a change in initial render time from 3.4 to 1.9 seconds and layout shift from 0.18 to 0.02. These are fictional example measurements.
- Performance claims are accompanied by example measurements and screenshots
- All three fictional projects include deployment links
- The open-source contribution provides an external review context
- The document has consistent formatting
Screening risk signalsCaution
Biggest riskThe previous career receives only one line. Readers cannot understand the reason for the transition or the experience it contributes.
- The previous career is reduced to one line, hiding information that could explain the transition and distinguish the candidate.
- Several technology choices are justified by popularity rather than project requirements.
- Solo projects dominate the portfolio, with little evidence of collaboration.
Seen first
- Before-and-after rendering and layout-shift measurements
- Deployment links for all three example projects
- An open-source accessibility contribution
Missing
- The duration of the previous career and reason for changing roles
- Reasons for state-management and routing decisions
- Evidence of working with other people
Follow-up questions
- 1
Did a problem in your previous career influence one of these projects?
What this lifts · This can connect the career transition to a specific problem and design decision.
- 2
Have you reviewed someone else’s code or responded to review comments, including on the open-source contribution?
What this lifts · This would supply collaboration evidence that the current document lacks.
- 3
Did any metric become worse while you improved performance?
What this lifts · An answer about a real trade-off would clarify the reasoning behind the implementation.
You can get the same report on your own portfolio. Signing up gives you one free portfolio review per day.
Review my portfolioThe portfolio, scores, and review text on this page were invented for illustration. They are not a real user's material or report, and they do not refer to any real individual or company. The layout and review criteria match the real report.