HR & Behavioural R Programming Interview Questions

Situation: my team spent two days every month building a sales report in Excel. Task: I was asked to reduce the effort. Action: I wrote an R script that pulled data from the database with DBI, cleaned it with dplyr, created charts with ggplot2 and rendered a Quarto report scheduled through cron. Result: the report ran in ten minutes, copy-paste errors disappeared and the team used the saved time for deeper analysis.

I chose R because I enjoy working with data and statistics, and R is designed exactly for that. During my coursework I used it for a project analysing student performance, where dplyr and ggplot2 helped me move from raw data to clear insights quickly. I like that results are reproducible with R Markdown. I am also learning SQL and basic Python, so I can work comfortably in a mixed team and pick the right tool for each task.

Situation: while preparing a monthly revenue dashboard, totals were 8 percent higher than finance figures. Task: find the cause before the review meeting. Action: I traced row counts after each step in my R script and found a join on customer ID that duplicated rows because some customers had two active addresses. I deduplicated the address table and added a row-count check. Result: numbers matched finance, and the check now runs in every refresh.

I start with the business question and the answer in one sentence, then show one or two clear charts instead of tables of coefficients. For example, in a college project on customer churn, I said that customers with more than three complaints were twice as likely to leave, showed a simple bar chart and suggested a follow-up call process. I keep technical details in an appendix and invite questions so managers can decide confidently.

Situation: two managers needed different analyses on the same Friday. Task: deliver both without compromising quality. Action: I asked each what decision the analysis would support and the minimum needed by Friday, reused one cleaned dataset in R for both, and shared a draft of the simpler one on Wednesday for early feedback. Result: both received usable outputs on time, and the fuller version of the second analysis followed on Monday as agreed.

Situation: I received three years of vendor invoices from different branches in Excel files with inconsistent headers, merged cells and dates in four formats. Task: build one clean table for spend analysis. Action: I used readxl to read all sheets, janitor::clean_names() to standardise headers, lubridate to parse dates and a mapping table for vendor name variants. I wrote validation checks for totals. Result: a clean dataset of 180,000 rows that finance now refreshes monthly.

Situation: I shared a retention analysis showing improvement, but a week later I noticed I had excluded customers with missing signup dates, who were mostly churned users. Task: correct it before decisions were made. Action: I informed my manager immediately, reran the analysis with proper handling, explained the impact clearly and added a missing-value check to my template. Result: the corrected numbers were used, and my manager appreciated the transparency.

Situation: the operations team believed late deliveries were spread evenly across the week. Task: I was asked to review delivery data. Action: in R I built a heatmap of late deliveries by weekday and hour with ggplot2, which showed a sharp cluster on Monday mornings linked to weekend order backlog. Result: management added a Sunday evening shift, and late deliveries dropped by about 18 percent the next quarter.

I would thank them and ask which part was unclear, such as too many colours, missing labels or an unclear message. In my internship this happened with a crowded chart of twelve product lines. I simplified it by highlighting the top three, greying the rest, adding a clear title stating the finding and labelling values directly. My manager found the new version easy to present, and I now review every chart for one clear message.

Situation: a marketing head expected a new campaign to have doubled sign-ups. Task: evaluate its impact. Action: my analysis in R using a pre-post comparison with a control region showed only a 6 percent lift, much of it seasonal. I presented the method and confidence interval openly, acknowledged what went well and suggested a cleaner randomized test. Result: the stakeholder accepted the finding, and the next campaign was run as a proper experiment.

I revise core concepts from a standard textbook and practise each method in R on public datasets, so I understand both the theory and the code. For example, after learning hypothesis testing, I reproduced published A/B test results from Kaggle datasets. I follow the R Weekly newsletter and read package vignettes. When I meet a method at work that I do not understand, I note it and study it that weekend.

Situation: in my first quarter, a senior reviewed my R reporting script. Task: address the review comments. Action: the main feedback was that my 300-line script mixed data loading, cleaning and plotting with repeated code. I split it into small functions, added input checks and moved constants to a config file. Result: the next report took half the time to build, and I now structure every new script this way from the start.

Situation: during my final-year project, our group's R code ran very slowly on a large dataset. Task: I was responsible for the cleaning step. Action: a teammate showed me how to replace my nested for loops with vectorized dplyr operations and explained why loops were slow. I practised the approach on other parts of the code. Result: processing time fell from twenty minutes to under one, and I shared the lesson with the rest of the group.

Situation: a lending team wanted to reduce early loan defaults. Task: build a default risk score. Action: I cleaned two years of loan data with dplyr, engineered features like EMI to income ratio with recipes, compared logistic regression and ranger in tidymodels using 5-fold cross-validation and chose logistic regression for interpretability with AUC 0.78. Result: the score was used in a pilot, flagging 60 percent of defaulters in the riskiest 20 percent of applicants.

I have practical R skills, not just theory. In my projects I cleaned real datasets with dplyr, built ggplot2 dashboards and ran regression and hypothesis tests, and I can explain results simply. I also know SQL, which most analytics work needs. I learn quickly, accept feedback well and care about accuracy, so I double-check numbers before sharing them. I am ready to start contributing to reporting tasks from the first month.

Situation: a demand model I built performed well in testing but its errors doubled two months after launch. Task: diagnose and fix it. Action: I compared input distributions and found a new product category and a pricing change that the training data never saw. I added drift monitoring, retrained with recent data and set up monthly retraining. Result: accuracy returned to target, and I learned to plan monitoring before deployment, not after.

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.

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.

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.

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.