Reports, Shiny and Production R Interview Questions for R Programming

R Markdown is a file format that combines narrative text written in Markdown with R code chunks. When rendered with knitr, the code runs and its output, such as tables and charts, is inserted into an HTML, PDF or Word document. This makes reports reproducible: when data changes, you re-render instead of copying charts manually. It is used for monthly reports, research papers, client deliverables and teaching material.

Shiny is an R package for building interactive web applications without writing HTML or JavaScript. An app has a ui that defines layout and inputs such as dropdowns and sliders, and a server function that contains R logic and creates outputs such as plots and tables. shinyApp(ui, server) runs the app. Analytics teams use Shiny for internal dashboards, what-if calculators and tools that let business users explore data.

renv is a package that creates a project-specific library and records exact package versions in a renv.lock file. renv::init() sets up the project, renv::snapshot() updates the lockfile and renv::restore() installs the same versions on another machine or server. This prevents code from breaking when packages update, makes analysis reproducible months later and is essential before deploying scripts or Shiny apps to production.

Git tracks every change to code, lets you revert mistakes, work on branches and collaborate through pull requests and reviews. RStudio has a built-in Git pane to stage, commit, diff, pull and push, and usethis::use_git() and use_github() set up repositories. Keep data files, secrets and outputs out of Git with .gitignore, commit the renv.lock file and write clear commit messages. Version control is expected even for analysis work.

I use openxlsx2 or openxlsx to write a workbook with multiple sheets, formatted headers, number formats for INR, column widths, frozen panes and conditional formatting, all from R. writexl is a lightweight option for plain sheets without formatting. I create a template once with the team's preferred layout and generate the file in the scheduled script, then email or upload it to a shared drive. This removes manual formatting every day.

In three years I see myself as a strong data analyst or junior data scientist who can own analyses end to end, from understanding the business question to building reproducible reports and models in R. I want to deepen my statistics and machine learning skills and learn cloud tools used by the team. I would also like to mentor new joiners, as seniors helped me, and contribute to reusable internal tools.

Quarto is the next-generation publishing system from Posit. It works with R, Python, Julia and Observable, and is a standalone command-line tool rather than an R package. It uses the same knitr engine for R and similar syntax, with chunk options written as #| comments. Quarto adds consistent support for websites, books, presentations and dashboards. R Markdown is still supported, but new projects increasingly use Quarto, especially in mixed R and Python teams.

Shiny uses reactive programming: outputs automatically update when the inputs they depend on change. Inputs are reactive sources, outputs such as renderPlot() are reactive endpoints, and reactive() expressions are cached intermediate results that recompute only when their dependencies change. For example, filtering data once in a reactive() and using it in three charts avoids filtering three times. Shiny tracks dependencies automatically, so you do not write explicit event handlers for most cases.

Options include shinyapps.io, a hosted service that is quickest to start but may not suit sensitive internal data, Posit Connect, a commercial on-premise or cloud server with authentication, scheduling and scaling, the free open-source Shiny Server on a Linux machine, and a Docker container behind a reverse proxy like Nginx, often with ShinyProxy for authentication. For internal data, I would choose Connect or containers inside the company network with single sign-on.

A minimal package has a DESCRIPTION file with metadata and dependencies, a NAMESPACE file listing exported functions, an R/ folder with function code, a man/ folder for documentation and usually tests/ for testthat tests. The usethis and devtools packages create and manage this: usethis::create_package(), use_r(), use_test(), and devtools::document(), test() and check(). Documentation is written as roxygen2 comments above each function. Internal packages are ideal for sharing team utilities.

On a Linux server I schedule Rscript with cron, for example 0 7 * * * Rscript /path/report.R, and on Windows with Task Scheduler or the taskscheduleR package. Posit Connect can schedule Quarto reports and email them directly. GitHub Actions can run scheduled workflows for non-sensitive jobs. The script itself renders the report and sends it with blastula or emayili. I add logging and an alert on failure so silent misses are caught.

I remove them immediately, inform the owner and ask for the password to be rotated, since it may exist in version history. Then I store credentials outside the code, in a user-level .Renviron file read with Sys.getenv(), the keyring package backed by the operating system's credential store, or the server's secret management, such as environment variables in Posit Connect. I make sure .Renviron is listed in .gitignore and scan the repository history.

plumber turns R functions into REST API endpoints using special comments. You annotate a function with #* @get /predict and its arguments become query parameters, then run the API with pr_run(). Other systems, such as a Java web app or a Python service, can call the R model over HTTP and receive JSON. It is commonly used to serve model predictions, and it can be deployed in Docker or on Posit Connect.

I would adopt the tidyverse style guide as the team standard, then automate it rather than relying on reviewers. styler reformats code automatically, including an RStudio add-in, and lintr flags issues such as long lines, unused variables and inconsistent naming. I add lintr to a pre-commit hook or a GitHub Actions check so pull requests are checked automatically. A short template for new scripts and projects helps new joiners follow the same structure.

Situation: regional sales managers waited for a weekly emailed PDF and could not drill into their own data. Task: give them self-service access. Action: I built a Shiny app with filters by region, product and period, used pre-aggregated tables for speed and deployed it on the internal server with login. I ran a short demo and gathered feedback. Result: over 40 managers used it weekly, and ad hoc data requests to our team fell by about half.

Situation: a teammate wanted to build our reporting pipeline in Excel macros, while I preferred R scripts. Task: agree on an approach quickly. Action: instead of arguing, we listed requirements together: refresh frequency, data size and who would maintain it. I built a small R prototype in a day to compare. Result: we chose R for the pipeline and kept an Excel output for users, and my teammate later helped improve the formatting.

I profile with profvis and reactlog to find slow reactives. I move heavy data loading outside the server function so it runs once per process, pre-aggregate data instead of computing on raw rows, and cache results with bindCache(). I use bindEvent() so expensive work runs only on a button click. Long computations can go to background tasks with ExtendedTask and promises. Finally I scale out with multiple R processes on Posit Connect or Shiny Server Pro.

reactive() creates a cached value that other code can read, such as filtered data, and it is lazy, recomputing only when needed. observe() runs code for its side effects whenever any reactive dependency changes, returning nothing. observeEvent() runs side effects only when a specific event fires, such as a button click, ignoring other dependencies. Use reactive() for computing values and observeEvent() for actions like saving data or showing notifications.

Packages like sf, xml2 or RPostgres need system libraries such as GDAL, libxml2 or libpq, which differ between machines. I would containerize the pipeline with Docker, starting from a rocker image like rocker/r-ver pinned to the R version, installing system dependencies in the Dockerfile and restoring packages with renv. The same image then runs on laptops, servers and the cloud, eliminating environment differences between development and production.

Situation: the scheduled R job feeding the morning leadership dashboard failed at 6 AM after a source table added a new column type. Task: restore the dashboard before the 9 AM meeting. Action: I checked the logs, identified the parsing error, patched the column specification, reran the job and informed stakeholders of the delay. Afterwards I added schema validation and a failure alert. Result: data was live by 8:30 AM, and similar changes are now caught early.