TASC Data Science and Digital Solutions study materials
TASC Data Science and Digital Solutions study resources

TASC Data Science and Digital Solutions common mistakes

TASC Data Science and Digital Solutions · Understand the traps and how to avoid them.

Mistake 1

Treating correlation coefficients as proof of causation when interpreting a statistical finding, and recommending an intervention based on a strong r value alone.

Correlation is the most visually salient statistic in exploratory output, and candidates under time pressure default to the intuitive 'these move together, so one drives the other' shortcut instead of checking for confounders, study design, or temporal ordering.

What to do instead

Before writing any conclusion, name at least one plausible confounder and state what evidence (randomisation, temporal precedence, controlled comparison) would be needed to support a causal claim. Practise rewriting correlational findings as explicit non-causal statements.

Mistake 2

Confusing precision with recall when asked to evaluate a classifier, reporting accuracy or precision as the answer to a question about missed positive cases.

The metric names are abstract and the confusion-matrix layout is easy to misread under exam conditions, so candidates substitute the metric they remember best rather than translating the business wording ('we cannot miss fraud cases') into the correct metric.

What to do instead

Drill the translation step: write out the confusion matrix in words (true positives, false positives, false negatives) and map the question's cost statement onto the cell that hurts. If false negatives are the stated cost, the answer is recall or sensitivity.

Mistake 3

Assuming a dataset is clean and complete, then running an analysis or model without checking for missing values, duplicates, or inconsistent categories.

Exam vignettes often describe a dataset in neutral language, and candidates want to move straight to the modelling step because that is the part they have studied most, skipping the unglamorous profiling stage.

What to do instead

Adopt a fixed checklist for any data-handling scenario: row count, missingness per column, duplicates, type consistency, outliers, and class balance. State the check explicitly even when the question does not ask, because answer options often hinge on a data-quality defect.

Mistake 4

Choosing a complex model or the newest-sounding algorithm when the scenario describes small data, limited compute, or a need for interpretability.

Candidates equate sophistication with correctness and may not have practised matching model complexity to constraints such as sample size, regulatory explanation requirements, or latency budgets.

What to do instead

Build a decision table linking constraints to model families: small n and interpretability needs point to regularised linear models or trees; large n and unstructured data point to deep learning. In the exam, extract the constraints from the prompt first, then select.

Mistake 5

Ignoring class imbalance and accepting a high accuracy figure for a model on a rare-event problem.

Accuracy is the default metric reported in introductory examples, so a headline number like 97 percent reads as success even when the minority class is almost never predicted.

What to do instead

Always compute the naive baseline (predicting the majority class) before trusting accuracy. If the positive rate is low, switch to precision, recall, F1, or a cost-weighted measure, and say so explicitly in the answer.

Mistake 6

Treating a training-set performance figure as evidence of generalisation, or tuning on the test set and reporting that score as final.

The workflow stages blur together in memory, and candidates who have not internalised the train/validation/test separation reuse the same holdout repeatedly because it feels efficient.

What to do instead

Recite the roles aloud: training fits parameters, validation selects hyperparameters, test is touched once for an unbiased estimate. When a scenario reports a suspiciously high score, check whether the evaluation data was also used for tuning.

Mistake 7

Proposing a technical solution to a problem that is actually organisational, such as recommending a new dashboard when the stated issue is unclear ownership of data definitions.

Candidates over-index on the technical content they are being tested on and treat every scenario as a modelling problem, missing governance, process, and stakeholder signals in the prompt.

What to do instead

Classify the problem before answering: is the gap in data, model, process, or people? Practise prompts where the correct answer is a data dictionary, an ownership agreement, or a validation step rather than an algorithm.

Mistake 8

Describing a machine-learning pipeline without addressing data privacy, consent, or bias checks, even when the scenario involves personal or sensitive attributes.

Ethics and compliance content is often studied as a separate topic and not integrated into technical answers, so candidates answer the modelling question and stop there.

What to do instead

Attach a standard governance paragraph to any design answer: lawful basis and consent, minimisation of personal data, protected-attribute bias testing, human review for high-stakes decisions, and monitoring after deployment.

Mistake 9

Misreading a chart or summary table, for example comparing absolute values across groups of very different sizes instead of comparing rates.

Raw counts are printed more prominently than denominators, and candidates read the largest number as the most important without normalising.

What to do instead

For every quantitative comparison, state the denominator before drawing a conclusion. Convert counts to rates or per-capita figures and check whether the ranking changes; if it does, the rate is the defensible answer.

Mistake 10

Recommending deployment of a model without a monitoring, retraining, or rollback plan, treating the project as finished at the modelling stage.

Coursework and practice questions concentrate on model building, so the operational lifecycle after launch is under-rehearsed and candidates do not think to mention data drift or performance decay.

What to do instead

End every solution with an operations sentence covering drift detection, scheduled retraining, alert thresholds, and a rollback path. Memorise this as a template so it appears automatically in any deployment scenario.