For remote developer roles, your portfolio does much of the talking before anyone meets you. Reviewers have limited time, so a few focused, well-explained projects beat a long list of tutorials. This article covers which projects to show, how to write a README people read, and how to present your GitHub.
What reviewers look for
A hiring manager or engineer reviewing your portfolio usually spends a few minutes per candidate. In that time they try to answer three questions: Can this person build something that works? Do they make sensible decisions? Can they explain their work in writing? The last one matters especially for remote teams, which run on written communication – see our guide to remote tech jobs in Canada.
Choosing projects
Two or three strong projects are enough. Good candidates:
- A project that solves a real problem – for you, a club, a small business. Real constraints lead to real decisions.
- A project in the stack of the jobs you want. Applying for back-end roles? Show an API with tests, not only a front-end.
- Something deployed that a reviewer can open in a browser, even if small.
- A contribution to an existing codebase, such as an open source pull request, which shows you can work in someone else’s code.
What to avoid: unmodified tutorial projects, many half-finished repositories, and projects you can’t explain in the interview.
A README that gets read
The README is where most reviewers decide whether to look further. Keep it short and structured:
The “why” section is the one most candidates skip, and the one reviewers remember. One or two sentences like “I used SQLite instead of Postgres because the app is single-user; I’d switch if it needed concurrent writes” show judgment in a way code alone can’t.
Signals in the code itself
- Tests for the important parts, runnable with one command.
- Consistent formatting through a formatter or linter.
- Meaningful commit history – small commits with clear messages, not one “final version” commit.
- No secrets: API keys and passwords belong in environment variables, never in the repository.
- A licence and a .gitignore, small details that show care.
Presenting your GitHub
- Pin your best two to four repositories.
- Add a short profile README: what you work on, the stack, your time zone and how to reach you.
- Archive or make private old experiments that don’t represent your current level.
- Link the portfolio from your resume header and LinkedIn – see applying for remote jobs for resume structure.
Tip: For each project, prepare a two-minute spoken explanation: the problem, your design, a mistake you made and what you’d change. It’s the most common follow-up question in interviews.
Portfolios and take-home tasks
Some companies let you submit a portfolio project instead of a take-home assignment; ask if the process allows it. If you do a take-home, treat it like a portfolio piece: clear README, tests, and a note on trade-offs and what you’d do with more time. Keep to the suggested time limit and say so.
Be careful with unsolicited “coding tests”. Fake recruiters have sent developers repositories that install malware when run. Check the recruiter and company first, and run unknown code only in an isolated environment – more in how to check if a recruiter is real.
Common questions
How many projects should my portfolio have?
Two to four strong, well-explained projects are better than many small ones. Pin them at the top of your GitHub profile.
Does a portfolio replace work experience?
Not entirely, but for junior roles and career changers it’s often the main evidence of skill. Combine it with any relevant experience, even outside tech.
Should I include group projects?
Yes, if you explain clearly which part you built. Reviewers want to know what you did, not what the team did.
More on this topic: our guide Remote Tech Jobs in Canada: Developer, IT and Data Careers puts this article in context.
