Actuarial work increasingly involves data, modelling and automation, so technical skills are useful before you start. The challenge is knowing which ones are worth learning.
You do not need to arrive at a graduate job as an expert programmer, and different employers use different tools. But a small number appear repeatedly across actuarial work: Excel, R, Python and SQL.
This course teaches the practical foundations of those four. The aim is not to turn you into a software developer. It is to make sure you can work with data, automate simple tasks, understand code written by others and talk confidently about the technical skills on your CV.
We will also look at how these skills appear in real actuarial graduate job adverts, so you can see what employers actually expect at entry level.
What the adverts actually say
| Advert (read 30 July 2026) | The wording | What this means for an applicant |
|---|---|---|
| Bolton Associates, graduate actuarial analyst, London (closing 13 Aug 2026) | "You should be familiar with using Excel"; "additional coding languages such as R, Python and SQL advantageous" | Excel expected; Python, R or SQL would strengthen an application |
| Bolton Associates, capital and reserving rotation, specialty insurer (closed 2 Mar 2026) | "Good Excel skills" required; "Experience of SQL, Python/R and data visualisation tools, e.g. Tableau/Power BI, is desirable but not a requirement" | Excel required; coding is not a gate, but prior experience is useful |
| Brit Insurance, Graduate Actuarial Analyst Programme (applications closed 1 Dec 2025) | "Coding experience (VBA, SQL, R, Python) is a plus" | Coding is not required, but clearly valued |
| Allianz UK, Pricing graduate scheme | "We use several software (Emblem, Radar, SAS, Excel) and coding languages (Python, SQL, R)", taught through a "Bronze Accreditation programme" | You will use these tools and receive training on the job, however, prior familiarity would still give you an advantage over other applicants |
| Lloyds Banking Group, actuarial graduate scheme | Graduates get hands-on with "Excel / VBA, Python, R, Prophet (actuarial-specific modelling software), Power BI and other powerful data-driven tools" | These are tools used on the job. You are not expected to know all of them beforehand, but experience with some will still give you an advantage |
| APR, graduate associate scheme | Project work is "model development and coding in various languages such as Excel, VBA, R and SQL" | Coding is part of the work, so prior experience can help even if the advert does not make it an entry requirement |
| Zurich UK, life actuarial graduate scheme | "analysing data using actuarial software and programming languages"; nothing named | Specific tools are not required, but working with code and data is clearly part of the role |
Four things fall out of that table.
Excel has the clearest pre-entry expectation. It is the only tool in this sample that employers explicitly describe as required or something applicants should already be familiar with. It is also widely used once you start actuarial work, so being comfortable with formulas, tables, checks and basic modelling is useful before your first day.
Python, R and SQL are often advantages rather than entry requirements. Words such as "advantageous", "desirable" and "a plus" do not mean the skills are unimportant. They mean an employer may still hire and train someone without them. However, displaying some experience gives you an advantage over other applicants and lets you show that you can already work with data and code.
"Taught on the scheme" does not mean "not worth learning". Employers expect graduates to learn their particular systems and ways of working, and almost nobody will arrive knowing every tool on the list. But if a role says you will use Python, R or SQL, knowing the basics beforehand makes it easier to contribute and gives you stronger examples to discuss at interview.
The team matters more than the company name. A pricing team may use large amounts of code and data, while another actuarial team at the same insurer may rely more heavily on Excel or specialist actuarial software. The aim is therefore not to master every possible tool, but to build a useful technical foundation that transfers between teams.
That is why the rest of this course teaches Excel, R, Python and SQL. You do not need all four to get an actuarial graduate job, but each is useful in actuarial work, and being able to use them gives you more options once you start.
What actually gets tested
What an advert asks for and what the recruitment process assesses are not always the same thing.
APR publishes its graduate process, which gives a useful example. After online numerical and verbal reasoning tests and a telephone interview, candidates attend an containing a presentation, written test and interview. The written test includes mathematical reasoning, probability and statistics, programming, insurance knowledge and written communication. Importantly, no particular programming language is required.
Other actuarial graduate processes also commonly include numerical tests, case studies, analysis exercises, presentations and interviews.
There is also some variation that does not always appear on public careers pages. In our own experience of actuarial recruitment, we have seen candidates given practical Excel tests, particularly where the role involves a lot of modelling or data work. For more technical actuarial roles, we have also seen assessments involving Python or R.
That does not mean every actuarial graduate interview will contain a coding or Excel test. But it is another reason to be comfortable actually using the tools on your CV rather than simply recognising their names. Additionally, it means if any of these tests do show up, you will be well prepared.
The safest preparation is therefore broader than learning one interview format: be able to work through data, explain your reasoning, build and check a simple calculation, and discuss any Excel, R, Python or SQL experience you claim.
Calibrating what you claim
Every skill on your CV is an invitation. Interviewers probe the thing you wrote down, because that is the cheapest way to find out whether you wrote it down honestly.
The CV lesson in Become an Actuary tells you to show evidence rather than adjectives. Here is the tool-specific version of that rule. For every technical line, be able to say three things without preparation: what you built, one number from it, and the part that took longest to get right.
The rest of this course builds that evidence: an Excel model you built and checked, code you fixed rather than copied, and enough of the software map to talk about tools you have never been licensed to open.
Check your understanding
An advert for a graduate actuarial role makes a numerate degree its stated requirement, then adds that coding experience in R, Python or SQL is 'desirable'. You have never written a line of code. What does the 'desirable' wording actually tell you?
A friend tells you not to bother learning Python basics before applying, because the scheme they are targeting says it will be taught on the job. What is the right call?
A pricing team and another actuarial team at the same insurer turn out to use very different amounts of code. When you are deciding what to learn before you apply, what does that variation mean?