EXIN BCS ML Award common mistakes
EXIN BCS ML Award · Understand the traps and how to avoid them.
Treating 'machine learning' and 'traditional programming' as the same thing, or defining ML as 'a computer that thinks like a human', rather than as systems that improve task performance by learning patterns from data instead of following explicitly coded rules.
Candidates skim the introduction domain because it feels like preamble, then rely on everyday intuitions about AI from media. The exam deliberately tests the precise distinction between rule-based programming (logic written by a developer) and model induction (parameters fitted from examples), and vague definitions lose marks.
What to do instead
Write out the two pipelines side by side: traditional = data + rules -> answers; ML = data + answers (labels/targets) -> rules (model). Practise classifying scenarios (spam filter, tax calculation, recommendation) into the correct pipeline, and be able to state that the learned artefact is a model with parameters, not hand-coded logic.
Confusing supervised, unsupervised, and reinforcement learning when the scenario is phrased in business language - e.g. labelling customer segmentation as supervised because 'we know our customers', or calling a labelled churn prediction unsupervised because no human writes the rules.
The learning-type definitions are learned as vocabulary rather than as a decision rule based on the presence of target labels and the type of feedback. Exam scenarios hide the signal in narrative, so candidates match on surface words like 'customers' or 'predict' instead of asking whether labelled outcomes exist.
What to do instead
Apply a fixed two-question test: (1) Are there labelled target values for the training examples? If yes, supervised; if no labels and the goal is structure, unsupervised; if an agent learns from reward through interaction, reinforcement. (2) Is the target categorical (classification) or numeric (regression)? Drill on short scenarios until the test is automatic.
Confusing classification with regression, or confusing the evaluation metric - reporting accuracy for an imbalanced classification problem, or using R-squared to judge a classifier - instead of selecting the metric that matches the target type and class balance.
Candidates memorise metric formulas without linking them to the prediction task. In imbalanced data (e.g. 1% fraud), a model predicting 'not fraud' always scores 99% accuracy, so accuracy looks excellent while the model is useless; exam items exploit exactly this trap.
What to do instead
Build a metric-selection table: numeric target -> MAE/RMSE/R-squared; categorical target -> confusion matrix, precision, recall, F1, and for ranking or imbalance also ROC-AUC or precision-recall curves. For every practice question, first name the target type and class balance, then choose the metric, and be ready to explain why accuracy misleads on skewed classes.
Mixing up overfitting and underfitting, or prescribing the wrong remedy - e.g. answering 'add more features' for overfitting, or 'increase model complexity' when both training and test error are high.
The bias-variance trade-off is understood qualitatively but not as a diagnostic procedure based on the gap between training and test performance. Candidates answer from the word 'overfitting' rather than from the error pattern described in the scenario.
What to do instead
Memorise the diagnostic: low training error + high test error = overfitting (high variance) -> simplify the model, add regularisation, get more data, reduce features; high training error + high test error = underfitting (high bias) -> use a more expressive model or better features. Practise reading described error patterns and naming the diagnosis before the remedy.
Treating data preparation as optional or as a single step - skipping train/test splitting before preprocessing, fitting a scaler on the full dataset, or ignoring missing values and class imbalance - and then reporting an optimistically biased score.
Candidates focus on algorithms because they seem more technical, and underestimate how much of the practical domain is data quality. Leakage from preprocessing on the full dataset is subtle and rarely demonstrated in casual tutorials, so the exam's leakage questions catch them out.
What to do instead
Learn the rule 'split first, then preprocess': fit scalers, encoders, and imputers on the training set only and apply them to the test set. Be able to name standard remedies for missing data (deletion, mean/median/mode imputation, model-based imputation), for imbalance (resampling, class weights, threshold tuning), and for categorical variables (one-hot vs label encoding).
Misreading Python indexing and slicing, or confusing zero-based positions with the values stored in the data - e.g. assuming data[0] is the first row of a DataFrame with a non-default index, or expecting slicing to include the end position.
The programming domain assumes fluency in basic Python and library conventions, but many candidates come from a business or process background. Slicing is end-exclusive and pandas label-based indexing behaves differently from positional indexing, so small syntax assumptions produce wrong answers.
What to do instead
Revise the specific conventions: list and NumPy slicing excludes the stop index; pandas .iloc is positional and .loc is label-based; a slice of a list returns a new list while assignment modifies in place. Run short snippets in a REPL and predict the output before executing, focusing on off-by-one and index-versus-position cases.
Writing or interpreting a scikit-learn workflow with the wrong method names - calling fit() and predict() on the wrong object, using predict() when predict_proba() is needed for probabilities, or forgetting that transformers use fit/transform while estimators use fit/predict.
The API is consistent but candidates learn it by copying examples rather than by understanding the fit/transform/predict contract. Exam items often hinge on which object owns which method, especially inside pipelines and for probability outputs.
What to do instead
Map the API explicitly: estimators implement fit() and predict(); transformers implement fit(), transform(), and fit_transform(); classifiers that support probabilities expose predict_proba(). Practise writing a short pipeline (scaler, then classifier) from memory and describe what each call does and on which data it is fitted.
Assuming a more complex or higher-accuracy model is automatically the right production choice, ignoring interpretability, latency, cost, and the business objective - e.g. recommending a deep network for a small tabular dataset where a simple model performs comparably.
Candidates equate sophistication with quality and treat accuracy as the only objective. The practical-applications domain tests whether the candidate can weigh model choice against deployment constraints, explainability requirements, and data volume.
What to do instead
For each scenario, state the objective and constraints before the algorithm: data size, need for explanation to stakeholders or regulators, inference speed, maintenance cost. Learn that simple models (linear/logistic regression, decision trees) are strong baselines and often preferred for tabular data and regulated contexts, and justify any complex model by a measured gain.
Confusing correlation with causation, or claiming a model 'proves' a relationship - e.g. concluding that a feature causes the outcome because it has high importance, or that a predictive model can replace a controlled experiment.
Feature importance and correlation coefficients are easy to read as causal evidence, and candidates without statistics background accept the intuitive but wrong interpretation. The exam tests whether the candidate can state the limits of observational, predictive modelling.
What to do instead
State the rule: predictive models exploit association, not causation; feature importance shows contribution to prediction within that model and can be distorted by correlated features. Be able to say what would be needed for causal claims (controlled experiment or explicit causal design) and to phrase conclusions as 'associated with' rather than 'causes'.
Mishandling the confusion matrix - swapping false positives and false negatives, or choosing the wrong error type to minimise for the context (e.g. optimising precision when missing a positive case is the costly outcome in a medical screening scenario).
The terms are symmetric and easy to reverse under time pressure, and candidates memorise precision and recall as formulas without anchoring them to the cost of each error type. Scenario questions reward reasoning about consequences, not formula recall.
What to do instead
Anchor the definitions: false positive = predicted positive but actually negative; false negative = predicted negative but actually positive. Recall = TP/(TP+FN) and matters when missing positives is costly; precision = TP/(TP+FP) and matters when false alarms are costly. For each practice scenario, state which error is more expensive before selecting the metric or threshold.