Before you start
- You have done at least one project-style lesson on this site (a Track 1, 2, or 3 deliverable is perfect raw material).
- You have a GitHub account and know the basics of pushing code. New? Do Git & GitHub for scientists first.
- Any term new? The Glossary has it.
Learning objectives
By the end of this lesson you will be able to: judge what makes a bioinformatics portfolio strong, turn your existing analyses into a few polished and reproducible GitHub projects, and present them with clear READMEs so hiring managers can see what you can do.
Why a portfolio beats a resume (especially for career-switchers)
A resume claims you can do things. A portfolio shows it. For someone moving in from the bench, the clinic, or another field, that difference is everything: you may not have the job title yet, but you can have the evidence. A hiring manager looking at a clean, well-documented analysis on your GitHub learns more in two minutes than a page of bullet points could tell them. Your public repositories become your real CV.
And the work you have already done on this site, the FASTQ analysis, the RNA-seq walkthrough, the misleading-figure critique, is exactly the raw material. This lesson is about turning those into portfolio pieces.
Quality over quantity: three great projects, not thirty
The single most common mistake is a GitHub full of half-finished tutorials and abandoned forks. That signals dabbling, not capability. Far better: three to five complete, polished projects, each with a clear question, a clean repository, and a result someone can actually reproduce. One excellent project outweighs twenty graveyards.
A strong portfolio usually mixes a few of these project types:
| Project type | What it shows |
|---|---|
| Reanalysis of public data | You can take real data (GEO, SRA, TCGA) and run a complete, correct analysis end to end |
| A small tool or script | You can write reusable, documented code that solves a real problem |
| A tutorial or explainer | You understand a topic deeply enough to teach it, and you communicate well |
| An open-source contribution | You can read someone else's codebase and collaborate, exactly what a job is |
As a career-switcher, your old field is an advantage here. A pharmacist who reanalyzes a drug-response dataset, or a clinician who works with patient-derived expression data, brings domain insight a pure programmer does not. Lean into that overlap.
Anatomy of a project repository that impresses
Open any of your project repos and a reviewer should be able to understand it in under a minute. That requires structure:
- A great README. This is the most important file in the entire repo, and the one beginners neglect most. It should state the question, show a key result or figure, and give the exact steps to reproduce it. If someone reads only the README, they should still get the whole story.
- Reproducibility built in. Commit an
environment.yml(see the Conda lesson) so anyone can recreate your software setup. A project that only runs on your laptop is not finished. - Clean, commented code. Sensible file names, a logical folder layout (data, scripts, results), and comments that explain why, not just what.
- Visible results. Include the key figures or a short results write-up in the repo, so a reviewer sees the payoff without running anything.
- No secrets or huge data dumps. Use a
.gitignore; link to where the public data lives rather than committing gigabytes.
Decode the jargonREADME
The front page of a repository (a README.md file in Markdown) that GitHub displays automatically. It is your project's elevator pitch: what it does, why, a result, and how to run it. A strong README is often the difference between a repo that gets read and one that gets skipped.
Show your reasoning, not just your code
Code shows what you did; employers also want to see how you think. A computational notebook (Jupyter or R Markdown) that walks through your analysis, with short narrative explaining each decision and interpreting each result, is far more compelling than a bare script. It demonstrates judgment: why you filtered the way you did, what a plot means, what you would do next. The misleading-figure critique from Track 5 is a perfect small example of visible reasoning.
Make the profile itself work for you
A little presentation goes a long way:
- Pin your best 3 to 6 repos on your GitHub profile so they appear first.
- Add a profile README (a repo named the same as your username) introducing who you are, your background, and what you are working toward. For a career-switcher this is where you frame the transition as a strength.
- Write real repo descriptions and add topics/tags so projects are findable.
- Keep a light online presence (LinkedIn, and optionally a short blog) that links back to the work. Being able to point to public, reproducible analyses is what turns "I'm learning bioinformatics" into "here is bioinformatics I have done."
⚠️ Polish the ones you show
An unpinned experiment can be rough, that is fine. But every pinned project is a sample of your professional work, so it must run, have a real README, and be reproducible. One broken flagship repo undoes the credibility of five good ones. Curate ruthlessly.
🛠️ Your deliverable: ship one portfolio-grade repo
Take one project you have done here (a Track 1/2/3 deliverable, or the Track 5 figure critique) and bring it to portfolio standard:
1. Write a README that states the question, shows one key figure, and lists the steps to reproduce.
2. Add an environment.yml and a .gitignore.
3. Turn the analysis into a narrated notebook that explains your reasoning.
4. Pin it on your profile and write a one-line description.
Do this for three projects over time and you have a portfolio. See Git & GitHub for scientists for the hosting mechanics.
Check your understanding
Sources & further reading
- Perez-Riverol Y, et al. Ten Simple Rules for Taking Advantage of Git and GitHub. PLOS Computational Biology 12(7): e1004947, 2016. doi:10.1371/journal.pcbi.1004947
- Way GP, et al. A field guide to cultivating computational biology. PLOS Biology 19(10): e3001419, 2021. doi:10.1371/journal.pbio.3001419
- Ziemann M, Poulain P, Bora A. The five pillars of computational reproducibility: bioinformatics and beyond. Briefings in Bioinformatics 24(6), bbad375, 2023. doi:10.1093/bib/bbad375
- GitHub Docs: Managing your profile README. docs.github.com
Last reviewed: June 2026.