Shipping R in production means pinned packages (renv), scripted pipelines—not ad hoc notebook clicks—logging, tests with testthat, and clear handoffs from SQL extracts.
Checklist
- renv.lock committed; no manual library installs on servers
- Rscript entry points with
main()functions - testthat for critical transforms
- Document cohort SQL and R preprocessing
- Static reports rendered in CI; Shiny behind auth if interactive
Track summary
You covered R fundamentals: vectors, factors, data frames, missing data, visualization concepts (base + ggplot2 locally), statistics, modeling, packages, reproducibility, and interview context. Continue with local tidyverse projects and explore Data Science for SQL + R/Python workflows—or compare patterns with the Python track.
Next steps
- Create a renv project and knit an R Markdown report locally
- Practice with a CSV export queried via SQL
- Build ggplot2 dashboards locally; try Shiny for interactivity
- Review CRAN task views for your domain (ClinicalTrials, Econometrics, etc.)
Important interview questions and answers
- Q: renv vs global install?
A: Global libraries drift; renv reproduces exact package versions in CI and prod. - Q: Rscript in cron?
A: Schedule batch reports—log stdout/stderr; alert on failure.
Self-check
- What file pins R package versions?
- Why testthat in pipelines?
Tip: Use scripted Rscript pipelines with renv—not click-only notebooks—in production. Next: Data Science.
Interview prep
- R in prod?
Scripted Rscript jobs, renv, tests, logging—not manual-only notebook runs.