All outcomes
Skills

Bioinformatics Analysis Pipeline

8 weeks · 0 milestones

Conduct a real bioinformatics analysis on a named publicly available genomic dataset from NCBI, Ensembl, or equivalent open repository: sequence alignment using BLAST, multiple sequence alignment (MUSCLE or MAFFT), phylogenetic tree construction (PhyML, IQ-TREE, or equivalent), variant annotation (Ensembl VEP, ClinVar), or RNA-seq differential expression analysis (DESeq2, edgeR). Document the complete methodology: dataset accession numbers, software tools with version numbers, parameters with rationale, and biological interpretation of outputs. The proof is the documented methodology, submitted code or pipeline, output files, and written interpretation of the biological significance of the results. All tools named are free and widely used by professional researchers — bioinformatics is among the most accessible postgraduate-level research skills available. The submitted code must be independently runnable. Reviewed by a geneticist or bioinformatician who examines the parameter choices and asks why specific settings were chosen over alternatives — requiring methodological understanding, not just tool operation.

Milestone map

Milestone map

3 milestones

Define question and select public dataset

1–2 weeks

Choose a specific biological question addressable through computational analysis, select an appropriate public dataset from a free repository, and document your rationale. Accessible alternative: all three milestones of this outcome can use public data — no wet-lab access is required. Real-world bioinformatics is largely computational work on existing sequencing data.

Proof required

Submit a written project proposal (1–2 pages) stating your biological question, the public dataset you have selected (include the NCBI/Ensembl/GBIF accession number or URL), your rationale for choosing it, and the analysis tool or pipeline you plan to use. Confirm the dataset has been downloaded and passes initial quality checks.

What gets checked

  • Biological question is specific and answerable — 'What differentially expressed genes distinguish cancer type A from B in dataset SRX123?' not 'What is interesting in this dataset?'
  • Dataset accession number or stable URL is provided — confirms the data is real and reproducible
  • Tool choice is justified — not just 'I will use Python' but which library or workflow (e.g., DESeq2, STAR, BLAST, QIIME2) and why it is appropriate for this question

Common mistakes

  • Choosing a vague question that can't be falsified computationally — a good bioinformatics question has a clear expected output that either supports or refutes a specific hypothesis
  • Selecting a dataset without checking its quality or metadata completeness — poor-quality sequencing data (low coverage, inadequate metadata, incomplete conditions) makes analysis impossible mid-project

Resources

Foundationstart here

Depthgo deeper

Masteryfor the dedicated

What a verifier looks for

  • Ask the submitter to explain their biological question in one sentence and state specifically what they expect the analysis to find — confirms the question is genuinely specific.
  • Ask why they chose this dataset over alternatives — a well-reasoned choice demonstrates dataset literacy beyond just picking the first result.
  • Ask what quality metrics they will check before beginning analysis — FastQC scores, read depth, metadata completeness are expected answers for sequencing data.

Execute pipeline and document QC decisions

2–4 weeks depending on pipeline complexity

Run your analysis pipeline from raw or preprocessed data through to initial results, documenting every quality control decision along the way. The documented QC decisions — not just the output figures — are what distinguish a genuine computational biology project from an AI-generated one.

Proof required

Submit your analysis code or Galaxy workflow, a QC report documenting the decisions made at each step (why reads were trimmed at a specific quality threshold, why a reference genome version was chosen, how outlier samples were handled), and at least one preliminary results figure with an interpretation.

What gets checked

  • QC documentation names specific thresholds and decisions, not just states 'QC was performed'
  • Code or workflow is reproducible — a reviewer should be able to run it on the same dataset and get the same output
  • Preliminary results figure is interpreted in biological terms — not just 'here are the numbers' but what the numbers suggest about the biological question

Common mistakes

  • Treating the pipeline as a black box — running a standard tool without understanding what each step does makes the methodology Q&A in M3 impossible to answer
  • Skipping QC and going straight to results — analyses built on unvalidated data produce findings that collapse under examiner questioning

Resources

Foundationstart here

Depthgo deeper

Masteryfor the dedicated

What a verifier looks for

  • Ask the submitter to explain their most important QC decision — what would have happened to their analysis if they had not made it — confirms they understand the pipeline, not just ran it.
  • Ask what they would do differently if they reran the analysis — a genuinely engaged analyst can always name something.
  • Check that QC metrics are specific numbers, not vague descriptions — 'mean Q30 score of 92% across all samples' is a QC decision; 'quality was good' is not.

Present findings with methodology Q&A

2–3 weeks to write up and schedule review

Present your completed analysis to a bioinformatician or computational biologist who will ask methodological follow-up questions. The documented Q&A session is the proof standard that distinguishes genuine computational reasoning from AI-generated output — an informed reviewer will present scenarios you cannot have anticipated.

Proof required

Submit your final analysis write-up (methods, results, interpretation, limitations — 3–5 pages) and a written record of your Q&A session with the reviewer: the specific questions they asked about your methodological choices and your responses. The reviewer must be named and their relevant background stated.

What gets checked

  • Write-up covers methods in sufficient detail to reproduce the analysis — tool versions, parameter choices, dataset accession numbers all stated
  • Q&A record shows at least three specific methodological challenges from the reviewer (not softball questions) and substantive responses from the submitter
  • Reviewer is named and their relevant background is stated — 'a friend who does biology' is not sufficient; a bioinformatician, computational biologist, or genomics researcher is required

Common mistakes

  • Asking the reviewer only to confirm conclusions rather than challenge methodology — the Q&A must include at least one moment where the reviewer said 'why did you do it that way rather than X?' and the submitter explained
  • A write-up that describes results without explaining analytical choices — reviewers need the rationale, not just the output

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

  • Ask the submitter what the reviewer's hardest question was and how they answered it — someone who went through a genuine Q&A can recall this clearly.
  • Ask whether any reviewer question revealed a limitation or gap in the analysis they had not previously considered — an honest yes indicates a genuine exchange.
  • Verify the reviewer's relevant background is stated — bioinformatics, computational biology, genomics, or closely related fields only; general biology is insufficient for a methodological Q&A on a computational analysis.

We use analytics to improve Powstik. No ads, ever.