Daria Deluermoz, one of our first graduate hires – talks through her route to FINBOURNE, her first few months in the job and what a typical day looks like.
From Biomedical Engineering to Fintech
I studied an Meng in Biomedical Engineering. When it came to looking for jobs, I originally looked at Big Data/Analytics/Machine Learning type positions in startup/SME companies and I’ll be honest, I had no initial interest in FinTech.
When I started to apply for jobs, I had 3-5 years’ experience with programming. This was mostly Matlab (engineering applications such as finite element modelling, fluid dynamics, image processing), with some C++ (introductory level course to OOP via Image processing and mathematical applications) and a little bit of python (AI and Machine Learning). All of this was mostly self-taught out of necessity for my research projects.
The job spec at FINBOURNE included python in the tech stack description – hence I assumed I would be working in python. However, in my second interview it became clear that I’d be working in C#. I had never used, or even seen, any C# code. At FINBOURNE, it’s not about what you know, it’s about how willing you are to learn and adapt. And so I began my first job out of university using a coding language I’d never used before, in an industry I was unfamiliar with!
The first few weeks
My first month was quite overwhelming – there was a lot of information to digest but I felt well supported by everyone in the team. In addition to experience with C#, I also had no experience with pipeline integrations, a vague understanding of what Git was but not really how to use it correctly, no experience with software specific coding of any kind (such as the infrastructure, testing, all the supporting code required etc). I had spent the better part of 4 years writing complex mathematical scripts that at best would output some fancy 3D models of a human heart, or control a robotic arm. I knew a good amount of theory surrounding programming and software, but codecademy doesn’t really prepare you for the reality of working as a developer.
Day 1 went well, as I spent it building a computer (read: clicking some ram sticks into a box and plugging various cables in) and installing all the software I would need to work. The checklist had suggestions for helpful extra software that I might want to use, such as more powerful text editors, IDE extensions, a different terminal/command line tool etc. I installed the one thing I recognised on the list: Atom. I’ve since been called a ‘typical millennial’ for using my fancy text editor with integrated Git and GitHub tools, ide-like extensions, support for all sorts of languages and features, instead of sticking to the more traditional Vim, but you’ll have to pry Atom from my cold, dead, millennial hands.
Day 2, my first coding task. I was asked to make a simple improvement to an error message. No tweaking of methods or debugging required – just finding the method that returned this error and modifying the string from “NotFound” to a more appropriate message specifying that dates didn’t match. A couple of days later (this fix should have taken 15min tops), with hours of help from various colleagues around me, I had my first piece of work floating through a then-green pipeline. About six minutes later, a very angry looking automated notification pops up in Slack, accusing me of breaking the pipeline, thus blocking any more updates from going through. I’d forgotten (or rather didn’t know about) the tests, which were now failing as the assertion that the error returned “NotFound” was no longer valid. It didn’t last long as my supervisor spent the next few hours walking me through the tests, the types, how they worked, how to run them before checking work in to make sure the pipeline won’t break etc.
Week 3 – I was assigned a large piece of work. A basic csv parser that pulled data from an API and passed it into our product LUSID had already been written a few months prior, however it was now out of date following some updates and new requirements. For the next couple of months this was my focus – building out this parser, and eventually adding and modifying related methods within LUSID. Suddenly other people within the company started popping by my desk, asking for clarification on some of these features, how they worked under the hood, how they related to other bits and bobs.
Month 2 – Python tutorial modules. It’s interesting how quickly you can lose grasp of a language when you no longer use it on a daily basis. At this point, nearly 8 months have gone by since I last had to write more than a print statement in python, so I volunteered to write a couple of tutorial modules for the client engineering team, just to get to grips with how LUSID integration worked through the sdks, and keep up my python skills. Since these were more linear script style pieces of work, they were a welcome break from the much more complex problems I was working on in the main codebase.
Month 4 – excel. This was another project that needed fixing since major updates had been made to LUSID, and the task fell to me. This is one that was more tedious than anything, as it was a combination of the work I’d done on the data parser and the python tutorial modules, but in a new environment that came with its own set of challenges courtesy of Microsoft. This was the first time that I knew exactly what needed to be done ahead of time, and how to do it with regards to the LUSID implementation. Annoyingly, I was stopped mostly by the intricacies of writing an Excel Add-on and being constrained by things totally outside of my control. Despite the frustration, it was a great opportunity to work with some of the guys on the business side of the company, and see our work from a user’s perspective.
Month 6 – After 6 months I had a happy grasp of the overall work that we were doing, and even a good working knowledge of some internal parts of LUSID and some extensions and tools we were creating alongside it. I was offered the opportunity to work with another team for a time, perhaps focusing more on database work, security, or systems, but I felt that I still had more to learn from where I was already, so I continued on. The opportunity is always there – if a task comes along that sounds interesting to me, I would be able to work on it regardless of which team it would automatically fall into.
Learning as you go
The biggest challenge of working in a new industry is learning about it on the go. When I joined, some of the senior engineers ran ‘Introduction to Finance’ sessions for me and our other graduates. In fact, over the first couple of months at FINBOURNE, I got to sit through a whole bunch of intro sessions on various topics such as “What does the finance industry do” and “Introduction to investments and asset management”. As dry as these sound on paper, they were quite interesting and informative. Having no formal background in finance these were invaluable to learn more about the motivations of the company, and the purpose of our work.
In addition to these sessions for the grads (and other new joiners) there are weekly and bi-weekly teaching/learning sessions organised revolving around sharing our knowledge and discussing various topics that are relevant to our work. These include our Finance Q&A where every couple of weeks someone talks about a finance/business type topic, aimed at expanding everyone’s knowledge of the industry. Codecraft is planned on a weekly basis. It is similar in aim to the Finance Q&A, but revolves around coding practices, new developments, and sharing knowledge about different parts of the software and how they’re being built. More recently, a Machine Learning Discussion group was formed, where we’ve discussed all sorts of topics ranging from basic AI to quantum computing, with the underlying aim of applying some of these techniques in LUSID.
What I’ve learned so far
- I learned matlab and python mostly as procedural languages, while C++ was my first real introduction to Object Oriented Programming.
- FINBOURNE has a more Functional approach in C#, which meant on top of not knowing the language, I would simultaneously have to learn the theory of functional programming, although we don’t have the strictest use of FP either, it’s still an extra step and load of information to take onboard and adapt to.
- This required more reading, more self-teaching with books and the internet, and is a continuing process that after nearly a year I still struggle to grasp parts of.
- “Improvise. Adapt. Overcome” is incredibly relevant to the first few months.
Agile working
We’re either busy working on fixing problems within the platform or building out new features. In general, we follow an Agile work methodology. This is a method of planning work by splitting each small task into “Stories” which have a number of points associated to them based on complexity and an estimation of the time it will take to complete each one. The stories are then assigned to people on a bi-weekly period (called “Sprints”). Each sprint, you focus on those tasks assigned, and as new ideas, solutions, bugs and other tasks pop up, you create more stories that are assigned and worked on in subsequent sprints.
These two week sprint blocks suit most people pretty well, your goals for the period are clearly defined, each task is usually pretty small and manageable, and it’s an easy way to keep track of the work you’ve been assigned (or assigned to yourself). At the end of a sprint, if there are any open stories remaining, they usually get rolled over onto the next sprint, meaning unless there are urgent changes needed (e.g fixing a bug that’s blocking other people’s work), the sprints and story points are just loose guidelines and targets, used more for planning than as deadlines.
As a grad you’ll be painfully familiar with the ever looming deadlines that uni courses throw at you, and it’s a refreshing change to know that yes, you should probably write that new method and the tests that go with it in a day or two, but if it takes you three or four days (or three weeks as has happened to me once), it’s not the end of the world. Instead, your task remains open, and you should probably just assess the reasons why it’s taking longer than expected and concentrate on completing it in a reasonable time.
A year on (almost)
It’s hard to believe I’ve been at FINBOURNE for almost a year. Now, I’m taking more ownership of certain parts of the software and work much more independently. I still have to rely on others to guide me and clarify the work that I have to do, and not a single day goes by that I don’t have to ask someone a question. But I have a much better understanding of the system which means it’s easier and quicker to get help and solutions to problems. With new grads joining, I suddenly feel much more useful in being able to help others out, as I’ve been through the process already and can help guide them through it from my own perspective.
