Application Documents
The engineer portfolio: when it matters, what reviewers open, and what to build if you have nothing
Who actually needs a portfolio, the twenty-minute review reality, GitHub and README standards, and a four-week build plan for career changers.
What you can use right away
- Experienced engineers need a portfolio rarely; career changers need one desperately — it is their only work sample.
- Reviewers spend minutes, not hours: the README, commit history, and one code file decide the impression.
- One finished, deployed, documented project beats five tutorial clones.
Who actually needs one
The honest calibration first: an engineer with five years of shipped work rarely needs a portfolio — the shokumukeirekisho's project entries and the technical interview carry the evaluation, and a GitHub profile with some real activity is a bonus, not a requirement. The portfolio becomes decisive exactly where work history goes silent: career changers into engineering, new graduates, long gaps, or moves into a stack your resume cannot evidence.
For those cases it is the single highest-leverage asset you can build, because it replaces the missing track record with a checkable one. "未経験だがポートフォリオがある" and "未経験" are different applications entirely.
The twenty-minute review: what actually gets opened
Reviewers do not study your portfolio; they sample it. The realistic sequence: the README (does it say what this is, why it exists, and how to run it?), the deployed link if one exists (does it work?), the commit history (real development rhythm or one giant upload?), and one or two source files chosen at random (naming, structure, consistency). Twenty minutes, often less.
Optimize for that sequence: a README with a screenshot, a one-paragraph purpose, the stack, setup steps, and — the differentiator — a "design decisions and trade-offs" section that explains one or two choices. That section is where a portfolio stops being a student exercise and starts being an engineering artifact.
What to build: one real thing
The tutorial-clone trap is real: five to-do apps signal course completion, not engineering. Build one thing that solves a problem you actually have — a tool for your current non-engineering job is ideal for career changers, because it also feeds your motivation story. Finish it: deployed, handling errors, with a few tests. Depth beats breadth at every review.
Scope it honestly — a CRUD app with authentication, a database, and deployment already demonstrates the full basic loop. Add one distinguishing layer you can discuss: a performance measurement, an external API integration, a CI pipeline. Every element you add is something you may be asked about; never include technology you cannot explain.
Try this checklist
- Write the README first — purpose, stack, setup, one design decision — then code toward it.
- Deploy early and keep it deployed; a dead link is worse than no link.
- Commit in small, described steps — the history is part of the submission.
The four-week version for career changers
Week one: define the problem and write the README skeleton; set up the repository, linter, and deployment pipeline with a hello-world. Week two: core feature, ugly but working, committed daily. Week three: the distinguishing layer plus error handling and tests. Week four: polish the README, add the screenshot and the trade-offs section, ask one person to follow your setup instructions cold.
A month of evenings produces something reviewable — and the process itself generates interview material: every obstacle you hit and solved is an episode for the "how do you learn" questions that dominate inexperienced-candidate interviews.
The portfolio feeds the interview
A portfolio is not just a screening asset; it is the anchor for your technical conversations — expect "walk me through this project" and deep-dives on your choices.
InterviewTrail AI stores your portfolio project as structured Career Memory alongside your work history, predicts the questions it will attract, and drafts answers grounded in what you actually built.