DSMA Admission common mistakes
DSMA Admission · Understand the traps and how to avoid them.
Treating correlation as sufficient evidence of causation when asked to interpret an observational result, and writing the conclusion as if the predictor caused the outcome.
Candidates carry over intuition from controlled experiments and from ML feature-importance output, which ranks predictive association but says nothing about intervention effects. Confounders and reverse causality are invisible in a correlation coefficient.
What to do instead
Before writing any interpretive sentence, explicitly list plausible confounders and the study design (observational vs. randomised). Phrase conclusions as association unless randomisation or a valid identification strategy is present, and state what additional evidence would be needed for a causal claim.
Reporting a p-value as the probability that the null hypothesis is true, or as the probability the result was due to chance.
The definition is counterintuitive and commonly misremembered under time pressure; the p-value is computed assuming the null is true, so it cannot be the probability of the null.
What to do instead
Memorise the conditional direction: p = P(data at least this extreme | H0). Practise rewriting flawed sentences into correct ones, and always pair a p-value with an effect size and confidence interval so the interpretation is anchored to magnitude, not just significance.
Ignoring base rates in diagnostic or screening questions and answering with sensitivity alone (the false-positive fallacy).
Sensitivity and specificity are properties of the test, while the question usually asks for the positive predictive value, which depends heavily on prevalence. The base-rate information is often stated in a separate sentence that candidates skim past.
What to do instead
When a question mentions a test, a rare condition, and a population, immediately build a 2x2 table with a concrete N (e.g., 10,000 people) and fill in the cells. Compute PPV from the table rather than from formulas, which makes the base-rate effect visible.
Using INNER JOIN as the default when the question requires retaining unmatched rows, silently dropping records and changing aggregate totals.
Inner joins are the most practised pattern, and the difference only surfaces when the result is aggregated or counted. Candidates also forget that a WHERE filter on the right-hand table of a LEFT JOIN converts it into an inner join.
What to do instead
Before writing the query, state in one line which side must be preserved and whether unmatched rows should appear. Put right-table filters in the ON clause (not WHERE) for outer joins, and sanity-check row counts against the base table.
Misjudging how NULL behaves in comparisons, aggregates, and joins, e.g., writing col != 'x' and expecting NULL rows to be returned, or expecting COUNT(col) to equal COUNT(*).
Three-valued logic is not intuitive, and many practice environments have no NULLs, so the behaviour is never observed. AVG and COUNT silently exclude NULLs rather than erroring, so the bug is invisible.
What to do instead
Treat NULL explicitly: use IS NULL / IS NOT NULL, COALESCE for defaults, and decide per column whether NULL means missing or zero. Verify with a small table containing NULLs and compare COUNT(*) against COUNT(col) and AVG(col) against AVG(COALESCE(col,0)).
Assuming GROUP BY output order is guaranteed, or filtering on an aggregate alias in WHERE instead of HAVING.
Query results often appear sorted by accident on small datasets, and the logical order of execution (FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY) is rarely rehearsed. WHERE is evaluated before aggregation, so aggregate filters there fail or mislead.
What to do instead
Always add an explicit ORDER BY when order matters, and place aggregate conditions in HAVING. Rehearse the logical execution order until it is automatic, and use it to predict which aliases are visible at each stage.
Leaking information across train and test by fitting scalers, imputers, or feature selectors on the full dataset before splitting, then reporting optimistic performance.
The preprocessing code runs cleanly and produces better numbers, so nothing signals an error. Candidates also split after imputation because it is the convenient code order.
What to do instead
Split first, then fit every transformer on the training fold only and apply it to validation/test (pipelines enforce this). When cross-validating, put preprocessing inside the pipeline so it is refit per fold, and state the split strategy explicitly in any write-up.
Choosing accuracy as the evaluation metric on imbalanced data and concluding a model that predicts the majority class is strong.
Accuracy is the default in most tutorials and libraries, and a 95% accuracy figure looks impressive until the 5% base rate is considered. The metric choice is rarely questioned once a number appears.
What to do instead
State the class balance first, then pick metrics matched to cost: precision/recall or F1, PR-AUC, or a confusion matrix with per-class counts. Always compare against a majority-class baseline so the reported gain is meaningful.
Describing a chart by reading its axis labels aloud ('sales went up') instead of stating the comparison, magnitude, and uncertainty the audience needs for a decision.
Candidates confuse describing the visual encoding with communicating a finding, and under exam time pressure they default to the safest literal statement.
What to do instead
Use a claim-evidence structure: one sentence with the takeaway and magnitude ('conversion rose 12 points, from 30% to 42%, after the change'), then the evidence, then the caveat. Delete any sentence that only restates the axis.
Omitting the ethical and governance framing when a scenario involves personal data, proxies for protected attributes, or model deployment, and answering purely as a technical optimisation problem.
Technical training rewards the best metric, so candidates optimise accuracy or profit and treat consent, purpose limitation, minimisation, and disparate impact as out of scope. Governance terms are also less practised than code.
What to do instead
For any scenario involving people, run a fixed checklist: lawful basis and consent, purpose limitation, data minimisation, retention, access controls, and impact on subgroups. Name the specific risk and a concrete mitigation (e.g., remove the proxy feature, audit error rates by group) rather than a generic call for fairness.