Building a Biostatistics Portfolio Project

Introduction

A strong biostatistics portfolio is more than a collection of statistical tests or attractive plots.

A professional portfolio project should demonstrate that you can take an analytical problem from question to conclusion.

That means showing that you can understand the scientific problem, define an estimand or analysis objective, prepare data appropriately, select a suitable statistical method, implement the analysis, check assumptions, interpret the results, and communicate the findings.

For someone hiring a biostatistician, this workflow is often more informative than a list of software packages on a résumé.

What Is a Biostatistics Portfolio Project?

A biostatistics portfolio project is a self-contained analysis that demonstrates your ability to solve a realistic biomedical, public-health, epidemiological, clinical-trial, or health-services research problem.

A complete project commonly contains:

• A scientific research question
• A description of the study population
• A defined exposure, treatment, or predictor
• One or more outcomes
• A statistical analysis plan
• Data preparation and quality checks
• Statistical modeling
• Tables and figures
• Interpretation
• Reproducible code
• Documentation
• A final report or presentation

The project may use public data, simulated data, or another dataset for which you have appropriate rights to use the information.

What Employers Are Actually Looking For

A portfolio project should demonstrate several dimensions of statistical competence.

What Makes a Project Strong?

The strongest portfolio projects have a coherent narrative.

For example:

A weak portfolio often looks like this:

The second approach may demonstrate programming ability, but it does not necessarily demonstrate biostatistical reasoning.

Choosing a Portfolio Project

A useful project should be complex enough to demonstrate meaningful skills but small enough that you can finish it.

A practical project can often be completed around one primary research question and several secondary objectives.

Good Project Characteristics

• Has a clear biomedical question
• Uses a realistic dataset
• Contains enough observations for meaningful analysis
• Includes both descriptive and inferential analysis
• Requires data preparation
• Allows useful visualizations
• Has identifiable limitations
• Can be explained in five to ten minutes during an interview

Weak Project Characteristics

• Only demonstrates a simple t-test
• Contains dozens of unrelated statistical tests
• Has no scientific question
• Uses a dataset without understanding its structure
• Contains copied code with little explanation
• Reports p-values without effect estimates
• Has no reproducibility documentation
• Cannot be explained without reading the code

Possible Portfolio Project Topics

A Recommended Portfolio Project

For a clinical biostatistics portfolio, one particularly useful project is a simulated randomized clinical trial analysis.

This type of project allows you to demonstrate concepts that appear frequently in clinical-trial work:

• Baseline characteristics
• Treatment-emergent adverse events
• Continuous laboratory endpoints
• Binary response endpoints
• Time-to-event endpoints
• Kaplan-Meier estimation
• Cox regression
• Odds ratios
• Confidence intervals
• Clinical interpretation
• Tables and figures

The dataset does not need to be real patient data. A carefully designed simulated dataset can be an excellent way to demonstrate the complete workflow without creating privacy or data-access concerns.

Define the Research Question

Before opening R, write the research question in one sentence.

For example:

That question immediately suggests the primary endpoint, treatment comparison, analysis population, and statistical framework.

Convert the Question Into an Analysis Framework

A useful framework is:

Write an Analysis Plan Before Coding

A portfolio project becomes substantially more professional when the analysis plan is written before the statistical programming begins.

Your analysis plan does not need to be a 100-page Statistical Analysis Plan.

A two- to five-page document can be sufficient for a portfolio project.

Minimum Analysis Plan

• Study objective
• Analysis population
• Baseline definition
• Primary endpoint
• Secondary endpoints
• Covariates
• Missing-data strategy
• Statistical methods
• Confidence interval convention
• Significance level, if applicable
• Sensitivity analyses
• Planned figures and tables

The Portfolio Project Workflow

Design the Dataset

If public data are unavailable or unsuitable, simulation is an excellent alternative.

A clinical-trial portfolio dataset might contain:

Keep the Dataset Realistic

A simulated dataset should not be perfectly clean.

A realistic portfolio project can include:

• Missing laboratory values
• Unequal treatment-group sizes
• Continuous and categorical variables
• Different follow-up times
• Censored survival observations
• Occasional outliers
• Imbalanced categories

However, simulated problems should be intentional and documented.

Example Project Dataset

Suppose the project contains 240 simulated randomized patients.

The numbers above are illustrative and should be described as simulated if used in the project.

Start With Data Inspection

Before performing any statistical test, inspect the dataset.

In R:

library(tidyverse)

dat <- read_csv("data/analysis_data.csv")

glimpse(dat)

summary(dat)

nrow(dat)

names(dat)

You should understand:

• How many observations exist
• How many variables exist
• Variable types
• Missingness
• Unique treatment values
• Potentially impossible values

Check Treatment Assignment

table(dat$TRT01P, useNA = "ifany")

prop.table(
  table(dat$TRT01P)
)

This basic check can identify unexpected treatment values or missing treatment assignments.

Check Continuous Variables

dat %>%
  summarise(
    n = n(),
    mean_age = mean(AGE, na.rm = TRUE),
    sd_age = sd(AGE, na.rm = TRUE),
    median_age = median(AGE, na.rm = TRUE),
    min_age = min(AGE, na.rm = TRUE),
    max_age = max(AGE, na.rm = TRUE)
  )

Do not assume that a variable is valid simply because R accepts it.

A value such as age = 250 is syntactically valid but clinically implausible for most adult clinical studies.

Define Analysis Populations

A portfolio project should explicitly define which patients are included in each analysis.

For example:

In a real clinical trial, these definitions should follow the protocol and statistical analysis plan. In a portfolio project, state your assumptions clearly.

Descriptive Statistics

The first statistical output should usually describe the study population.

For continuous variables, consider:

• N
• Mean
• Standard deviation
• Median
• Minimum
• Maximum
• Selected percentiles where useful

For categorical variables, consider:

• Count
• Percentage
• Missing category where appropriate

Do Not Turn Baseline Tables Into a Collection of P-Values

A common portfolio mistake is to compare every baseline variable using a p-value.

For a randomized trial, baseline tables are primarily descriptive.

The objective is to understand whether clinically important imbalances exist, not to test whether randomization "worked."

Example Baseline Visualization

Define the Primary Endpoint

A portfolio project should have one clearly identified primary endpoint.

For a time-to-event project:

The exact definition depends on the scientific setting and should be stated explicitly.

Time-to-Event Analysis

Time-to-event data are different from ordinary continuous outcomes because some patients may not experience the event during follow-up.

Those observations are commonly treated as right censored.

A simple representation is:

where \(T_i^*\) is the true event time and \(C_i\) is the censoring time.

The event indicator is:

Kaplan-Meier Analysis

A portfolio project involving survival analysis should generally include a Kaplan-Meier curve.

library(survival)
library(survminer)

fit_km <- survfit(
  Surv(PFS, PFS_EVENT) ~ TRT01P,
  data = dat
)

ggsurvplot(
  fit_km,
  data = dat,
  risk.table = TRUE,
  conf.int = TRUE,
  xlab = "Time from Randomization",
  ylab = "Progression-Free Survival Probability"
)

What to Report From a Kaplan-Meier Analysis

Useful outputs include:

• Number of patients analyzed
• Number of events
• Number censored
• Median survival, if estimable
• Confidence interval for the median
• Survival probabilities at clinically meaningful time points
• Between-group comparison

Do not report only the p-value.

Cox Proportional Hazards Model

The Cox model can estimate the relative instantaneous event rate associated with treatment.

For a binary treatment variable, the exponentiated treatment coefficient is often interpreted as a hazard ratio.

cox_fit <- coxph(
  Surv(PFS, PFS_EVENT) ~ TRT01P + AGE + ECOG,
  data = dat
)

summary(cox_fit)

Interpreting a Hazard Ratio

Suppose the estimated hazard ratio for Treatment A versus Treatment B is:

A common interpretation is that the estimated instantaneous event hazard in the Treatment A group is approximately 28% lower than in the Treatment B group, assuming the proportional-hazards model and coding convention are appropriate.

The interpretation should always include the confidence interval.

Confidence Intervals Matter

Suppose:

The interval communicates both the estimated effect and its uncertainty.

A portfolio project should demonstrate that you understand this distinction.

Check Model Assumptions

A professional project should demonstrate that you understand assumptions.

For a Cox model, one important assumption is proportional hazards.

ph_check <- cox.zph(cox_fit)

print(ph_check)

plot(ph_check)

If the assumption is questionable, discuss the issue and consider an appropriate alternative or sensitivity analysis.

Secondary Endpoint: Objective Response

Suppose objective response is binary:

• Responder
• Non-responder

The response rate can be calculated as:

For example, if 52 of 122 patients respond:

Comparing Response Rates

A portfolio project can demonstrate estimation of risk differences, risk ratios, odds ratios, or model-based adjusted effects.

For example:

response_tab <- table(
  dat$TRT01P,
  dat$RESP
)

response_tab

prop.table(
  response_tab,
  margin = 1
)

Logistic Regression

If response is modeled as a binary endpoint, logistic regression is a natural method.

logit_fit <- glm(
  RESP ~ TRT01P + AGE + ECOG,
  data = dat,
  family = binomial()
)

summary(logit_fit)

exp(cbind(
  OR = coef(logit_fit),
  confint(logit_fit)
))

Why Adjust for Covariates?

Covariate adjustment can improve precision and account for clinically important prognostic factors.

Possible covariates include:

• Age
• Baseline disease severity
• Performance status
• Biomarker status
• Prior treatment
• Disease stage

The covariates should be selected using scientific reasoning and the analysis plan rather than simply choosing variables based on univariable p-values.

Missing Data

Missing data are one of the most important areas in which a portfolio project can demonstrate statistical maturity.

First quantify missingness.

missing_summary <- dat %>%
  summarise(
    across(
      everything(),
      ~sum(is.na(.))
    )
  )

missing_summary

Then ask:

• Which variables are missing?
• How much is missing?
• Is missingness associated with treatment?
• Is missingness associated with outcome?
• Why might the data be missing?
• Does the analysis require an explicit missing-data method?

Do Not Automatically Delete Missing Records

Complete-case analysis is sometimes appropriate, but it should not be treated as the universal solution.

A strong portfolio project should explain why its chosen missing-data approach is reasonable.

Visualization Is Part of the Analysis

A professional project should contain figures that answer specific questions.

Useful examples include:

• Baseline distribution plots
• Boxplots or violin plots
• Response-rate plots
• Kaplan-Meier curves
• Forest plots
• Longitudinal plots
• Diagnostic plots
• ROC curves

Avoid adding a figure simply because you know how to make it.

Example Response-Rate Visualization

Build a Forest Plot

A forest plot is an excellent portfolio figure because it demonstrates estimation, uncertainty, and subgroup interpretation.

A simplified treatment-effect representation is:

For example:

These values are illustrative and should not be interpreted as evidence from a real clinical trial.

Do Not Overinterpret Subgroups

A subgroup confidence interval crossing one does not automatically prove that the treatment has no effect in that subgroup.

Similarly, apparent differences between subgroup estimates do not establish heterogeneity of treatment effect.

If you include subgroup analyses, discuss interaction testing and the limitations of multiple comparisons and reduced sample size.

Create a Statistical Analysis Dataset

A useful portfolio project separates raw or source data from analysis-ready data.

For example:

data/
├── raw/
│   └── trial_source.csv
│
└── analysis/
    └── analysis_dataset.csv

The analysis dataset should contain clearly defined variables that correspond to the statistical analyses.

Separate Data Preparation From Analysis

Avoid putting the entire project into one giant script.

A cleaner structure is:

R/
├── 01_import.R
├── 02_clean_data.R
├── 03_derive_variables.R
├── 04_descriptive_analysis.R
├── 05_primary_analysis.R
├── 06_secondary_analysis.R
├── 07_figures.R
└── 08_qc.R

This structure makes the project easier to review and maintain.

Use Functions for Repeated Tasks

Reusable functions demonstrate programming maturity.

summarize_continuous <- function(x){

  tibble(
    N = sum(!is.na(x)),
    Mean = mean(x, na.rm = TRUE),
    SD = sd(x, na.rm = TRUE),
    Median = median(x, na.rm = TRUE),
    Min = min(x, na.rm = TRUE),
    Max = max(x, na.rm = TRUE)
  )

}

The exact implementation is less important than demonstrating that you can recognize repeated analytical operations and make them reproducible.

Use a Project Configuration File

For larger projects, a configuration file can make assumptions explicit.

analysis_config <- list(

  alpha = 0.05,

  confidence_level = 0.95,

  primary_endpoint = "PFS",

  treatment_variable = "TRT01P",

  event_variable = "PFS_EVENT"

)

This prevents important assumptions from being scattered throughout multiple scripts.

Reproducibility Is a Portfolio Skill

Another statistician should ideally be able to clone your repository and reproduce your results.

A reproducible project should document:

• Required software
• Required R packages
• Input data
• Data preparation steps
• Analysis scripts
• Output locations
• Software versions where relevant

Use a README

The README is often the first thing a recruiter, hiring manager, or statistician will see.

A strong README should answer:

• What is the project?
• What question does it answer?
• What data were used?
• What statistical methods were used?
• What were the major findings?
• How can the analysis be reproduced?

Example README Structure

# Clinical Trial Biostatistics Portfolio Project

## Objective

Evaluate whether Treatment A improves progression-free survival
compared with Treatment B.

## Data

Simulated randomized clinical-trial dataset.

## Methods

- Descriptive statistics
- Kaplan-Meier analysis
- Cox proportional hazards model
- Logistic regression
- Response-rate analysis
- Sensitivity analysis

## Results

Treatment A was associated with longer estimated progression-free
survival in the simulated dataset.

## Reproducibility

Run:

R/01_import.R
R/02_clean_data.R
R/03_derive_variables.R
R/04_descriptive_analysis.R
R/05_primary_analysis.R
R/06_secondary_analysis.R
R/07_figures.R
R/08_qc.R

Recommended GitHub Structure

biostatistics-portfolio/
│
├── README.md
│
├── data/
│   ├── raw/
│   └── analysis/
│
├── R/
│   ├── 01_import.R
│   ├── 02_clean_data.R
│   ├── 03_derive_variables.R
│   ├── 04_descriptive_analysis.R
│   ├── 05_primary_analysis.R
│   ├── 06_secondary_analysis.R
│   ├── 07_figures.R
│   └── 08_qc.R
│
├── output/
│   ├── tables/
│   └── figures/
│
├── report/
│   └── analysis_report.html
│
├── docs/
│   ├── analysis_plan.md
│   └── data_dictionary.md
│
└── renv/
    └── project_environment.lock

Create a Data Dictionary

A data dictionary makes your analysis easier to understand.

Document Derived Variables

Derived variables should be explicitly documented.

For example:

and:

A reviewer should not have to reverse-engineer your definitions from your R code.

Quality Control

Quality control is one of the easiest ways to make a portfolio project look more like professional biostatistical work.

Create independent checks for important results.

Independent QC Example

Suppose your primary analysis reports 122 patients in Treatment A.

Do not simply trust the same programming code that created the table.

Create an independent check:

qc_n_treatment_a <- dat %>%
  filter(TRT01P == "Treatment A") %>%
  distinct(USUBJID) %>%
  nrow()

stopifnot(qc_n_treatment_a == 122)

The exact approach will depend on the project, but the principle is important: critical outputs should be independently verified.

Statistical QC vs. Programming QC

Write the Results Like a Statistician

A portfolio report should distinguish between statistical output and scientific interpretation.

For example, instead of writing:

write:

Then discuss clinical relevance separately.

Separate Statistical Significance From Clinical Importance

Suppose a study estimates:

The result may meet a conventional statistical criterion, but the magnitude of the estimated treatment effect may be modest.

Conversely, a large estimated effect with a very wide confidence interval may be statistically uncertain.

Include Sensitivity Analyses

A single analysis can make a portfolio project look superficial.

A better project asks whether the primary conclusion is robust.

Possible sensitivity analyses include:

• Alternative covariate adjustment
• Alternative endpoint definitions
• Complete-case versus imputation approaches
• Alternative censoring assumptions
• Different follow-up windows
• Alternative model specifications

Example Sensitivity Analysis

Suppose the primary model adjusts for age and ECOG.

cox_primary <- coxph(
  Surv(PFS, PFS_EVENT) ~ TRT01P + AGE + ECOG,
  data = dat
)

cox_sensitivity <- coxph(
  Surv(PFS, PFS_EVENT) ~ TRT01P + AGE + ECOG + BIOMARKER,
  data = dat
)

The purpose is not to search for the model that gives the most favorable result.

The purpose is to evaluate whether the scientific conclusion depends strongly on reasonable analytical choices.

Do Not P-Hack Your Portfolio

A portfolio project is an opportunity to demonstrate statistical integrity.

Avoid:

• Running dozens of tests until one is significant
• Removing inconvenient observations without justification
• Trying multiple endpoints and reporting only favorable ones
• Changing the analysis after seeing results without disclosure
• Presenting exploratory analyses as confirmatory findings

If an analysis was exploratory, label it as exploratory.

Document Exploratory Analyses

Exploratory analyses can be valuable.

For example, you might discover an interesting treatment-by-biomarker pattern.

You can present it as:

Build a Professional Report

The final report can be structured similarly to a short statistical report.

Include a Statistical Methods Section

The methods section should answer:

• What population was analyzed?
• What was the primary endpoint?
• How was it defined?
• What statistical model was used?
• Which covariates were included?
• How was censoring handled?
• How was missing data handled?
• What confidence level was used?
• Which software was used?

Make the Portfolio Project Visually Professional

Presentation matters because statistical output is ultimately a communication product.

Use:

• Consistent fonts
• Consistent decimal places
• Meaningful figure titles
• Readable axis labels
• Clear legends
• Units where appropriate
• Confidence intervals
• Denominators
• Footnotes for abbreviations

Avoid:

• Three-dimensional charts
• Excessive decoration
• Unreadable legends
• Unnecessary colors
• Plots without units
• Tables containing unexplained abbreviations

Tables Should Be Reproducible Too

Do not manually type your final results into a Word document.

Instead, generate tables from the analysis dataset whenever possible.

Packages such as gt, gtsummary, or flextable can be useful depending on the desired output.

library(gtsummary)

table1 <- dat %>%
  select(
    TRT01P,
    AGE,
    SEX,
    ECOG,
    BIOMARKER
  ) %>%
  tbl_summary(
    by = TRT01P,
    statistic = list(
      all_continuous() ~ "{mean} ({sd})",
      all_categorical() ~ "{n} ({p}%)"
    )
  )

table1

Use Quarto or R Markdown

A reproducible report can combine narrative, code, tables, and figures.

For example, a Quarto document can contain:

---
title: "Clinical Trial Biostatistics Portfolio Project"
format: html
---

## Objective

Evaluate progression-free survival...

```{r}
fit <- survfit(
  Surv(PFS, PFS_EVENT) ~ TRT01P,
  data = dat
)
```

## Results

The Kaplan-Meier estimates showed...

This is particularly valuable because the report and analysis remain connected to the code.

Use Version Control

Git is an important professional skill for modern statistical programming.

Useful commands include:

git init

git add .

git commit -m "Initial analysis workflow"

git status

git log

You do not need a complicated Git workflow for a portfolio project.

The important principle is that changes should be traceable.

Do Not Upload Sensitive Data

For portfolio work, simulated data or appropriately licensed public datasets are generally safer choices.

Consider Data Licensing

If you use public data, document:

• Where the data came from
• Whether registration is required
• Whether redistribution is permitted
• What license applies
• What preprocessing you performed

If the original dataset cannot legally be redistributed, publish your analysis code and instructions for obtaining the data rather than uploading the data itself.

Build a Project Scorecard

A simple internal scorecard can help identify weaknesses before you publish your project.

Build the Project in Stages

Do Not Make the Project Too Large

One of the most common portfolio mistakes is trying to demonstrate every statistical method in one project.

A project containing:

• ANOVA
• ANCOVA
• Logistic regression
• Cox regression
• Poisson regression
• Mixed models
• ROC analysis
• Principal components analysis
• Cluster analysis
• Machine learning
• Meta-analysis

may look impressive at first glance, but it can lack a coherent scientific story.

One Project Can Demonstrate Many Skills

A well-designed clinical-trial project can demonstrate:

What Should the Final Portfolio Contain?

Create a Portfolio Landing Page

If you have multiple projects, your portfolio can contain a simple landing page.

# Biostatistics Portfolio

## Featured Projects

### 1. Randomized Clinical Trial Analysis
Kaplan-Meier analysis, Cox regression,
objective response, safety summaries.

### 2. Diagnostic Test Accuracy
ROC curves, AUC, sensitivity,
specificity, predictive values.

### 3. Longitudinal Biomarker Analysis
Mixed-effects models and repeated-measures
visualization.

## Software

R | SAS | SQL | Git | Quarto

## Contact

Your Name

Tailor the Project to the Job

Different jobs value different skills.

If You Want a Clinical-Trial Job

A portfolio project should ideally demonstrate familiarity with concepts such as:

• Randomization
• Analysis populations
• Baseline characteristics
• Primary and secondary endpoints
• Estimands
• Missing data
• Adverse events
• Time-to-event endpoints
• Response endpoints
• Confidence intervals
• Multiplicity
• Sensitivity analyses
• Statistical programming
• Tables, listings, and figures

If You Want to Demonstrate SAS

You can implement the same project in both R and SAS.

For example, the survival analysis could be implemented using SAS procedures such as:

proc lifetest data=analysis
    plots=survival(atrisk);

    time PFS*PFS_EVENT(0);

    strata TRT01P;

run;

proc phreg data=analysis;

    class TRT01P(ref="Treatment B");

    model PFS*PFS_EVENT(0)
        = TRT01P AGE ECOG;

run;

The value of doing this is not simply showing two software packages.

It demonstrates that you understand the underlying statistical analysis independently of the software implementation.

R vs. SAS in a Portfolio

Do Not Claim Expertise You Have Not Demonstrated

A portfolio should be honest about your experience.

There is a meaningful difference between:

• "Used Cox regression in a portfolio project"
• "Experienced clinical-trial statistician specializing in survival analysis"

The first is precise and defensible.

The second implies professional experience that a portfolio project alone cannot establish.

How to Present the Project in an Interview

Prepare a five-minute version.

A useful structure is:

Example Interview Explanation

Questions an Interviewer May Ask

Be Ready to Explain Every Variable

If your model contains:

Surv(PFS, PFS_EVENT) ~ TRT01P + AGE + ECOG + BIOMARKER

you should be able to explain:

• Why treatment is included
• Why age is included
• Why ECOG is included
• Why the biomarker is included
• How each variable is coded
• What happens if values are missing
• What the treatment coefficient means

Never include a variable simply because a tutorial told you to.

Include Limitations

A project becomes more credible when you acknowledge its weaknesses.

For a simulated clinical-trial project, limitations might include:

• The dataset is simulated rather than real clinical data.
• Simulation assumptions may not reflect real-world disease behavior.
• The sample size may be too small for reliable subgroup analyses.
• The analysis does not reproduce every operational aspect of a real trial.
• Missing-data assumptions are simplified.
• The results should not be interpreted as clinical evidence.

What Not to Put in the Final Portfolio

• Raw identifiable patient data
• Unlicensed proprietary datasets
• Screenshots of statistical software without interpretation
• Hundreds of unfiltered exploratory plots
• Output copied directly from software with no explanation
• Unexplained p-values
• Claims of clinical efficacy based solely on simulated data
• Code that cannot be reproduced

A Professional Project Checklist

Common Portfolio Mistakes

1. Starting with a statistical test. A good project begins with a scientific question.
2. Using too many methods. A coherent project is stronger than a statistical-method shopping list.
3. Ignoring data preparation. Real biostatistical work involves substantial data understanding and derivation.
4. Reporting only p-values. Effect estimates and confidence intervals are usually more informative.
5. Ignoring assumptions. Every statistical method has conditions that should be considered.
6. Hiding limitations. Acknowledging limitations demonstrates statistical maturity.
7. Manual results. Important results should be generated reproducibly from the analysis dataset.
8. No QC. A portfolio project should demonstrate that you know how to verify your work.
9. Overly complicated GitHub repositories. Organization should make the analysis easier to understand, not harder.
10. Publishing confidential data. Portfolio development should never compromise patient privacy or data rights.
11. Unable to explain the model. If you cannot explain why a method was selected, reconsider including it.
12. Overclaiming results. Simulated or exploratory analyses should never be presented as clinical evidence.

How to Make the Project Stand Out

The difference between an ordinary portfolio and an excellent one is often documentation and reasoning rather than statistical complexity.

Consider adding:

• A prespecified analysis plan
• A data dictionary
• A reproducible Quarto report
• Independent QC checks
• Clear figure captions
• A sensitivity analysis
• A limitations section
• A short executive summary
• Session information
• A clean Git history

Demonstrate Reproducibility

A particularly strong portfolio allows a reviewer to reproduce the project using a single command or a clearly documented sequence.

For example:

source("R/01_import.R")
source("R/02_clean_data.R")
source("R/03_derive_variables.R")
source("R/04_descriptive_analysis.R")
source("R/05_primary_analysis.R")
source("R/06_secondary_analysis.R")
source("R/07_figures.R")
source("R/08_qc.R")

For a more advanced project, consider using a workflow manager such as targets to formalize dependencies.

Document the Software Environment

Package versions can affect reproducibility.

The renv package can record the project's R environment.

install.packages("renv")

renv::init()

renv::snapshot()

Another user can then restore the documented package environment.

Think Like a Reviewer

Before publishing, pretend you are reviewing someone else's analysis.

Ask:

• Can I understand the scientific question in one minute?
• Can I identify the primary endpoint?
• Can I reproduce the analysis?
• Can I determine how variables were derived?
• Can I tell which analyses were prespecified?
• Can I distinguish exploratory results?
• Can I understand the uncertainty around estimates?
• Can I identify major limitations?

Portfolio Project Maturity Levels

A Suggested Capstone Project

If you want one project that demonstrates broad clinical-biostatistics competence, consider building the following:

Suggested Final Deliverables

How the Project Maps to a Résumé

Once completed, the project can become a concise résumé entry.

Notice that this description focuses on what was actually done rather than claiming professional experience that the project does not establish.

How the Project Can Support an Interview

A strong project gives you concrete examples for common behavioral and technical interview questions.

Final Portfolio Audit

Before publishing the project, perform a final audit.

The Most Important Portfolio Principle

The most valuable portfolio project is not necessarily the one with the most advanced statistics.

It is the one that most convincingly demonstrates that you can think like a biostatistician.

That means understanding the question before analyzing the data, choosing methods for scientific reasons, quantifying uncertainty, validating your results, communicating limitations, and making the entire workflow reproducible.

Summary Checklist

References and Further Reading

Hernán, M.A., & Robins, J.M. (2020). Causal Inference: What If. Chapman & Hall/CRC.

Harrell, F.E. (2015). Regression Modeling Strategies. Springer.

Klein, J.P., & Moeschberger, M.L. (2003). Survival Analysis: Techniques for Censored and Truncated Data. Springer.

R Core Team. R: A Language and Environment for Statistical Computing. R Foundation for Statistical Computing.

Wickham, H., Çetinkaya-Rundel, M., & Grolemund, G. R for Data Science. O'Reilly Media.