Scenario-Based R Programming Interview Questions

First I check that the package providing the function is installed and loaded with library() at the top of the script, not only in my interactive session. Then I compare R and package versions using sessionInfo(), because functions get renamed or deprecated. To prevent this, I use renv to snapshot exact package versions into a lockfile, so the colleague runs renv::restore() and gets the same environment. Namespacing calls like dplyr::filter() also avoids masking conflicts.

read.csv() is single-threaded and guesses types slowly. I would switch to data.table::fread() or readr::read_csv(), which are many times faster and multi-threaded. I would read only the needed columns with the select argument and set column types explicitly. If the file is reused, I convert it once to a binary format like Parquet with the arrow package, which loads in seconds and supports reading just a subset of columns.

I first find the offending values, for example with unique(df$amount[is.na(as.numeric(df$amount))]), which reveals entries like '1,200', 'NA ' or '-'. Then I clean them, removing commas with gsub(',', '', x) and spaces with trimws(), and convert with as.numeric(). With readr I can also pass na = c('', '-', 'NA') and col_types so the column is parsed correctly at load time instead of being fixed later.

I check object sizes with lobstr::obj_size() and remove large intermediates with rm() followed by gc(). I load only the needed columns and use data.table, which modifies by reference without copies. For data larger than RAM, I push computation into a database through dbplyr, or use arrow with Parquet files so filters and aggregations run before data enters R memory. Chunked reading with readr::read_csv_chunked() is another option for one-pass jobs.

Functions like sample(), rnorm() and random train-test splits depend on the random number generator. I call set.seed(42) at the start of the script so the same random sequence is generated every run, which lets reviewers reproduce results. For parallel code I use reproducible streams, for example future with seed = TRUE. I also record the R version, because the default sampling algorithm changed in R 3.6.0 and can change results between versions.

I list the files with list.files(pattern = 'csv$', full.names = TRUE), then read them all at once with readr::read_csv(files, id = 'file'), which also records the source file. Alternatively I use purrr::map() with read_csv and dplyr::bind_rows(). Before combining, I check that column names and types match, because one file with text in a numeric column will fail or coerce the whole column. I then derive the month from the file name for traceability.

Calling rbind() inside a loop copies the growing data frame each iteration, so time grows roughly quadratically. I instead store each piece in a preallocated list, results[[i]] <- piece, and combine once at the end with dplyr::bind_rows() or data.table::rbindlist(), which is the fastest. Better still is to vectorize the computation or use purrr::map() followed by list_rbind(). On 10,000 iterations this can cut runtime from minutes to seconds.

Indian files often store dates as dd/mm/yyyy, but as.Date() expects yyyy-mm-dd by default, so values become NA. I specify the format, as.Date(x, format = '%d/%m/%Y'), or use lubridate::dmy(x), which handles different separators automatically. Then I count NAs before and after conversion to confirm nothing failed silently. If the column came from Excel as serial numbers, I use as.Date(x, origin = '1899-12-30') instead.

Extra rows after a join usually mean the key is duplicated in one or both tables, so each match multiplies rows. I check uniqueness with df %>% count(key) %>% filter(n > 1) on both sides. Then I decide whether to deduplicate, aggregate before joining or join on a composite key such as customer_id plus month. In dplyr 1.1 and later, the relationship argument, for example 'many-to-one', makes the join fail loudly when this assumption breaks.

I make the request with httr2, handling authentication and pagination, then parse with jsonlite::fromJSON(), which simplifies arrays of objects into data frames, using flatten = TRUE to spread nested objects into columns. For deeper nesting I keep a list and use tidyr::unnest_wider() and unnest_longer() to expand list-columns step by step. Optional keys become NA, so I check missing fields across records and validate types before analysis.

I first aggregate to one row per product and month with group_by() and summarise(). Then I group by product, arrange by month and use mutate(growth = (sales - lag(sales)) / lag(sales) * 100). The first month for each product becomes NA, which is correct. I make sure months with zero sales exist using tidyr::complete(), otherwise lag() compares non-consecutive months. Finally I round and format growth for reporting.

I group by customer_id and keep the row with the latest updated_at using slice_max(updated_at, n = 1, with_ties = FALSE), then ungroup. An alternative is arrange(desc(updated_at)) followed by distinct(customer_id, .keep_all = TRUE). I check that updated_at is a proper date-time and has no NAs, since missing timestamps would be dropped or mis-sorted. Finally I confirm that n_distinct(customer_id) equals the number of rows.

I can keep dplyr syntax but change the backend. dtplyr translates dplyr code to data.table, which is much faster in memory. duckdb with dbplyr runs the pipeline in an embedded columnar database, often handling data larger than RAM. arrow lets me query Parquet files with dplyr verbs lazily. I would also filter and select early, avoid row-wise operations and profile the pipeline to find the slow step before rewriting anything.

First I investigate whether they are data errors, such as an extra zero, or genuine high earners. I flag outliers with the IQR rule, values beyond Q1 - 1.5 IQR or Q3 + 1.5 IQR, or with percentiles. Errors I fix or remove with documentation. Genuine values I keep, but I report the median alongside the mean, or winsorize at the 1st and 99th percentiles for modelling. The choice depends on the business question.

I group by the relevant category, such as product category, and replace NAs with that group's median: group_by(category) %>% mutate(price = coalesce(price, median(price, na.rm = TRUE))) %>% ungroup(). Group medians are more realistic than a global value. I also add a flag column marking imputed rows so models and reviewers can see them. If a whole group is missing, I fall back to the overall median, and for important features I consider model-based imputation.

I load both datasets and standardise the key, for example trimming spaces and matching data types for transaction_id. Then anti_join(finance, report, by = 'transaction_id') lists transactions in finance but not in my report, and the reverse anti_join shows extras. I examine the missing rows for patterns such as a date range, status or filter in my code. Usually the cause is a timezone cut-off or an excluded status.

For comparing categories I use a bar chart, sorted by value, or a dot plot when there are many categories. For trends over time I use a line chart with time on the x-axis. For distributions I use histograms or density plots for one variable and boxplots or violin plots to compare groups. For relationships between two numeric variables I use a scatter plot. I avoid pie charts beyond three or four slices.

This is overplotting. I reduce point size and add transparency with geom_point(alpha = 0.1, size = 0.5). Better options are geom_hex() or geom_bin2d(), which show density as colour, or geom_density_2d() contours. I could also plot a random sample for shape and a smoothed trend with geom_smooth() on the full data. If x values are discrete, geom_jitter() spreads points. The goal is to make density visible, not every point.

I use colour-blind-safe palettes such as viridis with scale_colour_viridis_d() or the Okabe-Ito palette, and avoid red-green contrasts. I never rely on colour alone: I add direct labels, different shapes or line types, and facets. I limit categories to around six colours and highlight one key series while greying the rest. I also check charts with a colour-blindness simulator, such as the colorblindr package, before sharing.

ggplot2 orders discrete axes by factor levels, which default to alphabetical. I reorder the factor by the value with forcats: aes(x = fct_reorder(city, sales), y = sales), and add coord_flip() or put the category on the y-axis for long labels. For a fixed custom order, such as months or ratings, I set levels explicitly with factor(x, levels = c(...)). fct_infreq() orders by frequency for count bars.

I first ask which decisions the page supports and which three to five metrics matter most, because 15 charts usually hide the message. I put headline KPIs at the top, followed by trend charts and then breakdowns, with consistent colours, scales and a shared theme function. Less important views go to a drill-down tab in a Shiny or Quarto dashboard. I test the draft with one stakeholder and remove charts nobody uses.

I first question whether all points are needed. I aggregate before plotting, for example binning into hexagons with geom_hex() or summarising by time interval. If raw points are required, the scattermore package rasterizes millions of points quickly, and ggrastr rasterizes just the point layer while keeping text as vector. Saving as PNG instead of PDF also helps, because vector files with millions of shapes are huge and slow to open.

Conversion is a proportion, so I use a two-proportion test: prop.test(c(conv_a, conv_b), c(n_a, n_b)). I check the p-value and, more importantly, the confidence interval for the difference. Before trusting it, I confirm the sample size was planned in advance, the test ran for full weeks to cover weekday effects, users were randomized properly and nobody stopped the test early when results looked good. Then I judge business significance.

With small, heavily skewed samples the t-test's normality assumption is doubtful. I would check with a histogram, Q-Q plot or shapiro.test(). Options are a non-parametric test, wilcox.test() for two groups or kruskal.test() for more, a log transformation if the data is right-skewed and positive, or a bootstrap confidence interval for the difference in means. With large samples, the Central Limit Theorem usually makes the t-test acceptable.

I use power analysis before the test starts. In R, power.prop.test(p1 = 0.05, p2 = 0.055, power = 0.8, sig.level = 0.05) gives roughly 31,000 users per group. Smaller lifts need far larger samples, since sample size scales with the inverse square of the effect. I would then convert the sample into test duration using daily traffic, round up to full weeks, and agree on the stopping rule in advance to avoid peeking bias.

I explain that failing to reject the null is not proof of no effect. A p-value of 0.06 means the evidence is weak or the test was underpowered, and the 0.05 cut-off is a convention, not a law. I would show the confidence interval for the effect, which probably ranges from slightly negative to clearly positive, check whether the sample size met the planned power and suggest extending the test or weighing the decision on cost and risk.

Simple averages would be biased toward oversampled groups, so I use the survey weights provided with the data. In R, the survey package defines the design with svydesign(ids = ~psu, strata = ~stratum, weights = ~wt, data = df), then svymean(), svytotal() and svyglm() give weighted estimates with correct standard errors that account for clustering and stratification. The srvyr package offers the same with dplyr-style syntax.

This is Simpson's paradox. It happens when a confounding variable, here hospital or patient severity, is unevenly distributed between groups. If A was used mostly in hospitals with easier cases, its overall rate looks better even though B wins within each hospital. In R I would group by hospital and compare rates, then use a stratified analysis or regression with hospital as a covariate to estimate the adjusted effect.

A common cause is that the function reads a variable from the global environment instead of taking it as an argument. During testing that global variable had one value, and in the main script it has another. Lexical scoping finds it silently. I would check the function body for names not defined as arguments or locally, for example using codetools::findGlobals(fn), and pass everything explicitly so the function is self-contained.

I wrap each call with purrr::safely() or tryCatch() so one failure does not stop the loop, and add retries with exponential backoff, which httr2 supports through req_retry(). I respect rate limits with Sys.sleep() or req_throttle(). I save results incrementally, for example every 100 calls to an RDS file or database, so a restart resumes from the last checkpoint. Finally I log failed IDs and rerun only those.

First I profile with profvis to find the slow lines. Then I try vectorizing, for example generating all random numbers at once with rnorm(n * reps) and using matrix operations instead of nested loops. I preallocate outputs instead of growing them. If iterations are independent, I run them in parallel with future and furrr. If a tight loop cannot be vectorized, I rewrite it in C++ with Rcpp, which often gives a 10 to 100 times speed-up.

An if statement can only check a single TRUE or FALSE value, and since R 4.2 a longer condition is an error. The function was written for one value but received a vector. I would replace if with a vectorized alternative such as ifelse(), dplyr::if_else() or case_when(). If the function is truly meant for single values, I validate the input length with stopifnot(length(x) == 1) or apply it over elements with purrr::map().

I would extract the logic into well-named functions with arguments for the parts that differ, then move them into one shared file loaded with source() or, better, a small internal R package. A package gives documentation with roxygen2, tests with testthat and versioning, so every script uses the same tested logic. Fixing a bug then happens in one place. I would migrate the scripts gradually and compare outputs to confirm nothing changed.

The function repeats expensive work for identical inputs, so I would cache its results with memoisation. The memoise package wraps a function, memo_rate <- memoise::memoise(get_rate), and stores results by argument values, returning cached answers instantly. I can set a cache that expires, for example daily for rates, or store it on disk with cachem so it survives sessions. Alternatively I fetch all needed rates once and join them as a lookup table.

Accuracy is useless here, since predicting no fraud gives 99.5 percent. I use stratified splits and evaluate with precision, recall, F1 and the precision-recall AUC. To help the model learn the minority class, I try class weights, downsampling the majority or SMOTE through the themis package in a recipe, applied only to training data. Then I tune the probability threshold based on the cost of missed fraud versus false alarms agreed with the business.

The gap indicates overfitting or data leakage. I first check for leakage, such as a feature computed using future information or the target itself, or duplicate records across train and test. Then I simplify the model, add regularization, reduce features or tune hyperparameters with cross-validation instead of a single split. If data is time-based, I make sure the split is chronological. I compare against a simple baseline to judge real improvement.

This is a classic sign of multicollinearity, where predictors are highly correlated, for example total spend and online spend. The model cannot separate their effects, so coefficients become unstable. I check correlations and the variance inflation factor with car::vif(); values above 5 or 10 are a concern. Solutions are removing or combining correlated variables, using principal components or ridge regression. Prediction accuracy may be fine, but interpretation is unreliable.

Dummy-encoding 500 levels creates sparse, noisy features and overfits rare levels. I first lump rare levels into 'other' with step_other(). Then I consider target or effect encoding with the embed package, applied inside cross-validation to avoid leakage, or mapping pincodes to meaningful higher-level features such as city tier, region or distance to a warehouse. Tree models in some engines handle many levels better, but grouping by business meaning usually works best.

I gather at least two or three years of daily history, since festive peaks happen once a year and Diwali moves across October and November. I add holiday regressors for Diwali, Dussehra and sale events rather than relying on calendar seasonality alone. I compare models like ETS, ARIMA with regressors and prophet in fable, validating on past festive seasons. I report prediction intervals and review with business teams for planned promotions or stock limits.

I explain both global and individual behaviour. Globally, I show variable importance and partial dependence plots, using DALEX or the vip package, to show how key features affect predictions. For individual cases I use SHAP values, for example through the shapviz or fastshap packages, so a manager can see why a customer was flagged. I compare against a simple logistic model and walk users through real examples they know.

I save the fitted workflow, including the recipe, with saveRDS() or the vetiver package, which versions models and adds monitoring. For batch scoring, a scheduled R script reads new customers from the database, predicts and writes scores back, run by cron, Posit Connect or a container in the cloud. For real-time needs, I expose the model as a REST API with plumber or vetiver in Docker. I log inputs and track drift.

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.

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.

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.

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.

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.

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.