# Show your engineering work: a portfolio that supports your resume Choose a work example that supports a requirement in the job description. Explain what you built, what you personally contributed, how someone can inspect or test it and what remains unfinished. Use real evidence rather than invented impact metrics. ## Choose a claim before choosing a template A portfolio should help someone understand what you can do. Start with one statement from your resume or a role’s requirements, then choose work that supports it. If you say you can build APIs, show a request moving through validation, storage, failure handling and tests. A polished homepage alone does not explain those decisions. For a first internship, a coursework or personal project can supply that evidence. For a mid-level role, you may have stronger examples from employment, but public sharing must respect confidentiality and ownership. You do not need to publish employer code to explain your contribution. Be explicit about what was personal practice, team work or production responsibility. This guide offers an editorial method for presenting work, not a hiring requirement. Some employers will assess you through an interview or take-home task instead. Choose the amount of portfolio work that fits your target roles and available time. ## Map the role to evidence you already have Read the employer’s requirements and separate what you have done from what you need to learn. Amazon’s resume guidance recommends aligning accomplishments with the role’s basic and preferred qualifications. That advice is specific to its recruiting process, but it offers a useful editing question: which part of your work helps a reader evaluate this requirement? Suppose an opening asks for API development, PostgreSQL and familiarity with queues. You have a service with database migrations and a background worker, but have never operated a production queue. Show the API and schema work directly. Label the worker as a learning project. Do not turn familiarity from an exercise into a claim of production operations experience. Keep missing evidence separate from a missing skill. If you have used migrations at work but left them off your resume, the next step is to describe the real experience. If you have not used them, a small exercise can help you learn, but completing it does not erase an employer’s explicit professional-experience requirement. Sources: [Amazon recruiters: writing a relevant resume](https://www.aboutamazon.com/news/workplace/amazon-job-application-resume-writing-tips) ## A worked example: a retrying webhook worker Consider a fictional personal project: a service that accepts an event and tries to deliver it to a callback URL. This is an illustration of how to explain a project, not a recommended production architecture or a metric you should copy into your resume. A weak description says: “Scalable notification system using Node.js, PostgreSQL and Docker.” A more useful description says: “Built a personal webhook-delivery service with persisted attempts, bounded retries and tests for duplicate submissions. I implemented the API, schema and worker; the demo uses synthetic events.” The second version describes inspectable behavior and ownership. Show one failure path. If the receiver processes a request but the response is lost, the sender may retry. Explain your retry limit, how attempts are recorded, and why an event ID alone does not guarantee that the receiver avoids duplicate effects. Include a test or a reproducible demo of the case. Discussing the remaining limitation demonstrates more understanding than claiming the system is “exactly once” without evidence. Then show what you would change next. Perhaps the demo accepts only a fixed test destination, has no production authentication, or has never been load-tested. State that boundary. A local demonstration should not invite strangers to submit arbitrary URLs or real personal data. ### Diagram: A fictional webhook project maps a claim to contribution, evidence and an honest limitation. 1. **Claim** — A personal webhook service persists attempts and bounds retries. 2. **Contribution and evidence** — Identify the API, schema and worker you built; link a synthetic demo and tests. 3. **Boundary** — A receiver can repeat effects after a lost response; an event ID alone is not a guarantee. ## Give each project a short, repeatable structure Put the summary in the repository README so a visitor does not have to find a separate document. GitHub’s documentation describes the README as a place to explain what a project does, why it is useful and how to get started. Keep setup steps short and accurate; longer architectural notes can live in linked documents. If you publish a demo, offer a path that works without a private account. If hosting is too expensive, a short recording plus reproducible local instructions may be sufficient for your purpose. Label a recording as a recording and note any setup limits. - Problem and audience: what does the project do, and for whom? One or two sentences are enough. - Your contribution: distinguish your work from teammates, libraries, tutorials and generated code. - Evidence: link to the relevant code, a test, a demo or a safe write-up. Explain what the reader should look at. - One decision: describe an alternative you considered, the constraint and why you chose your approach. - One failure: show a bug, edge case or operational risk and how you investigated it. - Limits and next step: name what is incomplete, untested or deliberately outside the demo’s scope. Sources: [GitHub Docs: about repository READMEs](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes) ## Use measurements only when you can explain them Numbers help when they answer a real question. If you measured latency, record the environment, dataset, workload and method. Say whether the result came from a local benchmark, a staging test or production. Keep the raw result or test script where you can inspect it later. Do not invent a percentage improvement because a resume template expects one. If you cannot substantiate an impact metric, describe the change and how you verified its behavior: “Added regression tests for duplicate submissions” is more credible than an unsupported “improved reliability by 90%.” Never copy the hypothetical results from someone else’s example as your own. AI tools may help you write or debug, but you should be able to explain the submitted work and follow any employer rules on assistance. Credit a tutorial or starter project and identify what you changed. A conversation about a small feature you understand is easier to sustain than one about a large generated codebase you cannot navigate. ## Check the link as a stranger before sharing Pin the most relevant public work on GitHub rather than asking a reader to search through all your repositories. Link to the exact project from an application or introduction. Keep a small set current; an old broken demo can create more confusion than a plain, accurate write-up. Opened’s optional paid public profile can collect reviewed work examples and links into a shareable page. Publishing is your choice. Its activity report describes visits and link activity; it cannot prove recruiter interest. A GitHub README or another portfolio can serve the same basic purpose: make the work behind your claims easier to inspect. - Open every link in a signed-out browser. Check the repository, demo, screenshots and any linked documents. - Read the page on a phone. Make the project purpose and your contribution visible before a long technology list. - Try the setup instructions from a clean checkout. Document missing services and use example configuration without secrets. - Remove credentials, private contact details, employer material and customer data. Review screenshots as well as source files. - Confirm that the resume claim and the project description agree about dates, ownership and whether the work reached production. Sources: [GitHub Docs: pinning work to your profile](https://docs.github.com/en/account-and-profile/how-tos/profile-customization/pinning-items-to-your-profile) ## References - [Amazon recruiters: writing a relevant resume](https://www.aboutamazon.com/news/workplace/amazon-job-application-resume-writing-tips) - [GitHub Docs: about repository READMEs](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes) - [GitHub Docs: pinning work to your profile](https://docs.github.com/en/account-and-profile/how-tos/profile-customization/pinning-items-to-your-profile) Updated 2026-11-02 by Opened editorial.