Building a Portfolio and Work Samples That Get Remote Interviews

This guide is for anyone applying to remote roles who needs to show their work, not just describe it: developers, writers, designers, analysts, and support or operations people. It covers what to include for your kind of role, how to make each piece quick to review, and how to show client or employer work without breaking confidentiality.

Why work samples matter more in remote hiring

When a team hires someone they may never meet in person, written evidence carries a lot of weight. A resume tells a reviewer what you say you did. A work sample lets them see how you think, how you explain your decisions and how carefully you finish things. For candidates in India applying to teams abroad, a good sample also narrows the trust gap that distance creates, because a reviewer in another time zone can open your work whenever suits them and judge it without scheduling a call.

A portfolio does not need to be large. It needs to be relevant to the role, quick to review and honest about what you personally contributed. Three well-explained pieces usually do more for you than twenty links nobody has time to open.

• Relevance: choose work that resembles the job you are applying for.
• Context: explain the problem, who the work was for and what your part was.
• Reviewability: a stranger should understand each piece within a few minutes.
• Honesty: never present team work as solo work, and never invent results.

Developers: make your GitHub easy to review

Reviewers often skim. Few have time to read a whole codebase, and many open one or two repositories and start with the README. GitHub's own documentation describes the README as the place to explain what a project does, why it is useful, how to get started and where to get help. Treat every repository you want reviewers to see as a small product with that front page.

README checklist

1. One or two sentences on what the project does and the problem it solves.
2. How to install and run it locally, with exact commands that you have tested on a clean setup.
3. A short note on key design decisions and trade-offs, such as why you chose a particular database or library.
4. How to run the tests and what they cover.
5. Known limitations and what you would build next with more time.
6. A screenshot or short screen recording if the project has a user interface.

GitHub lets you pin up to six repositories or gists to your profile, so choose the ones you want reviewers to open first instead of leaving the platform to show whatever happens to be popular. You can also add a profile README by creating a public repository with exactly the same name as your username and putting a README.md file in its root. A few lines on what you work on and which projects to look at is enough.

Decide deliberately whether to add a licence. GitHub's documentation explains that without one, default copyright law applies: people can view and fork a public repository, but they have no permission to reuse or redistribute the code. Either choice is fine for a portfolio, but making it on purpose looks professional.

Small signals count too: readable commit messages, a tidy folder structure, no leftover debugging code and a dependency list that actually installs. If your best professional code is private, build one focused sample that reflects the kind of work the role involves, such as a small API with tests for a backend role, rather than another generic to-do app.

Designers: show your process, not only the final screens

Nielsen Norman Group's portfolio guidance suggests picking roughly three to five projects for detailed case studies and favouring a small set of strong projects over a large gallery. For each case study it recommends covering the problem, your role and how you collaborated, how you reached the solution, the challenges and ideas you set aside, the effect on users and the business, and what you learned.

• Open each case study with the problem and its constraints, not with the final mock-up.
• Include early sketches, wireframes, research notes and iterations alongside polished visuals.
• Explain at least one idea you dropped and why, since reviewers want to see your judgement.
• Keep the layout scannable, with short captions under each image, because reviewers often skim.

For remote roles, also show how you worked with people you did not sit next to: how you shared work for asynchronous feedback, documented hand-offs to developers or ran remote research sessions. That is direct evidence of the skill a distributed team is hiring for.

Writers: short, targeted samples with context

The Write the Docs hiring guide, aimed at technical writers, points out that reviewers rarely read long documents in full and recommends sharing the sections that best show your skills rather than entire manuals. The same thinking works for content writers, copywriters and editors.

• Choose two to four samples that match the role: a how-to guide for documentation work, a long-form article for content roles, before-and-after edits for editing roles.
• Add a short note above each sample covering the audience, the brief, what you owned and who reviewed it.
• If others edited a published piece, say so and describe your part.
• Link to live pages where you can, with a note that the published version may have changed since you worked on it.

If you cannot share anything from past jobs, write new samples. The Write the Docs guide suggests ideas such as documenting a tool you already use. A clear setup guide for a popular open-source tool, or a plain-English rewrite of a confusing public form, can be more persuasive than a vague piece you are not allowed to explain.

Support, operations and coordination roles: written case studies

Customer support, operations, project coordination and virtual assistant roles have no strong portfolio tradition, which is exactly why a short written case study stands out. Aim for one or two pages per case, in plain language, with this structure:

1. Situation: the team, the tools and the problem, described without naming the client or any customers.
2. Actions: the steps you took, the process you changed or the document you created.
3. Result: what changed, described honestly. Use numbers only if you can stand behind them, and label estimates as estimates.
4. Supporting material: a redacted template, a sample help-centre article, a process checklist or a reply you wrote fresh for the portfolio.

For support roles, a sample reply to a difficult but fictional customer message is useful because it shows tone, clarity and judgement in one page. For operations roles, a one-page standard operating procedure or an anonymised before-and-after of a workflow works well. Both are easy for a hiring manager to read in a spare five minutes.

Handling client work, NDAs and personal data

Much of people's best work is covered by a non-disclosure agreement, an employment contract or a client's confidentiality rules, and work produced for an employer or client is usually not yours to publish. The Write the Docs guide advises getting explicit written permission from someone with authority before using work material, and following any conditions they set, such as removing branding or sensitive details.

An article on sharing NDA-protected UX work from Smart Interface Design Patterns, a UX training site, makes a related point from a designer's angle: signing an NDA does not necessarily mean you can show nothing, but the exact terms matter. You can often describe your role, your process and your decisions even when the deliverables, client names and findings must stay private.

• Read the actual wording of your NDA or contract before deciding what is safe to show. Some restrictions expire and many do not.
• When unsure, ask the client or your former manager in writing and keep their reply.
• Remove client names, logos, internal links, unreleased features, financial figures and anything that identifies customers.
• Prefer recreated or generic versions: rebuild a screen in neutral styling, rewrite a document for a fictional product, or describe your process without the deliverable.
• Say plainly when a project is under NDA, and focus on your role and methods instead of filling the gap with made-up numbers.

Be especially careful with customer information in screenshots, support tickets and datasets. The UK Information Commissioner's Office explains that a person can be identified indirectly when details are combined with other available information, and that data with names removed but still traceable to a person remains personal data. In practice, blurring a customer's name is not enough if the screenshot still shows an order number, a city and a date. When in doubt, recreate the example with invented data.

Putting it together and keeping it current

• Host your portfolio somewhere you control and can update easily, such as your GitHub profile, a simple personal site or a single well-organised PDF.
• Link it from your resume and your LinkedIn profile, which lets you add media samples of your work, using the same name and headline so reviewers know they have the right person. Our guide to writing a resume for remote jobs covers where portfolio links fit on the resume itself and in a short cover note.
• Check every link and demo before each round of applications. A broken demo does more harm than no demo.
• Save drafts, screenshots and notes from current projects, within the limits of your agreements, so future case studies are easier to write.
• Ask someone in your field to look at it for five minutes and tell you what they remember. If it is not the thing you wanted them to remember, adjust the order.

A portfolio is never finished. Revisit it whenever you complete a meaningful project, and retire older pieces that no longer reflect the work you want to be hired for.