I’m Sam and at Certua I’m a junior machine learning engineer and also develop a lot of the automated testing.
I was always interested in problem solving and loved taking things apart and putting them back together. I was also always interested in tech but more so the hardware side of things than software. I first started seeing how the software side of tech was related to problem solving during my final A level project. It involved doing a lot from scratch and having to learn a lot that we hadn’t been formally taught. That’s where my interest in computer science started to develop and it’s what I studied at university.
Outside of Certua I am a foodie and enjoy exercising.
I started at Certua as an intern while doing computer science at university. I actually never intended on getting into machine learning engineering but the ML team were the people in on the day I started who were able to give me work so that’s where I ended up. It was a very steep learning curve but I enjoy learning and a challenge, so with the help of other people in the team I was able to get up to speed. I was working part time while still at university which actually ended up being very helpful as the skills I learnt for work later came up in university modules.
At Certua I’ve worked on the machine learning models we use in our open banking propositions for merchant and purpose tagging; given some arbitrary bank transaction, what was the purpose of the transaction and who was it with?
It’s a problem that’s quite complex because a lot of the transaction descriptions aren’t written in plain English but rather use a lot of abbreviations and acronyms which limits the degree to which pre trained natural language/sentiment analysis models are effective to solve the problem. Furthermore, a lot of merchants are small, local institutions that don’t turn up frequently. Amazon shows up in a lot of people’s bank statements, whereas somebody’s local café doesn’t. Picking up that name as a merchant using context clues is a lot easier for a human than an AI.
I also developed our automated insurance journey testing tool which can automatically verify that thousands of possible insurance journeys are implemented correctly. It crawls through our insurance journeys answering questions either at random or with re determined answers, and has expectations of the next thing it should see based on the answer it has just given. If it sees something unexpected (CSS, question text, answer type, being referred for underwriting when it should be accepted, being quoted the wrong price, etc), it flags it as a bug.
I have a lot of freedom in my job to experiment and learn. I’m told what problems are and am given space to find the solution that best fits for the problem. This normally involves getting up to date with the latest research in the field which is great for improving as an engineer, and as somebody who naturally enjoys problem solving this process is much more engaging than simply being told to implement something. A lot of these are also from completely new problem classes that I have never worked with before, which keeps me on my toes and gives me opportunities to learn about a lot of new fields.
Working with life insurance products the models used for pricing rates seem very antiquated. Not every 43 year old non-smoker with no medical conditions has the same amount of risk but the models treat them as if they do. In future it would be interesting to try and improve these models to be more dynamic based on the individual.
Innovative, adaptable, nurturing