1 / 5
Describe a portfolio project using Problem → Solution → Impact structure — what goes in each section?
A Problem = the specific technical or business challenge (with context about scale/stakes), Solution = what you built/changed and key technical decisions, Impact = measurable outcome (latency reduced X%, user growth, cost saved). Together they make your work legible to someone unfamiliar with the codebase B Problem = general tech domain description, Solution = all technologies used, Impact = GitHub star count C Problem = bug description, Solution = code fix, Impact = lines of code changed D Problem = previous engineer's mistakes, Solution = your rewrite, Impact = subjective quality improvement
Portfolio narrative: Problem (why it mattered, constraints) → Solution (what you chose and why — highlight trade-offs) → Impact (quantified where possible). Key vocab: "problem statement", "solution narrative", "impact quantification", "portfolio case study".
Next →
2 / 5
Which impact statement is most compelling on a portfolio?
A "Fixed performance bottleneck in the payment service" B "Worked on backend performance to make the payment service faster" C "Reduced p99 latency of the payment service from 850ms to 120ms by introducing a connection pool and query optimisation — eliminating the primary cause of checkout abandonment under load (8% → 0.3%)" D "Implemented performance improvements resulting in significant latency reduction"
Impact quantification: specific numbers + before/after + business consequence. "850ms to 120ms" = technical proof. "8% → 0.3% abandonment" = business proof. Vague = meaningless. Key vocab: "quantified impact", "before/after metrics", "business consequence", "technical impact narrative".
Next →
3 / 5
A non-technical recruiter will review your portfolio — how should you adapt the language?
A Remove all technical details and focus only on business outcomes B Write two levels: a one-sentence plain-language summary of the project's business purpose, followed by technical detail for engineers — allowing both audiences to find value in the same project description C Use technical terminology only — recruiters forward portfolios to technical reviewers D Add a glossary explaining all technical terms at the bottom of the portfolio page
Dual audience: non-technical (business purpose + impact) + technical (stack, architecture, scale). One-sentence summary + technical deep-dive. Key vocab: "dual-audience writing", "plain-language summary", "technical depth layer", "portfolio accessibility".
Next →
4 / 5
How should you present a project where you were one of many contributors?
A Claim sole credit for the entire project B Avoid listing the project since individual contribution is unclear C List only the technology stack without describing your specific contribution D Use precise ownership language: "Led the authentication module redesign within a 6-engineer team", "Owned the data migration strategy", "Contributed the caching layer and wrote the accompanying architecture documentation"
Contribution language: "Led X", "Owned Y", "Contributed Z". Avoids overclaiming ("built the entire platform") and underclaiming ("helped on a project"). Key vocab: "contribution attribution", "led vs. contributed", "ownership scope", "team project individual contribution".
Next →
5 / 5
What makes a 'Technical decisions' section of a portfolio case study valuable?
A Listing all technologies evaluated before choosing the final stack B Defending every decision as the perfect choice for the problem C Explaining why you chose approach A over approach B — including trade-offs considered, constraints that shaped the choice (time, team skill, scale), and in retrospect what you'd do differently — demonstrating engineering judgment, not just execution D Describing the project timeline and sprint structure
Technical decision narrative: "we chose X over Y because at our scale Z was acceptable and Y required infrastructure we didn't have." Shows: trade-off awareness, constraint-driven thinking, maturity. Key vocab: "engineering trade-off narrative", "constraint-driven decision", "retrospective honesty", "engineering judgment demonstration".
See results