Dell Data Science Associate common mistakes
Dell Data Science Associate · Understand the traps and how to avoid them.
Treating correlation between two features as proof that one causes the other, or dropping a feature purely because it correlates with another, without checking whether the relationship is confounded or whether the correlated pair carries complementary signal.
Candidates carry over informal intuitions from statistics coursework where correlation is taught alongside regression, and the exam deliberately plants pairs of correlated business metrics (e.g., marketing spend and revenue) to test whether the candidate distinguishes association, confounding, and predictive redundancy. Under time pressure, the shortcut is to assume the correlated feature is 'the same thing'.
What to do instead
For any correlation question, explicitly ask three questions before answering: (1) Is there a plausible common cause? (2) Is the correlation measured on the same unit and time window? (3) For modeling, does the second feature add explained variance beyond the first (check partial correlation or compare model performance with and without it)? Practice by writing one sentence for each correlated pair naming the confounder or ruling it out.
Choosing the wrong summary statistic or chart for a skewed distribution, for example reporting the mean and standard deviation for income-like data, or using a pie chart for many-category or non-part-to-whole data.
Default tooling (describe(), bar charts) produces mean and standard deviation automatically, and candidates rarely inspect the distribution shape first. Exam items describe a business scenario and expect the candidate to notice skew, outliers, or categories that do not sum to a whole, but candidates answer from habit rather than from the described shape.
What to do instead
Adopt a fixed pre-answer checklist: plot or reason about the distribution shape, check for outliers and zero-inflation, confirm whether categories are mutually exclusive and exhaustive, then select the statistic (median and IQR for skewed data) or chart (histogram, box plot, sorted bar chart). For every practice item, write down the distribution shape before looking at the options.
Confusing population parameters with sample statistics, or misapplying the central limit theorem to a small or heavily skewed sample, when interpreting a confidence interval or a p-value.
The formulas look similar and candidates memorize procedures without tracking what is random (the estimator) versus fixed (the parameter). Exam items often describe a small sample from a skewed population and offer a normality-based interval as a distractor; candidates pick it because it is the formula they rehearsed most.
What to do instead
Before computing, annotate each quantity as parameter or statistic and check the sample size and shape against the assumption. State in words what the 95% interval means ('if we repeated sampling, 95% of such intervals would contain the true mean') and what a p-value is not (not the probability the null is true). Drill with small-sample and skewed-population scenarios until the assumption check becomes automatic.
Handling missing data by dropping every row with a null or filling every null with the column mean, without considering the mechanism (MCAR, MAR, MNAR) or the effect on variance and bias.
Single-line pandas or SQL operations make listwise deletion and mean imputation the path of least resistance, and candidates often have not been taught to reason about why data is missing. Exam items describe missingness tied to a group (e.g., high-income respondents skip the income question) where mean imputation or deletion biases the result.
What to do instead
For each missing-data scenario, first classify the mechanism from the described context, then choose a method: complete-case analysis only if missingness is plausibly unrelated to the variables of interest; conditional imputation (group mean, regression, or multiple imputation) for MAR; explicit missing-indicator or sensitivity analysis for MNAR. Practice articulating the bias direction each naive method would introduce.
Leaking target information across the train/test split, or fitting scalers, encoders, and imputers on the full dataset before splitting, and then reporting optimistic performance.
Tutorial code frequently scales or imputes before splitting because it is convenient, and candidates copy that pattern. The exam presents a pipeline description or a suspiciously high score and expects the candidate to spot the leak; candidates instead accept the score or misidentify the leak as a modeling choice.
What to do instead
Memorize the invariant: split first, then fit every transformation on the training fold only and apply it to validation and test folds (use pipelines to enforce this). When reviewing any described workflow, trace each step and ask whether it saw test data. Also flag leakage from time ordering (random split on time-series data) and from duplicate or group-linked records.
Misdiagnosing bias versus variance from training and validation error patterns, for example calling a model with low training and high validation error 'underfitting' or fixing high bias by adding more features.
The vocabulary is easy to memorize but the diagnostic mapping is not, and candidates often conflate 'the model performs poorly' with a specific cause. Exam items give a pair of error numbers and expect the correct remedy; candidates pattern-match on the word 'error' rather than comparing the two numbers.
What to do instead
Use a fixed decision rule: large gap between training and validation error means variance (regularize, simplify, add data); both errors high and close means bias (add capacity or better features). Write the rule down and apply it to at least ten synthetic error pairs, stating the diagnosis and the remedy each time before checking the answer.
Treating accuracy as the primary metric on imbalanced classification problems, or reporting a single aggregate metric without per-class breakdown.
Accuracy is the default in most libraries and tutorials, and candidates rarely compute the baseline rate of the majority class. Exam items describe fraud or failure-detection scenarios with a small positive rate and offer accuracy as a tempting distractor; candidates select it because it is the metric they trust most.
What to do instead
Always compute and state the majority-class baseline before evaluating any classifier. Then select the metric from the cost structure: precision or recall (and their trade-off via the threshold) when false positives and false negatives have different costs, F1 or balanced accuracy for a single summary, and PR curves rather than ROC curves when positives are rare. Practice by writing the cost of each error type for the described business case.
Writing SQL or data-transformation logic that silently changes row counts, for example an inner join that drops unmatched records, an aggregation without grouping on all non-aggregated columns, or a filter applied before rather than after aggregation.
Candidates focus on getting a syntactically valid query rather than on the grain of the result, and they do not mentally execute the row counts. Exam items describe source tables and ask for an output; the plausible distractor is a query that runs fine but returns the wrong grain or silently loses rows.
What to do instead
Before writing the query, state the grain of the input tables and the required grain of the output. After writing it, trace row counts through each join (check for fan-out and dropped keys) and confirm the GROUP BY covers every non-aggregated column. Practice by writing the expected row count next to each query stage and comparing with the result.
Presenting model output to a business audience as raw technical metrics (AUC, RMSE, p-values) without translating them into the decision, the expected impact, or the uncertainty the audience should care about.
Candidates are trained to optimize and report metrics and often have little practice framing findings around a decision. Exam items describe a stakeholder and ask what to communicate; candidates pick the most technically complete answer rather than the one that supports the decision and states its limits.
What to do instead
Structure every communication answer as: decision being supported, finding in business units (e.g., expected lift, cost saved, customers affected), confidence and key caveat, and recommended next step. Convert at least one metric into a business quantity in each practice scenario, and explicitly name the assumption behind the conversion.
Confusing statistical significance with practical or business significance, or recommending rollout of a change based on a significant test result without checking effect size, segment heterogeneity, or the cost of the intervention.
Hypothesis-testing coursework emphasizes p-values and decision thresholds, so candidates equate 'significant' with 'worth doing'. Exam items pair a small p-value with a tiny effect or a costly intervention and expect the candidate to weigh magnitude and cost, but candidates stop at the p-value.
What to do instead
For every A/B or experiment scenario, report four things: effect size in business units, confidence interval, p-value, and the cost or risk of acting. Check whether the effect is consistent across described segments and whether the test ran long enough. Practice by writing a one-line go/no-go recommendation that cites effect size and cost, not just significance.