Top 60 R Interview Questions (2026)

R is a language and free software environment built for statistical computing and graphics. It's open source, dynamically typed, and vector-first, which means most operations naturally work on a whole vector at once rather than element by element, so a lot of analysis indicates a few short expressions.

It's used for data analysis, statistics, machine learning, and visualization. The base install covers models and plots, and the CRAN archive adds thousands of packages for almost any analysis task.

A vector is R's core data structure: an ordered collection of values that all share one type. R has no separate scalar type, so even a single number like 5 is really a length-one vector, which is why so many operations naturally work on whole vectors at once.

It matters because R is built for vectorized operations. Adding two vectors, filtering with a logical vector, or applying a function across one is idiomatic and fast, while element-by-element loops are usually the slower, less R-like choice.

R has six atomic vector types: logical, integer, double (the default for numbers), character, complex, and raw for bytes. The first four are the ones you use daily. Every element of an atomic vector shares a single type, which is what makes them different from lists.

If you combine types with c(), R coerces to the most general one: logical to integer to double to character. Knowing this coercion order explains many surprising results.

An atomic vector holds elements of a single type, all numbers or all characters. A list is the flexible container: it can hold elements of different types, including other lists, so one list can mix a number, a string, and a whole vector as its members.

Lists are how R holds mixed or hierarchical data. A data frame is actually a list of columns under the hood, which is why it can mix numeric and character columns.

R has three main assignment operators: the leftward <- , the plain = , and the rightward -> . The community standard is <- for creating and updating variables, while = is conventionally reserved for passing named arguments inside a function call, so the two roles stay visually distinct.

There's also <<- , which assigns in an enclosing or global scope. Use it rarely and deliberately, because reaching outside the current scope makes code hard to reason about.

When two vectors of different lengths meet in an operation, R recycles the shorter one, repeating it until it matches the longer vector's length. This is why adding a length-one vector to a long one adds it to every element.

If the longer length isn't a multiple of the shorter, R still recycles but warns you. Silent recycling is a common source of bugs, so watch for length mismatches.

Missing values are NA, short for Not Available. They're contagious: most operations involving an NA return NA, so mean(c(1, NA, 3)) comes back as NA unless you explicitly tell the function to ignore the missing value first.

Test for them with is.na(), never with == , because NA == NA is itself NA. Many functions take na.rm = TRUE to drop missing values before computing.

NA is a missing value that still occupies a slot. NULL is the absence of a value entirely, a zero-length object, often used to drop things. NaN is 'not a number', from undefined math like 0/0. Inf and -Inf are infinity, from things like 1/0.

The key distinction: NA keeps its place in a vector, while NULL disappears. is.na() is TRUE for both NA and NaN, so use is.nan() when you need to separate them.

A data frame is R's table structure: a list of equal-length columns where each column can carry its own type. Rows are observations and columns are variables, which matches how real tabular data looks. Because it's a list of columns underneath, one column can be numeric while the next is character.

Because it's a list of columns under the hood, one column can be numeric and another character. It's the object almost every analysis and modeling function expects.

R indexing is 1-based and works four ways. Positive integers keep the positions you name, negative integers drop them, a logical vector of the same length keeps the TRUE positions, and character names pull elements from a named vector. Logical indexing is the one you'll reach for most when filtering data.

Logical indexing is the workhorse for filtering data. Index 0 returns an empty vector rather than the first element, which surprises people coming from other languages.

A factor is R's type for categorical data. It stores values as integer codes behind a set of labelled levels, so 'Low', 'Medium', 'High' become 1, 2, 3 with those labels attached. That representation is compact and tells modeling functions to treat the column as distinct groups.

Use factors for categories that feed into models or need a defined order, since a model treats a factor as a set of groups. Convert to an ordered factor when the categories have a natural ranking.

Base R uses read.csv(), which reads a comma-separated file into a data frame. The tidyverse readr package offers read_csv(), which is faster on big files, guesses column types more carefully, never converts strings to factors, and returns a tibble instead of a plain data frame.

Common arguments handle real files: header, sep for the delimiter, stringsAsFactors to control factor conversion, and na.strings to mark missing codes.

install.packages("name") downloads a package from CRAN and installs it to disk, which you do once per machine. library(name) then loads that installed package into your current session, and you run library() again at the start of every new session because loading isn't permanent.

A detail interviewers like: install.packages takes the name as a string, while library takes it unquoted. You can also call a function without loading with the package::function() form.

You create a function with the function() keyword and assign it to a name. Arguments can carry default values, and the last expression the body evaluates is returned automatically, so you rarely write return() except for an early exit partway through. Braces are optional for a one-line body.

Functions in R are first-class objects: you can pass them to other functions, return them, and store them in lists. That's what makes the apply family work.

R has if / else, for, while, and repeat, with much the same shape as other languages. A for loop walks over the elements of a vector or list, while break exits a loop early and next skips to the following iteration. The condition in an if must be a single logical value.

The R-specific advice: prefer vectorized operations and the apply family over explicit loops when you can, because they read better and are usually faster. Loops aren't wrong, they're just often not the R-like choice.

Arithmetic: + , - , * , / , ^ for power, %% for modulo, and %/% for integer division. Comparisons: == , != , < , > , <= , >= , all returning logical vectors.

Because operators are vectorized, comparing a vector to a value returns a logical vector you can use for filtering. Logical operators come in two forms, which is the next thing interviewers ask about.

& and | are vectorized: they compare element by element and return a logical vector. && and || are scalar: they look only at the first element and short-circuit, which is what you want inside an if condition.

Using & where you meant && (or the reverse) is a classic bug. From R 4.3, && and || actually error on inputs longer than one, which catches the mistake early.

The colon operator makes simple integer sequences, so 1:10 counts up by one. seq() is the flexible version that takes a step with by or a target count with length.out. rep() repeats values, either repeating each element in place or tiling the whole vector a number of times.

These show up constantly for building index vectors, test data, and grouping labels, so knowing the argument names saves time in live coding.

str() shows the structure, listing each column's type and first few values, and it's the fastest way to understand an unfamiliar data frame. summary() gives per-column statistics like min, median, and max. head() and tail() print the first or last rows so you can eyeball the actual data.

dim(), nrow(), ncol(), and names() answer the basic shape questions. Reaching for str() first is a small habit that indicates real experience.

A matrix is a two-dimensional atomic structure where every element shares one type, most often numeric. You build one with matrix(), which fills column by column by default, and you index it with two positions in [row, column] form. Leaving one blank keeps that whole dimension.

Matrices support real linear algebra: %*% is matrix multiplication, t() transposes, and solve() inverts. For mixed-type tabular data you want a data frame instead.

String work in base R centers on a handful of functions. paste() and paste0() join strings, with paste0() using no separator between pieces. nchar() counts characters, toupper() and tolower() change case, and substr() extracts a range by position.

For pattern work, grepl() tests for a match, gsub() replaces, and sub() replaces the first hit. The stringr package wraps these in a consistent, easier-to-remember interface.

R has strong in-session help. ?function or help(function) opens a function's documentation, and example(function) runs the examples from that page. When you don't know the exact name, ??term does a fuzzy search across every installed package's help files.

ls() lists objects in your environment, rm() removes them, and getwd() / setwd() manage the working directory. Knowing you can read the docs in-session is exactly what an interviewer hopes to see.

The apply family runs a function repeatedly without writing an explicit loop. apply() works over matrix rows or columns, lapply() over a list returning a list, sapply() simplifies the result, vapply() adds a safety type check, and mapply() iterates over several inputs at once.

They read as 'run this function across this structure', which is closer to how R thinks than a for loop. Picking the right one signals fluency.

Not dramatically, and that's the honest answer the question needs. The apply family is still a loop running at the R level under the hood, so the big speedups come from true vectorization, where the work drops into compiled C, not from swapping a for loop for sapply.

The real reasons to use apply functions are readability and intent: they say 'map this function over this structure' clearly, and they avoid the classic bug of growing a vector inside a loop. For raw speed, vectorize or pre-allocate.

dplyr gives a small set of verbs that cover most data wrangling: filter() keeps rows, select() keeps columns, mutate() adds or changes columns, arrange() sorts rows, group_by() sets grouping, and summarise() collapses each group to a single summary row. Each verb takes a data frame and returns one.

Chained with the pipe, they read top to bottom like a recipe, which is why teams reach for dplyr over base R subsetting for anything beyond one step.

The pipe passes the value on its left into the function on its right as the first argument, so x %>% f(y) is the same as f(x, y). Chaining several pipes turns a nest of inside-out calls into a readable top-to-bottom sequence that reads like the steps of a recipe.

There are two: the magrittr %>% from the tidyverse and the native |> added in R 4.1. The native pipe is built in and slightly stricter; %>% supports the . placeholder for arguments other than the first.

Wide format spreads a variable across several columns, like one column per month. Long format stacks those into key-value rows, with a column naming the month and a column holding the value. Most tidyverse tools and ggplot2 want long, tidy data with one observation per row.

tidyr does the reshaping: pivot_longer() goes wide to long, pivot_wider() goes long to wide. In base R, reshape() does the same job with a clunkier interface.

Base R uses merge(), where you control the join type with the all, all.x, and all.y arguments to get inner, full, left, or right behavior. dplyr offers clearer named verbs, inner_join(), left_join(), right_join(), and full_join(), that map one to one onto the SQL joins you already know.

The dplyr names map directly to SQL joins, which makes the intent obvious. Watch for the join key: mismatched types or duplicate keys quietly change your row count.

There are three common paths. Base R has aggregate() and tapply() for split-apply-combine. The tidyverse pairs group_by() with summarise() for readable, chainable code. data.table uses its dt[i, j, by] syntax and runs fastest on large data. All three split by a group, compute per group, then combine.

All three answer the same question: split the data by a group, compute something per group, and combine. Knowing more than one path shows range.

ggplot2 builds a plot in layers, starting from a data frame. You map columns to visual aesthetics like x, y, and color with aes(), then add one or more geometric layers such as geom_point or geom_bar that decide how those mappings are drawn. Each layer stacks on with a plus sign.

The grammar means you compose a plot from parts instead of picking a canned chart type: data, aesthetics, geoms, scales, and facets add up with +. That composability is why it's the default plotting choice for most R users.

R uses copy-on-modify: when you assign y <- x, both names point to the same underlying object in memory until one of them is actually changed. Only at that moment does R make a real copy, which means plain assignment is cheap and no data is duplicated until you modify it.

The practical effect is that functions can't accidentally mutate their arguments; changing a passed-in vector inside a function copies it first. That safety costs memory when you modify large objects in a loop, which is why growing objects iteratively is slow.

An environment is a container of name-to-value bindings, and R uses lexical scoping to resolve names. A function looks for a name first in its own environment, then in the environment where the function was defined, and on up the chain to the global environment and the loaded packages beyond it.

This is what makes closures work: a function returned from another function remembers the variables from its defining scope. Unlike most R objects, environments are mutable and passed by reference.

A closure is a function bundled with the environment it was created in, so it keeps access to variables from that enclosing scope even after the outer function returns. In R, most functions you write are technically closures.

They power counters, function factories, and callbacks that carry state. The <<- operator lets the inner function update a captured variable, which is the mechanism behind a stateful closure.

S3 is R's simplest and most common object system. An object gets a class attribute, and generic functions like print() or summary() dispatch to a method named generic.class, such as print.lm for a linear model. There's no formal class definition; you just set the class and write the matching methods.

It's informal by design: there's no formal class definition, you just set a class and write methods. That flexibility is why base R and most packages use S3, and why it's the system the question expects you to know first.

S3 is informal: class is just an attribute and dispatch is by naming convention. S4 is formal, with defined slots, types, and validity checks, used where structure matters, like Bioconductor. R5, or Reference Classes, adds mutable, reference-based objects that behave like classes in Java or Python.

Most everyday R uses S3. Reach for S4 when you need enforced structure and multiple dispatch, and R5 (or the R6 package) when you genuinely need mutable objects with methods.

Vectorizing means expressing an operation over a whole vector at once instead of looping element by element. x + y adds two vectors in one step, with the loop running in fast compiled C rather than interpreted R.

It matters for both speed and readability. A vectorized expression is shorter and often many times faster than the equivalent for loop, because it skips R's per-iteration overhead.

match.arg() validates a string argument against a set of allowed values and lets callers use partial matches, which is how base functions accept type = "pearson" or just "p". do.call() calls a function with its arguments supplied as a list, useful when you build an argument list at runtime.

Both show up when you write flexible functions. do.call() in particular is the clean way to call a function whose arguments you have assembled programmatically.

A tibble is the tidyverse's modern take on the data frame. It prints only the first rows with column types, never converts strings to factors on its own, and doesn't do partial column-name matching, so it surprises you less.

It's still a data frame underneath and works with base functions. The differences are about safer defaults and cleaner printing, not a different structure.

The base functions are grep() and grepl() for matching, sub() and gsub() for replacing the first or all matches, and regmatches() with regexpr() for pulling out the matched text. By default they use POSIX-style regex, and passing perl = TRUE switches them to the richer Perl-compatible engine.

One R-specific trap: backslashes are doubled in regular strings, so a digit class is "\\d". Raw strings (r"(...)") since R 4.0 remove that pain, and stringr wraps the base functions in a friendlier interface.

R has two core classes. Date holds a calendar date as the number of days since 1970-01-01. POSIXct holds a full date-time as seconds since that same epoch, along with a time zone. as.Date() and as.POSIXct() parse strings into these classes, and format() turns them back into readable text.

Date math just works: subtracting two Dates gives a difftime in days. The lubridate package makes parsing and arithmetic far easier with functions like ymd() and months().

tryCatch() is the main tool: it runs an expression and lets you supply handlers for error, warning, and message conditions, plus a finally block that always runs. try() is a lighter option that just keeps going after an error.

You raise conditions with stop() for errors and warning() for warnings. R's condition system is more general than a simple try/catch, but tryCatch covers the everyday cases.

R evaluates function arguments lazily, meaning an argument isn't computed until the function actually uses it. Each argument is wrapped in a promise that holds the unevaluated expression along with the environment it came from, and that promise is forced the first time the value is needed inside the body.

This is why a function can accept an argument it never touches without erroring, why default arguments can refer to other arguments, and how non-standard evaluation packages like dplyr capture and rewrite the expressions you pass.

Non-standard evaluation means a function captures the expression you pass rather than its value, then evaluates it in a context it chooses. That's why filter(df, mpg > 20) works even though there's no object called mpg in your session; dplyr evaluates mpg inside the data frame.

The tidyverse builds on this with tidy evaluation: quo(), enquo(), and the {{ }} embrace let you write functions that take bare column names. It's the same mechanism behind subset() and with() in base R.

R stores objects on a heap and uses a generational, mark-and-sweep garbage collector that reclaims memory automatically once objects become unreachable, so you don't free anything by hand. gc() forces a collection and prints current usage, though you rarely need to call it since the collector runs on its own.

The practical issues are copy-on-modify creating extra copies, growing objects in loops reallocating repeatedly, and reference cycles being handled fine by the collector. Tools like lobstr::obj_size() and pryr help you see what's actually using memory.

Each time you extend a vector with c() or result[i+1] beyond its length, R allocates a new, larger block and copies the old contents over. Do that N times and you've done work proportional to N squared, plus repeated garbage collection.

The fix is to pre-allocate the result to its final size, then fill it by index. Better still, vectorize the operation or use an apply function, which handles allocation for you.

Measure first, because intuition about bottlenecks is usually wrong. Rprof() or the profvis package shows where the time actually goes across your call stack, and microbenchmark or bench::mark() fairly compares two implementations of the same task so you optimize the line that matters.

Then fix in order of impact: vectorize hot loops, pre-allocate, use data.table for large aggregations, and only after that reach for parallelism or Rcpp to rewrite a genuine hot spot in C++.

data.table is built for speed and memory efficiency on large data. It modifies in place with := to avoid copies, has fast grouped operations, and reads and writes files quickly with fread and fwrite. dplyr trades some of that for readability and a gentler syntax.

The honest split: dplyr for most analysis where clarity matters, data.table when the dataset is large enough that copy-on-modify and speed become the bottleneck. Both are excellent; the choice is about scale and team familiarity.

Rcpp lets you write C++ functions that R calls directly, with automatic conversion between R and C++ types. You write the function, compile it with sourceCpp() or inside a package, and call it like any R function.

Drop down to Rcpp when a profiled hot spot is an inherently iterative algorithm that can't be vectorized, recursion or element-by-element logic in a tight loop being the classic case. If the work can be vectorized in R, that's usually simpler and fast enough.

The parallel package (built in) offers mclapply() for forking on Unix and makeCluster() with parLapply() for a portable, socket-based approach. The furrr and future packages give a modern, apply-style interface that runs sequentially or in parallel by swapping the plan.

Parallelism helps CPU-bound, independent tasks: cross-validation folds, simulations, per-group models. Watch the overhead, since spinning up workers and copying data can cost more than it saves for quick jobs.

lm() fits a linear model from a formula like y ~ x1 + x2, where the tilde separates the response on the left from the predictors on the right. Calling summary() on the fitted model reports the coefficient estimates, their standard errors, p-values, and the R-squared that measures fit.

The output is what interviewers probe: a coefficient is the change in the response per unit of that predictor holding others fixed, and R-squared is the share of variance explained. predict() applies the model to new data, and plot(model) checks assumptions.

A formula, written with ~ , is an unevaluated object that captures a modeling relationship: response on the left, predictors on the right. y ~ x + z means model y using x and z. Modeling functions interpret the symbols in operators specially: + adds terms, : is an interaction, * is main effects plus interaction, and I() protects arithmetic.

Because a formula is just an object, it isn't evaluated where you write it; the modeling function decides what the symbols mean. That indirection is a form of non-standard evaluation.

A package is a directory with a DESCRIPTION file (metadata and dependencies), a NAMESPACE (what's exported), an R/ folder for code, and man/ for documentation. devtools and roxygen2 automate most of it: roxygen comments above a function generate the help file and namespace entries.

The workflow is load_all() to test in place, document() to regenerate docs, check() to run R CMD check, and test() for the testthat suite. Wrapping analysis in a package is what makes it reusable and shareable.

testthat is the standard framework. You group related checks inside test_that() blocks and assert with expectation functions like expect_equal(), expect_error(), and expect_true(). Test files live in tests/testthat/, are named test-*.R so they're found automatically, and run together with test() or during R CMD check.

Good practice mirrors any language: test behavior not implementation, cover edge cases like empty inputs and NAs, and keep tests fast so they run often. Test files are named test-*.R to be discovered automatically.

Pin package versions with renv, which records exact versions in a lockfile and restores them on another machine. Set a seed with set.seed() before any random step so results repeat. Keep the analysis in scripts or R Markdown / Quarto rather than console history.

The failure mode is an analysis that runs today and breaks in six months because a package updated. renv plus scripted, seeded code is the standard defense, and mentioning it indicates production experience.

sapply() guesses how to simplify its result: sometimes a vector, sometimes a matrix, and sometimes a list when the outputs differ in length. That inconsistency turns an edge case into a silent type change downstream, so a function that worked in testing returns a different shape in production and breaks quietly.

vapply() requires you to declare the expected output type and length with FUN.VALUE, so it fails loudly when a result doesn't match. In code others depend on, that predictability is worth the extra argument.

Attributes are metadata attached to any object: names, dimensions (dim), class, levels for factors, and custom tags you add. They're what turn a plain vector into something with structure; a matrix is a vector with a dim attribute, a factor is an integer vector with class and levels.

Access them with attr() or the bulk attributes(). Understanding attributes demystifies a lot of R: the difference between a list and a data frame, or a vector and a matrix, is largely which attributes are set.

Shiny is R's framework for interactive web apps. An app has a UI that describes inputs and outputs, and a server function that reacts to inputs and renders outputs. Reactivity is the core idea: when an input changes, only the outputs that depend on it recompute.

It lets analysts ship dashboards and tools without writing JavaScript. The mental model to explain is the reactive graph: inputs feed reactive expressions feed outputs, and Shiny tracks the dependencies for you.

Both weave narrative text, R code, and its output (tables, plots, results) into one document that renders to HTML, PDF, or Word. Change the data, re-render, and the whole report updates, which is the core of reproducible reporting.

Quarto is the newer, language-agnostic successor: same idea, works with R, Python, and Julia, and handles books, sites, and slides. Reaching for either instead of copying numbers into a slide deck signals reproducible-analysis habits.

browser() drops you into an interactive session at that line so you can inspect variables. debug(fn) steps through a function on its next call, and traceback() after an error shows the call stack that led to it.

options(error = recover) is the power tool: on any error it lets you jump into any frame of the call stack to see local state. In RStudio, breakpoints in the margin wrap the same machinery in a UI.

When x is empty, length(x) is 0, and 1:0 in R is the vector c(1, 0), not an empty sequence. A loop written as for (i in 1:length(x)) then runs with i = 1 and i = 0 on empty input, causing a subtle bug.

seq_along(x) and seq_len(n) return an empty sequence when there's nothing to iterate, so the loop correctly does nothing. It's a small habit that prevents a whole class of edge-case failures.