IFoA CS2 common mistakes
IFoA CS2 · Understand the traps and how to avoid them.
Writing R code that runs correctly in the console but fails in the exam's R Markdown script because the candidate hardcodes a file path or object that only exists in their local session.
Candidates practise interactively and forget that the exam deliverable is a single self-contained script that must read provided data files by the exact filenames given and run top-to-bottom without manual intervention.
What to do instead
Practise under exam conditions: always execute the whole script from a clean R session before submitting, load data only from the specified filenames, and avoid relying on objects created interactively. Keep all library() calls at the top of the script.
Producing plots or summary output that answer a different question from the one asked, e.g. plotting the survival function when the question asks for the hazard or cumulative hazard, or reporting a mean when a median was requested.
Under time pressure candidates reach for the code they know best rather than re-reading the precise quantity demanded, and survival quantities (S, f, h, H) are easily confused when derived from the same fitted object.
What to do instead
Before coding, underline the exact quantity and time point requested. Explicitly derive the requested function from the fitted model (e.g. h(t) = f(t)/S(t)) and add a one-line comment stating what each output represents.
Failing to set a seed before any simulation, or setting it in the wrong place so results are not reproducible, and then reporting numbers that cannot be regenerated.
Candidates test simulation code repeatedly without seeds and only add set.seed() inconsistently, or place it after random draws have already occurred, so the submitted output differs from a fresh run.
What to do instead
Place set.seed() once at the very start of any simulation block, before the first random number is drawn, and never change it between the development and final run. Verify reproducibility by restarting R and rerunning the script.
Using an inappropriate number of simulations or a poor variance-reduction choice, then quoting Monte Carlo estimates with no measure of their accuracy.
Candidates treat simulation output as exact and do not appreciate that standard error scales with 1/sqrt(n); they also overlook antithetic or control variates that the question may expect.
What to do instead
Always report the Monte Carlo standard error alongside estimates, justify the number of simulations in terms of desired precision, and where the question hints at variance reduction, implement antithetic variates and show the variance reduction achieved.
Mis-specifying the state space or transition structure in a Markov chain or Markov jump process model, e.g. omitting an absorbing state, mislabelling transient states, or getting the generator matrix rows wrong.
Candidates jump to matrix algebra before drawing the state diagram, and generator matrices (off-diagonal rates positive, row sums zero) are easy to sign-flip under pressure.
What to do instead
Draw the state transition diagram first, label every state and rate, then write the generator or transition matrix directly from the diagram. Check that rows sum to zero (generator) or one (transition matrix) before proceeding.
Computing ruin probabilities or survival quantities numerically but failing to interpret or sanity-check the result against obvious bounds.
Candidates focus on getting code to run and do not check whether the output is plausible, so sign errors, wrong time units, or a mis-specified initial surplus pass unnoticed.
What to do instead
After every numerical answer, check it against known bounds (probabilities in [0,1], survival decreasing in time, ruin probability increasing as initial surplus falls) and state the interpretation in a sentence.
Confusing the roles of the force of interest, the discount function, and the accumulation factor when converting between continuous and discrete time in a life-contingency or cashflow calculation.
The relationship between delta, v, and (1+i) is mechanical but easily inverted, especially when the question mixes payment timings (in advance vs in arrears).
What to do instead
Write down the conversion identities (v = e^{-delta} = 1/(1+i)) at the start of the question, state whether payments are in advance or arrears, and check that discounting reduces the value of later cashflows.
Submitting an answer with no accompanying explanation, commentary, or justification, relying purely on code and numeric output.
Candidates treat the exam as a programming test rather than an actuarial communication exercise, and run out of time to write the interpretation the markers award marks for.
What to do instead
Budget time to write concise prose around each result: what the model assumes, what the number means, and any limitations. Structure the script with headings and comments so the narrative is visible.
Ignoring model diagnostics and goodness-of-fit checks, presenting a fitted model as final without testing residuals, comparing candidate models, or commenting on assumptions.
Candidates prioritise getting a fit to converge and move on, forgetting that marks are awarded for validating assumptions such as proportional hazards, exponentiality, or independence.
What to do instead
For every fitted model, run and report at least one diagnostic (residual plots, AIC/BIC comparison, formal test of the key assumption) and state whether the assumption appears reasonable and what the consequence is if not.
Poor time and script management: spending too long on one part, leaving later parts unattempted, or producing an unreadable script with no structure.
The exam is long and open-ended; candidates over-invest in early modelling and debugging rather than securing marks across all parts, and neglect formatting.
What to do instead
Practise full past-style papers under timed conditions, allocate time proportional to marks, and move on when stuck. Structure the script into clearly labelled sections matching the question parts so partial work is easy to credit.