How to Build a Bioinformatics Portfolio as a Student: Projects, Code and Proof of Skill

Build a bioinformatics portfolio by publishing three or four small projects as public repositories, each with the code, the data accession numbers, pinned software versions and a README that states the result and its limits. A project counts when someone who has never met you can clone it and reproduce your numbers.

You have no job history and no publications. A supervisor reading your application has about five minutes and no reason to believe anything you assert about yourself. A portfolio is how you replace assertion with evidence: three or four projects a stranger can download, run and check.

What is a bioinformatics portfolio, and what makes one count?

A bioinformatics portfolio is a small set of public repositories, each containing the code, the input data or its accession numbers, and a README that lets a reader reproduce your result on their own machine. It counts when someone who has never met you can run it end to end and get the same numbers you reported.

That last sentence is the whole test. A screenshot of a docked pose proves nothing, because a screenshot can come from anywhere. A repository with a script, a parameter file and an accession number proves that you ran the analysis, understood the parameters, and were willing to have the work checked. Reviewers know the difference immediately.

This matters more in computational biology than in most fields, because the training gap is real and documented. Wilson and colleagues open Good enough practices in scientific computing (PLOS Computational Biology, 2017) with the observation that “most researchers are never taught the equivalent of basic lab skills for research computing”. A student who has taught themselves those skills, and can show it, stands out against a pile of applications that all list the same coursework.

How many projects do you need, and how big should each one be?

Three to four finished projects beat ten abandoned ones. A finished project is one where the README is written, the code runs from a clean checkout, and the result is stated plainly. An abandoned project is a folder of notebooks with cell outputs from six months ago and no way to tell which version produced which figure.

Size each project so you can finish it in two to four weekends. If you are also planning a dissertation, keep the two separate: the dissertation is graded on scientific contribution, the portfolio is graded on whether a stranger can reproduce it, and those are different jobs. Our guide to the computational biology skills roadmap sets out the order in which the underlying skills are worth learning.

Which projects should you actually build?

Pick projects that show different skills rather than the same skill three times. Four docking studies prove you can run one program. A pipeline, a structural workflow, a data-analysis project and a small tool prove you can work across a stack.

If immunoinformatics is your area, the workflow splits cleanly into portfolio-sized pieces. Predicting B-cell epitopes with BepiPred and ABCpred is one project. Predicting T-cell epitopes and MHC binding with NetMHCpan and IEDB is a second. Designing a multi-epitope construct with linkers and an adjuvant, screening it for antigenicity, allergenicity and toxicity, and docking the finished construct against TLR4 give you three more. Each is small, each has a defined output, and together they read as one coherent line of work. The immunoinformatics pillar has the full sequence.

Where do you get real data for a portfolio project?

From the public archives, using an accession number you record in the README. The scale is not the limitation. Checked on 25 August 2026, NCBI GEO held 294,073 GSE series, the Sequence Read Archive held 46,167,297 records, and the RCSB Protein Data Bank held 258,616 released structures.

The gap between data and interpretation is where a student project can say something. On the same date, UniProtKB reported 149,810,139 entries of which 575,503 were reviewed Swiss-Prot records, under 0.4 percent. Almost everything in the protein universe is machine-annotated and unverified. A careful project on a small, well-chosen slice of that is a genuine contribution, and it is honest about its scope.

Two rules protect you here. Record the accession, the download date and the exact query, because archives are versioned and a rerun in six months will not match otherwise. And never commit large raw files to a repository. Commit the script that fetches them.

How should you structure a bioinformatics project repository?

Use a layout a reader recognises on sight. The Wilson 2017 paper gives one and it is worth copying verbatim: put “all documents associated with the project in the doc directory”, “raw data and metadata in a data directory and files generated during cleanup and analysis in a results directory”, “project source code in the src directory”, and “external scripts or compiled programs in the bin directory”.

Applied to a docking project, that becomes:

• data/ for the receptor and ligand inputs, plus a text file listing the PDB and UniProt accessions with their retrieval dates
• src/ for the preparation and analysis scripts, in the order they run
• results/ for the output poses, score tables and figures
• doc/ for your notes on parameter choices and anything that surprised you
• README.md at the top level
• environment.yml or requirements.txt pinning tool versions
• LICENSE

Name files for their content, keep the numbering consistent, and resist the urge to invent a clever directory scheme. The reader is spending four minutes on your repository. Familiar beats original.

What should the README contain?

Write the README for a human being who has never seen the project. Six sections cover it:

1. What this project does, in two sentences, including the biological question.
2. The data: accession numbers, the archive they came from, the date you retrieved them.
3. How to run it: the actual commands, in order, that a reader types after cloning.
4. Software versions: every tool with its version string, because a docking score is meaningless without the program that produced it.
5. What the result was, stated as a number or a short table, not as an adjective.
6. Limitations: what the analysis does not show. This section is the one that impresses reviewers and the one students always skip.

Wilson and colleagues make the audience point explicitly: “If the audience is humans, write the metadata (the README file) for humans.”

How do you make the project reproducible rather than just public?

Public means the files are visible. Reproducible means the result comes back. The gap between them is version pinning and recorded commands.

Sandve and colleagues set the floor in Ten Simple Rules for Reproducible Computational Research (PLOS Computational Biology, 2013): “As a minimum, you should at least record sufficient details on programs, parameters, and manual procedures to allow yourself, in a year or so, to approximately reproduce the results.” Their second rule is blunter still, and it is the one that breaks student projects: avoid manual data manipulation steps. Every time you open a file and edit it by hand, you create a step nobody can repeat, including you.

Practical version for a student repository:

• Put every step in a shell script or a workflow file, even the trivial ones. A four-line script beats a four-line note.
• Pin versions in an environment file. Bioconda covers most command-line bioinformatics tools and Bioconductor covers the R side.
• Set a random seed anywhere a method samples, and say in the README what it was.
• Add one worked example with a tiny input, so a reader can confirm the code runs before committing to the full dataset.
• Add a LICENSE. Without one, nobody may legally reuse your code. choosealicense.com takes about a minute.

If you want the project to be citable in an application, archive a release. GitHub’s own documentation describes the route: “You can use the data archiving tool Zenodo to archive a repository on GitHub and issue a DOI for the archive.” See Referencing and citing content, and note the constraint stated on the same page, that Zenodo can only access public repositories. A DOI on a student project is a small thing that reads as serious.

Which claims should you leave out of a portfolio?

Anything you cannot show. This is where portfolios lose credibility fastest, and the failures are predictable:

• Do not call a predicted result validated. A docking score, an antigenicity score and an MD trajectory are predictions. Validation means an experiment. Say “predicted” and you look careful; say “validated” and an examiner who works in the field stops reading.
• Do not quote a number you cannot source. No invented accuracy figures, no benchmark you did not run, no statistic without a citation.
• Do not claim a tool does something its own documentation disclaims. Several docking servers state plainly that their scores are not calibrated binding affinities. Repeating that caveat in your README is a credibility signal, not a weakness.
• Do not list a skill you have used once. If it is on the portfolio, expect to be asked to explain a parameter choice in an interview.
• Do not pad with coursework. A tutorial you followed is not a project. A tutorial you extended, with your own data and your own question, is.

The same discipline applies to how you describe the field on your CV. Mulder and colleagues, writing on bioinformatics core competencies (PLOS Computational Biology, 2018), note that although everyone agrees bioinformatics knowledge is needed, “there is little agreement in the field over what that knowledge entails or how best to provide it”. Vague competency claims land in that gap. Specific, checkable projects do not.

How does a portfolio fit with certifications and a CV?

They do different jobs. A certificate shows you completed a defined syllabus. A portfolio shows what you can do without supervision. Reviewers use the certificate to filter and the portfolio to decide, so you want both, with the portfolio carrying the weight.

If you have neither yet, start with a structured assessment so the first line of the CV exists while you build the repositories. Our free certification track is designed for exactly that starting position. From there, the skills you actually need for a computational biology job maps each skill onto something you can demonstrate, and the guide to bioinformatics career paths and job roles tells you which subset matters for the role you want. Students applying in India should also read how to become a bioinformatician after BSc or MSc.

On the CV itself, give each project one line: what you did, which tools, which data, and the repository link. Reviewers do not read paragraphs about projects. They click.

Frequently asked questions

Do I need publications to get into a bioinformatics PhD?

No. Publications help, but most applicants from BSc or MSc programmes do not have them. A reproducible portfolio and a clear research interest carry an application, because both show the reviewer how you work rather than what you were assigned.

Should my portfolio be on GitHub or somewhere else?

GitHub is the default because reviewers already have accounts and know how to read it. GitLab and Bitbucket work equally well technically. What matters is that the link opens without a login, the README renders, and the repository is public.

Can I use a class assignment as a portfolio project?

Only if you extend it. Rerun it on data you chose, add a question the assignment did not ask, write your own README, and say clearly in that README which part was coursework. Passing off an unmodified assignment as independent work is easy to spot and hard to recover from.

What if my project produced a negative or boring result?

Publish it with the result stated plainly. A repository that reports “no significant enrichment was found” with clean code is stronger evidence of scientific honesty than one reporting a striking result you cannot defend. Reviewers are assessing your method, not your luck.

How long does it take to build a portfolio worth showing?

Three or four projects at two to four weekends each is roughly three to five months of part-time work alongside a degree. The first project takes the longest, because you are learning the repository habits at the same time. The fourth takes a fraction of the first.

Should I include a project that uses a web server rather than code?

Yes, if you record it properly. Many standard workflows run on public servers with no local code at all. Record the server, the version, the exact input file, every non-default parameter and the date you ran it, then commit the inputs and outputs. That is reproducible even without a script.

The work in this guide reflects how the StemSkills Lab team, with more than ten years in sequence and structural bioinformatics, drug discovery and design, and multiscale molecular modeling, assesses student work and prepares students for research positions. Our published research is listed on the research page.