FAQ
Below is a list of questions I get asked at interviews, is discussed amongst my colleagues etc. It contains my opinions, which are clearly neither right nor wrong. Any of the below should not be construed as professional advice or used as inputs in making decisions. I refer to "model" and "systems" below. By a model, I mean the application (usually written on Prophet or MoSes) that is designed to deliver a calculation or series of calculations (e.g. a reserve, an embedded value). A "system" is the model with other applications that either feed into the model (e.g. a parameter spreadsheet, a SQL query that extracts data from a mainframe) and/or an applications that take output from the model (e.g. a spreadsheet or webpage that displays results from a model run).Where are you based? Where are you prepared to work?
While I am based in London and prefer to work there, I have worked from Guernsey to Glasgow and quite a few places in between. I am happy to work pretty much anywhere, including other parts of the world. Please keep in mind that I will need a work permit outside Australia, New Zealand and Europe.
What are your future plans? How long do you intend to stay in the UK?
I am reasonably certain I will be staying for a few more years in the UK as I own my own house in London.
What do you think is a better modelling platform, MoSes or Prophet?
I think it is unfair to say that one platform is better than the other. I think they are built with different philosophies. For example, MoSes is built with the "high end" programmer in mind. It is very easy to create custom, bespoke applications. However, the developer needs to be a very skilled programmer to be able to achieve this. Prophet is very easy to use (by far its greatest strength). However, it can be very difficult to create to custom, bespoke applications. Having used both applications to an advanced level, I am neutral between them. I can use both very well and enjoy both of them equally.
What is your favourite contract?
Of all the contracts I have completed, my favourite would have to be Surrenda Link in Chester, June 2007 to February 2008. Surrenda link asked me to build a Traded Life Interest model. This model needed to have the ability to have a data set that varied in size as the model ran because the model was going to buy and sell policies. This is something that I had never seen before and a number of my MoSes friends said it could not be done because MoSes is not designed to do this. Ah!! A challenge!! And I LOVE a challenge!! So I sat down a figured out how to do this and, suffice to say, I got this to work. After two weeks of writing specifications, I started the model build. I had a working model within another two weeks and just kept adding more functionality from there. Overall, what I delivered was far greater than the original specification. After training, documentation and handover, the work was finished. I think the one thing I really loved about this contract is that it bought out my full potential. I had to solve some very difficult problems, build a model from scratch (first time I had achieved this) and the contract vastly increased my MoSes skills. I would love to find the same again.
You have trained a number of staff in MoSes and other applications. How do you go about this?
I do not teach people specific skills. I teach people to teach themselves. That is to use the resources around them (the online help, the internet etc) to gain skills and knowledge. It is very cliché but the old adage about "give a man a fish" is very true.
Do you do "mainstream" actuarial work that is not systems/modelling/programming orientated?
No, I do not. I spent my early actuarial career doing this and it is not really what I am suited for. I am a strong, natural programmer and I really enjoy the challenge the actuarial work provides. A career that combines both of these is perfect for me.
Are you more an actuary or a general programmer?
I am much more an actuary than a general programmer. For example, I was approached about a MIS contract in a brewery a number of years ago. As much as I enjoy a beer, I doubt this would have provided enough challenge for me. I am great believer that actuaries are born, not made. And I was born to be an actuary!
Are you interested in other fields of actuarial practice such as General Insurance and hence keen to learn new software packages such as Igloo?
I am always very keen to gain experience in a different area of actuarial practice, learn new software etc. One of my greatest strengths is that I learn new material very fast. I knew NOTHING about Operational Risk before I started at the Co-operative Financial Services but I picked it up in a few weeks. I taught myself Prophet to a functional level in one day.
Would you consider a permanent role? If so, what would be an indicative salary?
I would be very happy to be employed on a permanent basis, particularly in a "high end" MoSes/Prophet role. I am not a contractor entirely by choice. Being so specialised, companies have not generally been able to offer me work for more than a few months at a time. However, due the effects of the credit crunch, the looming recession, and increasing regulation, I am starting to find that this changing. A number of companies are looking for senior MoSes/Prophet people on a permanent basis. It is also worth mentioning that some of the reason that I have been a contractor is that the contract market moves so much faster than the permanent market. Most companies take a month or two to recruit for a permanent role. Contracts can be interview today and offer tomorrow. I have often been for an interview for a permanent role and a contract role within a day or two of each other. The contract was offered to me long before I even got feedback from the permanent interview and I simply was not in a position to decline the offer.
What is your daily rate?
I do not make my daily rate public but I am always happy to disclose this if you contact me.
What approach and processes do you follow in designing and developing a model/system?
Firstly, I am great believer in formal software development methodologies. Actuarial systems development is a very long and complex process. The models themselves are complex. The technologies that are used are often even more complex. To ensure that work is properly and thoroughly completed, a formal and rigorous process need to be put in place with proper controls implemented. A good formal software development methodology facilitates this. Personally, I prefer the Software Development Life Cycle. While it one of the longer methodologies, I have found it the one that most suits actuarial systems development. Also, it is some what analogous to the Actuarial Control Cycle so I think mainstream actuaries tend to understand it better than other methodologies.
Secondly, I have three rules of actuarial systems/model development.
1. Get it right the first time. Whether it is just writing a few lines of code or building an entire end-to-end valuation system, It is far easier to take the extra time and effort to complete the task properly now rather than do a "half hearted" job now and complete or fix it up later. Two reasons - it is often very difficult to remember exactly what thought processes you were following at the time and try to replicate them later, and with time constraints, workloads etc, people often just don't get back to completing the task.
2. Don't build something to do something once or to do one thing. Code should be modularised and hence easily adaptable to other applications. Furthermore, code should be able to repeat a process many times. Systems should be designed with a longer term view in mind. When a client asks me to design and a build a system, I ask what are they looking for longer term, their "wishlist" if you like. Quite often, what the client wants in the future can have a significant impact on the initial design and build. It is far smarter to find this out now rather than having to re-engineer/reprogram an entire system/model a year or two later.
3. Document! Document!! Document!!! It is nearly impossible to put sufficient emphasis on this point. Large amounts of time get wasted because models and systems are not properly documented and knowledge is not recorded. From my experience, every hour spent documenting saves about half a day in the future. I make a point of documenting two aspects of my work - the work itself (what I have done) and the thinking/philosophies behind the work (why I have done what I have done and taken the approach I have).
My approach to actuarial systems/model development is mostly a combination of these two.
1. Understand the client's needs, both immediate and long term.
2. Write a set of business requirements ("what we want to do"). Review this as many times as is necessary to get agreement from all stakeholders.
3. Write a set of functional specifications ("how we are going do what we want to do"). This includes the test plans. Again, review as many times as is necessary to get agreement from all stakeholders.
4. Write a module of code.
5. Test this model in isolation.
6. Integrate this module into the entire model/system and test both the module itself and regression test the entire model/system.
Repeat 4-6 until model/systems is finished.
7. Implement and maintain.
By far the most important stages of this process is stages 2 and 3. So many model/system builds don't succeed because 2 and 3 were not properly completed.
What "gets your goat" about Actuarial Systems and Model Development?
Two things;
1. Apathy and slackness - One of the most common development "methodologies" I have seen over my years in this field is the SBR methodology. SBR?? "She'll Be Right". Examples - I have seen people build approximate solutions without knowing or caring how close they were to the actual result, "quick fix" solutions that prove to be a waste of time over the longer term and hence discarded, no documentation and no-one seemed to care, and so on.
2. Inefficiency - So models/systems I have seen could produce the same results a lot quicker and with a lot less work. Examples - manipulation of MoSes results that is done in an Excel spreadsheet that could have been automatically done in the MoSes model itself, a data set produced from a SQL query that still needs further work before it can be fed into a model run. Furthermore, the more manual work that is done, the more chance there is for error. Having done a great deal of systems development and Business Process Re-engineering, I know how easy it is to save so much time and effort and reduce errors to practically nil by efficient and intelligent systems' design.
What do you do outside of work?
I have a great many interests outside of work. I love to cook and match food with wine. My "signature" dishes are Smoked Salmon Fettuccine (which goes great with a fruity Riesling) and a chocolate biscuit that does NOT come with the National Heart Foundation's "tick of approval". I run and cycle a lot (good for fitness and health and is excellent stress management). I compete in various races throughout the year to raise money for Cancer Research UK in memory of my father. I play chess regularly (I was school chess champion but I don't play competitively any more). I love art, particularly the first half of the 20th Century. However, my greatest love in life is music. I used to work as a DJ back in my student days. I play bass guitar (just for fun - I don't have the time to take it seriously). I go to a lot of concerts throughout the year, especially the festivals in Hyde Park. The live music scene is the one thing I will miss about London when I eventually leave.