What a data science viva can test
A data science viva is an opportunity to explain how you would make and evaluate decisions with data. The exact format depends on your course or institution: there is no single international data science viva syllabus or marking scheme. Check your course handbook, assessment brief and official guidance for the format, topics and criteria that apply to you.
The questions below practise skills that transfer across many data science assessments: framing a problem, identifying risks in the data, choosing an evaluation method, and explaining limitations. They are not a substitute for your course’s requirements. Replace the scenarios with the methods and terminology used in your own notes.
For a useful answer, state your decision, explain the evidence behind it, and name what could change your conclusion. Avoid reciting a metric or algorithm without connecting it to the problem. If you need more information, say what you would ask for and how the answer would affect your approach.
In MySummaries, a board made from your course material can supply the source notes for viva practice; the examiner strip below shows how a practice session can focus on a few technical habits.
A practice examiner strip for this subject looks like this:
The emphasis list is a practice focus, not a universal or official marking rubric. For your own assessment, use the criteria published by your course or examiner.
Build stations from problems, not topic labels
A station should give you a decision to defend. “Explain classification” is too broad to rehearse well. A concrete scenario forces you to choose a target, identify what information is available at prediction time, select a useful evaluation method, and discuss what can go wrong.
Use a simple speaking structure:
- Frame the task: Who needs the prediction, when, and what action follows?
- Check the data: Define the target and prediction time; look for leakage, missingness, imbalance and sampling problems.
- Choose and justify: State a baseline, validation design and metric that fit the use case.
- Interpret and qualify: Explain the result in plain language, identify uncertainty and name a next check.
Practise aloud, not only in writing. A concise answer can still be complete if it makes the chain from problem to decision clear. When you are unsure, distinguish what you know from what you would verify. That is stronger than guessing at a threshold or claiming that one metric proves a model is ready.
A set of stations built around decisions rather than broad chapter headings looks like this:
Station 1: time leakage in churn prediction
This station tests whether you can define a prediction moment and keep information from the future out of both features and validation. A common weak answer jumps straight to an algorithm. Begin with what “likely to cancel” means operationally: a prediction made on a particular date about a defined future window.
A strong answer should also distinguish a random split from a time-based split. If the intended use is to predict future customers or periods, a random split can give an overly optimistic result when patterns from the same time period appear in both sets. Mention a simple baseline before proposing complexity, and state how the chosen metric would help the business make a decision.
A marked practice response to the churn station looks like this:
Examiner
A subscription company wants to identify customers likely to cancel in the next 30 days. How would you design a model and make sure its evaluation represents future use?
Defines a 30-day cancellation target and links the prediction to retention action.
ImproveSpecify the snapshot date and exactly which event counts as cancellation.
Recognises that post-snapshot events must not enter the features.
ImproveGive an example: exclude a cancellation-processing timestamp recorded after the prediction date.
Chooses a chronological holdout and proposes a simple baseline.
ImproveState that all feature construction must use information available at each snapshot.
Connects recall and precision to retention capacity but does not fully explain calibration.
ImproveDescribe how you would check whether predicted probabilities correspond to observed churn rates.
A strong answerI would define a prediction snapshot for each customer and label whether cancellation occurs in the following 30 days. Every feature must be available at that snapshot; I would exclude later information such as a cancellation-processing event or a support outcome recorded afterwards. I would compare a simple baseline with a more flexible model and use a chronological holdout, keeping feature construction inside each training period. I would report precision and recall at a threshold matched to the retention team’s capacity, and check calibration if the scores are presented as probabilities. I would also inspect performance across relevant customer groups and revisit the design if the intervention changes customer behaviour.
That is a MySummaries station, filled with data science material. Yours is written from your own notes. Start free
The model answer makes a conditional recommendation rather than claiming that one metric settles the question. In your own version, be prepared to explain how you would choose the date split and why the available features could realistically exist at prediction time. A useful follow-up is: what would you do if the company’s retention action itself changes cancellation rates? Explain that the observed outcome after intervention may no longer represent the outcome without intervention, so the evaluation and experiment design need to account for that distinction.
Station 2: evaluating rare-event fraud detection
This station tests whether you can avoid relying on accuracy when the positive class is rare. It also asks you to connect threshold choice to consequences: missed fraud and unnecessary investigation are not equivalent errors, and the costs depend on the organisation’s workflow.
Say how you would evaluate ranking and the chosen operating point. The area under the precision–recall curve can be useful when the positive class is rare; report precision and recall at a selected threshold as well. The threshold should be chosen using validation data and an explicit operational or cost-based objective, not tuned on the final test set. Explain why the test set remains untouched until the final evaluation.
A marked answer to this station shows how those ideas can be spoken through:
Examiner
Fraud is uncommon, but missed fraud is costly and false alarms create review work. How would you evaluate a classifier and choose an operating threshold?
Rejects accuracy as the only measure and names precision and recall.
ImproveAdd precision–recall analysis and report the positive-class prevalence alongside results.
Recognises that the review team has limited capacity but does not state how the threshold is selected.
ImproveChoose a threshold on validation data against a stated review-capacity or cost objective.
Keeps a final test set separate from model selection.
ImproveCheck that splitting reflects time and repeated customers or transactions where relevant.
Mentions changing fraud patterns but gives few monitoring signals.
ImproveTrack alert volume, precision after investigation and changes in input or outcome distributions.
A strong answerI would first establish the fraud prevalence and the cost of a missed case compared with the cost of a false alert. Accuracy alone could look high simply because most transactions are not fraud. I would compare a baseline with candidate models using a precision–recall curve, then report precision and recall at an operating threshold that the review team can handle. I would select that threshold on validation data using the agreed capacity or cost objective and leave the final test set untouched. I would also check whether the split reflects time and repeated entities, and monitor alert volume and confirmed outcomes because fraud patterns can change.
The key improvement is to make “choose a threshold” concrete. In a viva, you do not need to invent a cost value the scenario has not supplied. Say what information you need, such as the review team’s capacity or the relative cost of missed fraud, then describe how it would determine the operating point. If you mention oversampling or class weights, clarify that these are training choices; evaluate on data that reflects the intended real-world prevalence.
Station 3: a model whose risk predictions are too low
This station tests the difference between discrimination and calibration. A similar ROC AUC does not establish that predicted probabilities remain reliable. If a model predicts a 4% event risk on a group of cases but the mature observed rate is 7%, that discrepancy deserves investigation; it does not, by itself, identify the cause or prove that one particular fix is safe.
First check that the comparison is valid: are outcomes fully observed, is the population comparable, and are the prediction horizon and outcome definition unchanged? Then examine calibration over time and relevant subgroups, along with changes in inputs and the data pipeline. If the evidence supports recalibration or retraining, validate the change on suitable later data and consider the consequences of acting on altered scores.
A marked response to the monitoring station looks like this:
Examiner
A deployed default model still has a similar ROC AUC, but observed default rates are higher than predicted. What would you investigate and do next?
Explains that similar ranking performance does not guarantee accurate risk probabilities.
ImproveState how you would compare predicted and observed risk across probability bands.
Checks the outcome horizon and whether outcomes have matured.
ImproveAlso verify that the population and outcome definition have not changed.
Suggests investigating drift and validating recalibration before deployment.
ImproveKeep the current model as a comparator and test the proposed change on later data.
Notes that users may act on risk scores, but does not specify a safeguard.
ImproveDescribe how decision-makers would be told about the calibration issue while it is investigated.
A strong answerI would separate discrimination from calibration: similar ROC AUC suggests the ranking may be similar, but it does not show that the probabilities are accurate. I would first confirm the prediction horizon, outcome definition, population and outcome maturity, then compare predicted with observed default rates across probability bands and relevant groups. I would investigate changes in the input distribution, data pipeline and underlying population before selecting a remedy. If recalibration is supported, I would compare it with the existing model using suitable later data and assess its effect on decisions. Until the issue is understood, I would communicate that probability estimates may be understated and agree appropriate safeguards with the people using them.
This answer earns credit by separating diagnosis from remedy. Avoid saying “retrain” as an automatic response: a pipeline error, changed population, immature labels or a genuine change in risk may need different action. State what evidence would distinguish those explanations.
Review the words that lost marks
After a practice answer, review one point at a time. Did you define the prediction target? Did you name an evaluation method and explain why it suits the decision? Did you state what information you would check before acting? If an answer says only “monitor for drift”, add the signal you would monitor and what response would follow from a concerning result.
A transcript can make one incomplete phrase easier to repair:
I would check whether the labels are mature and compare predicted with observed risk across probability bands. If it has drifted, I would retrain it. Then I would deploy the new model. The reason it drifted is that the customers changed.
If it has drifted, I would retrain it.
This jumps from a monitoring signal to a remedy without identifying whether the cause is a pipeline issue, population change or a genuine change in outcomes.
Say: I would check the input pipeline, population and mature outcomes first; then compare a proposed recalibration or retraining approach against the current model on later data before deployment.A good correction adds reasoning, not just length. Replace a vague action with a conditional plan: what evidence you need, what options it might support, and how you would test the chosen response. In your next attempt, aim to say the improved version naturally rather than memorising a paragraph word for word.
The examiner’s feedback can also be turned into a short spoken recap:
You separated ranking from calibration, then named the checks needed before changing the model.
A repeatable practice routine
Use your own lecture notes, assignment methods and assessment brief to build the next set of stations. For each method, prepare one scenario that asks you to choose or defend it. Then practise the answer aloud in roughly two or three minutes, adjusting that time to your actual assessment instructions.
After each attempt, record three things: the decision you defended, the evidence you used, and the most important limitation you did not mention. Re-answer only the weak part, then try the complete station again later with different numbers or context. This checks whether you understand the reasoning rather than remembering a script.
Before your viva, verify the assessment format and criteria with your course’s official materials. Practise the topics your course actually covers, and be ready to explain the assumptions and trade-offs behind its methods.
How MySummaries helps
MySummaries turns your PDFs, slides and photographed notes into revision boards. From a board, you can build viva stations around your own course topics, record spoken answers, review examiner-style feedback and revisit points that need more detail.