Data Science Researcher Interview Questions for AI Training Work

I first check whether the missingness is random or systematically related to some other variable, since the right imputation strategy depends entirely on that. Data missing not at random requires modeling the missingness mechanism itself, not just filling gaps with a mean or median, since naive imputation in that case can quietly bias the downstream analysis.

I start from domain reasoning about what should plausibly predict the target, rather than generating features blindly and letting feature selection sort it out later. Interaction terms and ratios between raw fields often carry more signal than the raw fields alone, but I validate each engineered feature's actual contribution rather than assuming a reasonable-sounding feature is automatically useful.

I run the appropriate significance test given the data type and sample size, and I'm careful about multiple comparisons, since testing many patterns increases the chance of finding a spurious one purely by chance. A pattern that looks compelling visually still needs to survive a properly corrected statistical test before I'd treat it as a real finding.

I check row counts and key summary statistics at each stage of the pipeline against the previous stage, so an unexpected drop or shift is caught immediately rather than discovered downstream. Spot-checking individual records through the full pipeline, not just aggregate counts, also catches transformation bugs that aggregate checks alone would miss.

Observational analysis works when strong confounders can be reasonably ruled out or statistically controlled for, but a genuine causal question usually needs a controlled experiment to be answered with confidence. I'm explicit about which type of question I'm actually able to answer with the available data, rather than presenting a correlational finding as if it settles a causal question.

I'd stop and communicate the issue immediately rather than trying to quietly patch around it or finish the analysis first, since decisions may already be pending on preliminary results. I'd reassess which findings are still valid despite the issue and which need to be redone once the data quality problem is fixed.

I'd give the honest, uncertain answer along with a clear explanation of what would be needed to get more certainty, rather than rounding an uncertain finding into a false definitive statement. A stakeholder can make a good decision with an honestly uncertain answer, but not with a confidently wrong one.

I'd treat the disproven hypothesis as a real finding worth reporting rather than searching for a way to salvage the original narrative. A well-documented negative result, backed by clean data wrangling and sound analysis, is more valuable to the research than forcing a conclusion the data doesn't actually support.

While cleaning a dataset, I found that a significant portion of records had a timestamp field recorded in the wrong timezone due to an upstream system change, which had been silently skewing a time-based analysis. Catching it during the wrangling stage, rather than after drawing conclusions, redirected the project toward fixing the data pipeline before any further analysis was trustworthy.

For a research question with a modest sample size, I chose a simpler, well-understood test over a more complex model that would have required assumptions the data couldn't really support at that scale. The simpler method gave a result I could actually defend, while the more sophisticated approach would have looked impressive but rested on shakier ground.