HR & Behavioural Data Science Interview Questions

Situation: in my final-year project, a teammate's cleaning script was one 600-line notebook that took 20 minutes to run. Task: I needed to reuse it for new data. Action: I split it into small functions, added docstrings, replaced row loops with vectorised Pandas code and wrote a few checks for row counts. Result: run time fell to 2 minutes and the team could reuse the functions. I learned to refactor in small, tested steps.

I start with the decision they care about, not the formula. Once a sales manager asked why a 3 percent lift was not significant. I explained that with only 200 customers, the result could easily happen by chance, like getting 6 heads in 10 coin tosses. I showed a simple range chart of the confidence interval and suggested running the test longer. He agreed, and the extended test gave a clear answer.

Situation: leadership believed a discount campaign drove a sales spike. Task: I was asked to measure its impact. Action: I compared similar regions with and without the campaign and found the spike matched a festival week in both. I shared the method, the charts and the limits openly. Result: they cut the next discount budget by half and moved it to retention. I learned to present surprising results with clear evidence and calm framing.

Situation: my demand forecasting model had 8 percent error offline, but 20 percent in the first month live. Task: find out why quickly. Action: I compared live inputs with training data and found a promotions feature arrived a day late in production, so the model saw zeros. I added a data freshness check and a fallback. Result: error returned to 9 percent. Since then I always test with production-like pipelines before launch.

Situation: I built a lead scoring model where only 3 percent of leads converted and labels came 60 days late. Task: deliver a useful ranking for the sales team. Action: I set up a clean time-based validation, engineered activity features, used gradient boosting with class weights and measured lift in the top decile. Result: the top 10 percent of scored leads converted 3.5 times better than average. The hardest part was building trust in the labels.

Situation: for a credit risk use case, my deep learning model beat logistic regression by only 0.5 AUC points. Task: recommend one for production. Action: I compared explainability, latency, monitoring effort and regulatory needs, and showed the small gain was within noise across folds. Result: we shipped a scorecard-style logistic regression that the risk team could audit. It launched three weeks earlier and was easy to maintain.

Situation: my internship project used PyTorch, but I had only used Keras. Task: build a text classifier within two weeks. Action: I followed the official tutorials for two days, rebuilt a small Keras model in PyTorch to compare, and asked a senior to review my training loop. Result: I delivered the model on time with 88 percent F1. I learned that rebuilding something familiar is the fastest way into a new tool.

Situation: we had to classify 50,000 support tickets into 12 categories with only 600 labelled. Task: reach usable accuracy in a month. Action: I used a pretrained sentence embedding model with logistic regression, then active learning to pick the most uncertain tickets for agents to label in short daily batches. Result: with 2,000 labels we reached 86 percent macro F1. I learned that smart labelling beats waiting for perfect data.

Situation: two freshers joined my team and struggled with messy real data. Task: help them deliver independently. Action: I paired with them on the first project, set up weekly code reviews, shared a checklist for validation and leakage, and gave them small end-to-end tasks with clear success metrics. Result: within three months both owned models in production. I focus on teaching how to debug and ask questions, not just giving answers.

Situation: on an insurance claims model, my first features gave average results. Task: improve fraud detection. Action: I sat with two claim investigators for a day and asked what made them suspicious. They mentioned claims filed soon after policy start and repeated garage names. I turned these into features and checked them with the team. Result: recall at the same precision rose by 12 points. Experts often know signals the data hides.

Situation: our delivery time model kept underestimating late-night orders. Task: reduce large errors. Action: I noticed restaurant prep time depended on how busy the kitchen was, so I built a feature for active orders at that restaurant in the last 30 minutes, computed point in time. Result: MAE dropped by 14 percent and late-night errors fell the most. It taught me to study the worst errors before adding generic features.

Situation: the leadership team needed festive-sale numbers by city for a 9 am review, and the dashboard pipeline had failed overnight. Task: deliver accurate numbers in three hours. Action: I queried the raw orders tables directly, reused validated logic from the dashboard SQL, cross-checked totals with finance's daily figure and flagged two cities with partial data. Result: the review went ahead on time, and I later added pipeline failure alerts.

Situation: during my internship I was building a monthly sales report. Task: make sure numbers were correct before sharing. Action: I compared order counts per day and noticed one day had double the usual orders. A GROUP BY on order_id showed every order that day appeared twice because a load job had run twice. Result: I reported it, the data team removed duplicates and added a uniqueness check. Now I always validate row counts.

Situation: as the only analyst for three teams, I received 15 ad-hoc SQL requests a week and my model work stalled. Task: protect focus without upsetting stakeholders. Action: I grouped requests, built a self-serve dashboard covering the 5 most common questions, and set up a simple weekly priority review with the managers. Result: ad-hoc requests dropped by 60 percent and the model shipped a month later as planned.

Situation: our HR team answered the same leave and policy questions daily. Task: build an internal assistant in six weeks. Action: I built a RAG pipeline over policy PDFs, added citations, created a 150-question evaluation set with HR, and iterated on chunking and reranking. Result: answer accuracy reached 91 percent and HR queries dropped by 40 percent. I learned that the evaluation set mattered more than the choice of model.

Situation: sales leaders wanted an LLM to auto-send pricing quotes to clients. Task: guide them to a safe plan. Action: I demoed real failure cases where the model invented discounts, showed accuracy numbers from a test set and proposed a draft-and-approve flow with fixed price data from our system. Result: they agreed, quote drafting time fell by half, and no wrong prices reached clients.

Situation: a pricing model had to go live before a sale in ten days. Task: deploy safely in that window. Action: I cut scope to batch scoring instead of real-time, reused our standard Docker and Airflow template, wrote tests for the key features and set up a dashboard for score distribution. Result: it went live two days early and ran without incidents during the sale. Real-time scoring followed a month later.

Situation: one morning our recommendation model started showing the same five products to all users. Task: restore service and find the cause. Action: I rolled back to the previous model version within 20 minutes, then traced the issue to an upstream table that had arrived empty, so all user features were defaults. Result: we added data volume checks before scoring and a blameless postmortem. Rollback readiness saved us that day.

Situation: marketing wanted the lead model judged on overall accuracy. Task: agree on a metric that matched the goal. Action: I showed that accuracy rewarded predicting no conversion for everyone, then proposed precision in the top 1,000 leads per week, which matched the sales team's call capacity, with a simple chart. Result: they agreed, and the model with the better top-1,000 precision added 18 percent more conversions.

Situation: my weekly demand forecast under-predicted a category by 30 percent for a month. Task: explain the miss and stop it recurring. Action: I compared forecast and actuals by region and found a new distribution channel had launched that the model knew nothing about. I told the planning team quickly, added channel as a feature and set up a weekly error review. Result: error returned to normal and planners trusted the alerts.

Situation: planners relied on a 4-week moving average and distrusted models. Task: move them to a better forecast without forcing it. Action: I ran both methods side by side for eight weeks, showed error and stockout cost in rupees, kept their override option and explained forecasts with simple drivers like holidays and price. Result: the model cut error by about 20 percent, planners adopted it category by category, and overrides fell steadily.

Situation: after presenting a retention report, I noticed I had counted test accounts as users. Task: correct it before decisions were made. Action: I reran the numbers that evening, informed my manager and the audience with a short note showing old and new figures and what changed, and added a filter and a check to the shared query. Result: the conclusion held with smaller numbers, and the team valued the transparency.

Situation: a sales head asked for a model to find good leads but could not define good. Task: turn this into a clear target. Action: I met the team, looked at past deals, and proposed converted within 60 days as the label, with expected revenue as a secondary view. I shared a quick baseline in a week to get feedback. Result: the definition was agreed, and the final model raised conversion in the top decile.

Situation: a shelf-detection model plateaued at low accuracy. Task: find out why and fix it. Action: I reviewed 500 errors and found that a third were labelling mistakes, with inconsistent boxes for partly hidden products. I rewrote the guidelines with visual examples, had a second annotator review hard images and relabelled the worst batch. Result: mAP rose by 9 points without changing the model, and labelling rework dropped sharply.

Situation: our document classifier mislabelled several legal notices, and the client was upset. Task: explain clearly and restore confidence. Action: I showed the misclassified examples, explained that they used a format absent from training data, and avoided jargon. I proposed adding those samples, a confidence threshold for human review and weekly error reports. Result: errors on that format fell sharply and the client extended the project.

Situation: the team was confident a redesigned home page would increase orders. Task: I owned the experiment design and analysis. Action: I set conversion as primary and session length and refunds as guardrails, ran it for two full weeks and found no lift in orders but a drop for older app versions. Result: we fixed the performance issue, retested, and shipped a version that raised orders by about 1.5 percent.

Situation: a team wanted to launch a feature after a test showed a 6 percent lift. Task: as the reviewing data scientist, validate it. Action: I found that assignment was triggered after users clicked into the feature, so treatment had only engaged users. I explained the selection bias simply, proposed assigning at app open, and helped rerun it. Result: the true lift was under 1 percent, and we added assignment checks to the review template.

Situation: new analysts kept misusing two similar revenue columns. Task: reduce repeated questions and errors. Action: I wrote a short data dictionary for our main tables, with definitions, known pitfalls and sample queries, and linked it in the team wiki and onboarding checklist. I updated it whenever schemas changed. Result: onboarding time dropped, and the number of revenue mismatches in reports fell noticeably within a quarter.

Situation: a team wanted an LLM to categorise transactions into 12 fixed categories. Task: recommend an approach. Action: I benchmarked an LLM against a gradient boosting model on labelled history, comparing accuracy, latency and cost per million records. The classic model matched accuracy at a fraction of the cost and ran in milliseconds. Result: we shipped it and used the LLM only for the few low-confidence cases.

Situation: each monthly retrain needed a day of manual data pulls, notebook runs and copying files to servers. Task: make it reliable and hands-off. Action: I wrapped the steps into a scheduled pipeline with data validation checks, logged runs in MLflow and added an approval step before promotion. Result: retraining time dropped from a day to under an hour of review, and there were no more failed deployments from missed steps.