Module 5: Portfolio & Specialization Assessment: Case Studies
These case studies package the capstone into credible engineering evidence: case study, portfolio, specialization decision, and spoken defense.
Case Study 1: Capstone Case Study That Reads Like A Feature List
Scenario: The portfolio page lists technologies: React, Node, PostgreSQL, Docker, AWS. It does not explain the problem, tradeoffs, failure modes, or evidence.
Source anchor: GitHub's Managing your profile README shows where project narrative is surfaced; the capstone still needs engineering evidence, not a technology inventory.
Module concepts: portfolio narrative, evidence, tradeoff, engineering judgment.
Wrong Approach
List technologies as proof of skill.
Better Approach
Write the case study:
Problem:
who needed what
Constraints:
time, budget, reliability, security
Design:
core architecture and rejected options
Evidence:
tests, ADRs, deployment, runbook, metrics
Reflection:
what changed and what remains weak
Failure Mode
Reviewers see tool familiarity but cannot infer judgment, delivery discipline, or whether the capstone solved a meaningful problem.
Project / Capstone Connection
Use this to structure the public write-up for your own capstone so the portfolio page reads like engineering evidence.
Tradeoff Table
| Option | Benefit | Cost | Better fit when |
|---|---|---|---|
| Technology list | quick to write | weak credibility | the page is only an index, not the main project story |
| Evidence-led case study | stronger engineering signal | more writing and curation | the capstone is a core portfolio artifact |
Required Artifact
Write a 15-minute-readable capstone case study with screenshots, diagrams, ADR links, and operational evidence.
Case Study 2: GitHub Repo That Does Not Survive Inspection
Scenario: The app works, but the repo has no setup instructions, no architecture docs, unclear commits, and no demo path.
Source anchor: Official GitHub README guidance is the anchor here because the README is the entry point reviewers will inspect before they trust deeper artifacts.
Module concepts: README, repo hygiene, demo path, evidence of craft.
Wrong Approach
Assume reviewers will run the app from source code alone.
Better Approach
Create a reviewer path:
README:
what it is
why it matters
architecture
local setup
tests
deployment
demo account/data
known limitations
Failure Mode
The capstone may work, but the repo fails the first inspection because reviewers cannot orient themselves, reproduce the system, or find the evidence efficiently.
Project / Capstone Connection
Use this to make your capstone repository reviewable by someone who spends five minutes scanning before they choose to invest more time.
Tradeoff Table
| Option | Benefit | Cost | Better fit when |
|---|---|---|---|
| Minimal README | low writing effort | poor reviewer onboarding | internal throwaway projects |
| Reviewer-path README | faster inspection and stronger trust | more maintenance | public capstones and hiring portfolio repos |
Required Artifact
Write a project README checklist and apply it to the capstone repo.
Case Study 3: Specialization Choice By Vibes
Scenario: The learner says they are interested in backend, cloud, security, distributed systems, and data. The next learning plan has no priority.
Source anchor: StaffEng archetypes and Will Larson's Readable engineering strategy documents are useful here because specialization works better as an explicit strategy than as a loose preference list.
Module concepts: specialization, evidence inventory, 12-month plan, strategy.
Wrong Approach
Pick a direction based on what sounds impressive this week.
Better Approach
Score evidence:
Track:
backend/platform/distributed/security/data
Evidence:
strongest projects
strongest artifacts
weakest gaps
market fit
motivation
Failure Mode
Learning time scatters across too many directions, so the portfolio stays broad but shallow and no specialization story becomes credible.
Project / Capstone Connection
Use this to decide which capstone strengths you will amplify into your next 12 months of portfolio and study work.
Tradeoff Table
| Option | Benefit | Cost | Better fit when |
|---|---|---|---|
| Interest-only choice | emotionally easy | weak prioritization | you are still in broad exploration mode |
| Evidence-scored choice | clearer direction and narrative | forces harder tradeoffs | you want the capstone to anchor a specialization story |
Required Artifact
Create a specialization decision matrix and 12-month learning plan.
Case Study 4: Defense That Avoids Tradeoffs
Scenario: In the final defense, the learner explains only happy-path features. A reviewer asks why PostgreSQL, why modular monolith, why this SLO, and the answers are vague.
Source anchor: ADRs and architecture review artifacts are the right anchor because defense quality comes from explicit tradeoffs already recorded during Modules 1-4.
Module concepts: defense, tradeoff, ADR, evidence, concise explanation.
Wrong Approach
Demo features and hope the reviewer does not ask design questions.
Better Approach
Prepare five defense answers:
Why this problem?
Why this architecture?
Why this data model?
Why this deployment?
What would you change with 3 more months?
Failure Mode
The demo looks polished, but the defense collapses when reviewers probe decisions, alternatives, or known limitations.
Project / Capstone Connection
Use this to rehearse the exact design questions your own capstone evidence should already answer.
Tradeoff Table
| Option | Benefit | Cost | Better fit when |
|---|---|---|---|
| Feature-only demo prep | easier rehearsal | weak answer depth | the audience only cares about surface behavior |
| Tradeoff-focused defense prep | stronger technical credibility | more deliberate preparation | the capstone will be questioned by engineers or instructors |
Required Artifact
Write and rehearse a 5-minute defense script plus 10 likely reviewer questions.
Case Study 5: Honest Gaps Inventory
Scenario: The portfolio claims production readiness, but there is no load test, no real users, and no backup drill. The learner hides the gaps.
Source anchor: Strong engineering portfolios improve credibility by naming what was not proven, what evidence exists, and what next work would close the gap.
Module concepts: limitations, next steps, integrity, learning plan.
Wrong Approach
Market the capstone as more mature than it is.
Better Approach
Name the gaps:
Not proven:
sustained production load
multi-tenant abuse handling
disaster recovery under real outage
Next:
load test, auth hardening, backup automation
Failure Mode
Reviewers detect overclaiming, which weakens trust in the rest of the portfolio even when the actual project work is solid.
Project / Capstone Connection
Use this to write the limitations section for your capstone so the artifact reads honest, mature, and scoped to the evidence you actually have.
Tradeoff Table
| Option | Benefit | Cost | Better fit when |
|---|---|---|---|
| Over-polished claim set | sounds impressive briefly | credibility loss under scrutiny | never when reviewers can inspect the evidence |
| Honest gaps inventory | stronger trust and clearer next steps | exposes unfinished areas | the capstone is a learning artifact, not a finished product company |
Required Artifact
Write a "Known Limits and Next Work" section with severity, evidence, and next action.
Source Map
| Source | Use it for |
|---|---|
| GitHub profile README docs | understanding where portfolio narrative is surfaced on GitHub |
| StaffEng archetypes | comparing long-term engineering direction options |
| Will Larson strategy writing | turning a specialization plan into a concrete strategy document |
Completion Standard
- Capstone case study is published.
- Repo README supports reviewer inspection.
- Specialization matrix and 12-month plan are complete.
- 5-minute defense is rehearsed.
- Known limits are written honestly.