How to Prepare for a Bioinformatics Interview

Answer: A bioinformatics interview is not one assessment. It is usually four: a screening conversation about your CV, a data-handling or coding test, a deep-dive on one project you claim, and a biology sanity check. Each tests something different, so preparing for all four as if they were one exam is why good candidates get caught out.
Most students prepare by revising algorithms. Then the test hands them a FASTA file with a broken record in it, the interviewer asks why they chose that force field, and nothing they revised is relevant. The problem is not effort. It is aiming at the wrong target.
This guide splits the process into the four assessments, says what each one is listening for, and walks through a parsing task exactly as an interviewer would score it, including the malformed record that separates a passing answer from a failing one. If your CV is not yet built as an evidence document, start with how to write a bioinformatics CV as a student, because assessment one is simply that document read out loud back at you.
Contents
- What are you actually being assessed on?
- How do you prepare for the screening call about your CV?
- What does a bioinformatics coding test actually ask?
- Worked example: a parsing task, scored
- How do you handle the project deep-dive?
- What is the biology sanity check?
- What should you practise beforehand?
- Troubleshooting: the common ways candidates lose it
- Frequently asked questions
What are you actually being assessed on in a bioinformatics interview?
Four different things, usually by different people, and often on the same day.
There is no single published description of how every employer or admissions panel runs this, and any page that tells you “the typical process has N rounds” is guessing. What does exist is a documented account of what the field considers competence. The International Society for Computational Biology’s Education Committee published its bioinformatics core competencies in PLOS Computational Biology: The development and application of bioinformatics core competencies to improve bioinformatics training and education (Mulder et al., 2018). Its Table 1 lists 16 core competencies, labelled A to P, built from surveys of employers and training programmes and then refined through community engagement.
Read that list and the four assessments explain themselves. Competencies A to D are biology and the scientific discovery process. F, I and J are tools, web-based skills, and command line and scripting. N is “effective communication of bioinformatics and genomics problem/issue/topics with a range of audiences”. An interview is a short, cheap way to sample those groups separately, because a candidate can be strong in one and empty in another.
| Assessment | What is being tested | What the interviewer listens for | How to prepare | Most common way candidates lose it |
|---|---|---|---|---|
| Screening call on the CV | Whether your claims survive one follow-up question | Specifics: tool, version, dataset, your part of the work | Take each CV line and write the follow-up question you would dread | Claiming a tool used once in a tutorial |
| Coding or data-handling test | Whether you can get a real file into a usable state | Edge cases, sanity checks, readable code | Parse each common format from scratch once, deliberately on broken input | Revising algorithm puzzles instead of file formats |
| Project deep-dive | Depth on one project, and honesty at the limit | Why you chose each parameter, and what you would do differently | Rehearse the reasoning, not the result | Bluffing past the point of knowledge |
| Biology sanity check | Whether a number means anything to you | An answer that is biologically possible | Re-derive what your own numbers imply about the molecule | Quoting an output with no physical meaning attached |
The order varies and the four often blur into one conversation. That does not change the preparation, because each still has to be prepared for separately.
How do you prepare for the screening call about your CV?
By assuming every line gets exactly one follow-up question, and writing that question yourself first.
This is the direct payoff of treating the CV as an evidence document. If a line points at a repository, an accession, a DOI or a certificate, the follow-up question has an answer you can give in one breath. If it does not, the follow-up exposes it immediately.
Here is one line pushed through three questions, which is roughly as far as a screening call goes before moving on.
CV line: “Performed molecular docking of phytochemicals against a bacterial target using AutoDock Vina.”
- Q1: which target, and where did the structure come from? A weak answer names the protein and stops. A strong answer gives the PDB ID, says whether the structure was crystallographic or predicted, and mentions what was removed before docking, such as crystallographic waters or a co-crystallised ligand.
- Q2: how did you set the search box? This is the question that separates a run from an understanding, because the box is where most student docking goes wrong. A strong answer says how the centre was chosen, whether it was defined from a bound ligand or a predicted pocket, and what the dimensions were.
- Q3: how do you know the result means anything? The honest answer is usually about reproducibility and controls: re-docking the native ligand, checking that repeated runs converge, and knowing that a score is a ranking device rather than a measured affinity.
If you cannot answer Q2 for a project on your CV, the project is not interview-ready, and the fix is to go back and run it properly rather than to memorise an answer. Our walkthroughs of how to set the AutoDock Vina grid box and how to interpret docking results cover the reasoning those two questions are testing.
Want the guided, hands-on version?
Our live Molecular Modeling & MD Simulations cohort bootcamp takes you from zero to running real docking and MD workflows, with a portfolio project for your grad-school applications.
What does a bioinformatics coding test actually ask?
Usually: read this file, count something per record, and tell me what you would check first.
Algorithm trivia appears in some software-engineering roles, but the everyday work of the field is reading, validating and reshaping structured text files, which is competency J in the ISCB list, command line and scripting skills appropriate to the discipline. A test built from real work therefore hands you a file. The formats are a short, closed list, and their specifications are public.
| Format | What it holds | One-line sanity check before you compute anything |
|---|---|---|
| FASTA | Sequences with a header line each | Count headers, then check no sequence is empty and no record has characters outside the expected alphabet |
| FASTQ | Reads with per-base quality | Check the sequence and quality strings are the same length in every record |
| VCF | Variants against a reference | Read the header lines starting with ##, confirm the sample columns are the ones you think they are |
| GFF/GTF | Genome annotation features | Confirm coordinates are 1-based and inclusive, and that start is never greater than end |
| BED | Genomic intervals | Confirm coordinates are 0-based half-open, which is the opposite convention to GFF |
| SAM/BAM | Aligned reads | Check the header, then whether records are sorted, before trusting any downstream count |
Two of those rows are worth memorising as a pair, because mixing them up is a real and silent error: GFF and GTF coordinates are 1-based and inclusive, while BED is 0-based and half-open. The hts-specs repository holds the authoritative SAM/BAM and VCF specifications, and the FASTQ variants are described in Cock et al. (2010), “The Sanger FASTQ file format for sequences with quality scores, and the Solexa/Illumina FASTQ variants”. Saying “I would check the spec” and naming where the spec lives is a better answer than guessing a field order.
You are allowed to use libraries in most tests, and Biopython is standard. Ask which is permitted before you start. If the test explicitly says no libraries, it is asking whether you understand the format, not whether you can memorise an API.
Worked example: a parsing task, scored the way an interviewer scores it
The task: report GC content per record for a FASTA file. Four candidates write four answers.
The failing answer reads the whole file, counts G and C across everything, and divides by the total number of characters. It has counted header lines as sequence, ignored record boundaries, and answered a different question from the one asked.
The barely passing answer splits on “>” and computes per record. It works on clean input, which is the only input it was tested against.
The passing answer handles the cases that real files contain. Sequences wrapped over several lines. Lowercase bases. Blank lines. Ambiguity codes such as N, which must be excluded from the denominator rather than silently counted as not-GC. An empty record. This is a compact version of that answer.
import sys
def read_fasta(path):
header, chunks = None, []
with open(path) as fh:
for n, line in enumerate(fh, 1):
line = line.strip()
if not line:
continue
if line.startswith(">"):
if header is not None:
yield header, "".join(chunks)
header, chunks = line[1:].split()[0], []
elif header is None:
sys.exit(f"line {n}: sequence before any header")
else:
chunks.append(line.upper())
if header is not None:
yield header, "".join(chunks)
for name, seq in read_fasta(sys.argv[1]):
acgt = sum(seq.count(b) for b in "ACGT")
if acgt == 0:
print(f"{name}\tNA\tlength={len(seq)}", file=sys.stderr)
continue
gc = (seq.count("G") + seq.count("C")) / acgt
print(f"{name}\t{gc:.3f}\tlength={len(seq)}")
Run against a small test file containing a wrapped record, a lowercase record with two N bases, an empty record and a record with Windows line endings, it prints:
seq1 0.600 length=10
seq2 0.333 length=8
seq4 1.000 length=4
with seq3 NA length=0 going to standard error rather than into the results. Two details are doing the work there. The seq2 value is computed over the six unambiguous bases and not over all eight characters, so the N bases do not quietly deflate the result. The empty record is reported rather than skipped, because a record that disappears without a message is the failure mode that costs someone a week downstream.
The answer that gets the offer is the passing answer plus one sentence spoken out loud: what happens on input the task did not mention. Feed the same script a file whose first line is stray sequence with no header and it stops with line 1: sequence before any header and a non-zero exit status, instead of attributing that sequence to the next record. Saying “I made it fail loudly here, because silently guessing would corrupt the count” is the whole assessment in one line.
Notice what is not being tested: clever code. If you need the mechanics first, our tutorials on fetching sequences from UniProt and handling analysis output in Python cover the everyday file work this draws on.
How do you handle the project deep-dive?
By rehearsing the reasoning rather than the result, and by planning how you will say “I do not know”.
The interviewer picks one project from your CV and pushes until you reach the edge of what you understand. Reaching that edge is expected. What is being assessed is what you do at it. The PLOS Computational Biology editorial Ten simple rules for giving an effective academic job talk puts the standard plainly in its Rule 9, on the question session: “one cardinal rule is to never bluff. If you don’t know the answer, you can say so, but then show how you would think through the question, or relate it to something you have done or know about.”
That is the difference between the two versions of the same admission.
- Badly: “I did not do that part, my supervisor handled it.” The answer closes the topic and hands away ownership of your own project.
- Well: “I have not tested that. My guess is it would change the binding site definition rather than the ranking, and I would check it by re-docking the native ligand with the same box and seeing whether the pose still reproduces. If it did not, my box was wrong.”
The second answer contains no more knowledge than the first. It contains a method. The same editorial suggests paraphrasing a question before answering it, which buys you a moment and confirms you understood what was asked.
If your project is an immunoinformatics pipeline, expect the deep-dive to follow the chain rather than a single step, so know the joins: why those epitopes survived antigenicity, allergenicity and toxicity screening, why the linkers and adjuvant sit in that order in the assembled construct, and what the model quality metrics did or did not tell you in structure prediction and validation. The full chain is laid out in our immunoinformatics pillar guide.
What is the biology sanity check, and how do you fail it?
It is the moment someone asks what your number means for the molecule, and it is the fastest rejection in a computational interview.
Competencies A and B in the ISCB list are general biology and depth in at least one area of biology, and they sit above the tool competencies for a reason. A candidate who reports an RMSD value without being able to say whether it indicates a stable trajectory or a structure falling apart has produced a number, not a result. A candidate who reports a docking score in kcal/mol and calls it a measured binding affinity has misunderstood what the software returns.
Practical preparation: take every number in your own project and write one sentence on what it implies physically. A pI below the buffer pH means the protein carries net negative charge in that buffer. An instability index above 40 classifies a protein as unstable in the test tube, which our guide to ProtParam characterisation covers with the caveats attached. A low per-residue confidence score across a linker region in a chimeric model is the expected result for a flexible linker, not a broken model. If you cannot write that sentence, you do not yet own the number.
What should you practise before the interview?
Three things, in this order.
- Your own projects, out loud. Everything on your CV, with the follow-up questions written first. Nothing you practise afterwards matters as much, because your projects are where three of the four assessments actually happen.
- Parsing, on deliberately broken input. Write the FASTA and FASTQ readers from scratch once, without a library, then corrupt your own test file: truncate a record, mismatch a quality string, add an empty sequence, save it with Windows line endings. Rosalind is a free platform of bioinformatics problems that are checked automatically, which makes it a reasonable place to drill this.
- The vocabulary of the role you applied for. A structural role and a genomics role test different things. If you are unsure which the posting is, our guide to bioinformatics career paths and job roles maps the families, and the skills you actually need covers what each expects. EMBL-EBI Training is a credible free source for the genomics and data-resource side.
If you want a checkable result from that practice rather than just a feeling of readiness, our free assessments and certificates are free to take and free to certify, with a pass mark of 70% and a certificate URL you can put straight on the CV that starts this whole process. Where those fit alongside everything else is covered in the computational biology skills roadmap.
Troubleshooting: the common ways candidates lose it
- The tool list with nothing behind it. A CV naming eight tools invites a question about the one you know least. Cut anything you cannot defend, as covered in building a portfolio that proves the claim.
- Revising algorithm puzzles for a file-handling test. Useful for some software roles, irrelevant to most bioinformatics tests. Ask the recruiter what the test covers; that question is normal and is not held against you.
- Answering a broken-input question with “that would not happen”. It happens constantly. The expected answer describes what your code does when it does.
- Producing a number with no biological meaning attached. Practise the one-sentence implication for every number you report.
- Bluffing. The interviewer usually knows the answer already. An invented one ends the interview quietly, and you will not be told that is what happened.
- Treating the questions you ask as a formality. Asking what data the team works with, or how analyses get reviewed, shows you are evaluating the role rather than hoping to be chosen.
Written by the StemSkills Lab team, which has spent more than ten years in sequence and structural bioinformatics, drug discovery and design, and multiscale molecular modeling, and has sat on both sides of these conversations.
Frequently asked questions
Do I need to know data structures and algorithms for a bioinformatics interview?
For a research or analysis role, a working understanding matters far less than file handling, statistics and the biology. For a bioinformatics software-engineering role in a company, algorithms and software design may be tested directly. Ask which kind of role it is before you decide what to revise.
Can I use Biopython, pandas or an AI assistant during the coding test?
Ask. Library use is often allowed and sometimes expected, and asking is treated as a sensible question rather than a weakness. Rules on AI assistants vary and are usually stated up front. Using one when it has been ruled out is a straightforward integrity problem, so clarify first.
What if I am asked about a tool that is on my CV but I have only used once?
Say so precisely: what you ran, on what data, and what you did not do. That answer costs you nothing. Claiming more and then failing a follow-up question costs you the interview and casts doubt on every other line.
How do I prepare for the deep-dive if my only project is a course assignment?
Depth beats novelty. One assignment you can defend line by line, including its limitations, interviews better than three you ran once. If you need a project with more to defend, our project ideas for MSc students are scoped to be finishable and reproducible.
Is a PhD interview different from a job interview?
The four assessments are similar, but the weighting moves. A selection panel puts more on the project deep-dive and on your reasons for the research direction, and often includes a presentation. Our guide to applying for a bioinformatics PhD covers the application side, and an internship is the cheapest way to have something real to be questioned on.
Want the guided, hands-on version?
Our live Molecular Modeling & MD Simulations cohort bootcamp takes you from zero to running real docking and MD workflows, with a portfolio project for your grad-school applications.
