Joel started coding games when he was 15, then created web applications a few years later during his PhD in Mathematics. It is only in his mid-twenties that he started considering himself as a real developer, when he started working in banks, developing risk management systems. Recently, 10 years and several banks later, Joel founded Quantelligence, which provides freelance consultant services in risk systems implementation to the financial services industry.


What is your job title? 

Quantitative analyst / developer, also known as Quant

What is your role about?

As a quantitative developer, I work in a bank and help the business by providing tools they need to generate trades and risk manage them. This can mean a range of things, but most of the time it revolves around adding features to the infrastructure to give people better access to data / computation tools / reports.

One example of projects I worked on was to create a DSL (domain specific language) so that non-programmers could represent complex deals and understand what the risks of these deals are. To give an analogy, imagine you are at the racetrack and you want to bet if a horse A finishes second in a race, and if, on top of that, horse B finishes maximum 10% after the time it took to C, irrespective of whether they are in the top 3. Well, some of the financial contracts traded by banks are as complicated as that, and some even way beyond that. Now, programming the algorithm is not very complicated, but that is not scalable. It is the sales person who is on the phone with the client, and having to ask a programmer for every single trade is just too cumbersome.

Another kind of projects consisted in improving the performance of some of the calculation routines in order to get end-of-day profit/loss reports on time so people can leave at a decent time. The improvement can be as simple as analysing the bottlenecks / profiling the calculation times, or can involve a reconfiguration of the distribution of tasks on the compute farm. Sometimes it can be a blanket improvement by pre-computing some data, and sometimes it requires fine-tuning a quantitative model (e.g. a MonteCarlo simulation, a root-solving algorithm) so it gets to the result quicker.

All the work is by essence team-based, and a large share is very short-term. People tend to be on medium-term projects (i.e. few weeks), but the bulk of their time is devoted to day-to-day support of stuff breaking, or new requirements due to client requests. The quant needs to be responsive to traders / sales people, as there are often large and urgent trades or risk management issues to deal with.

What are the best/most positive parts of the job/industry?

A rewarding side of working in a bank is that, even nowadays, with all the pain the industry is going through, banks are still printing a lot of money. This means that for junior developers pay can be substantially higher than in other industries. Even if banks are not software-producing companies, and therefore programmers are a cost centre rather than profit centre, there is still enough money around.

In one of the places I worked, the programming environment was very interactive, which meant that you could experiment with changes to a model / calculation method, and very quickly see the impact and even push to production. This is much more stimulating than working on a feature for a long time, that will only make it to production weeks or months down the line.

In first tier banks, most quants tend to be quite smart, so there is definitely a lot of intellectual stimulation. However, these places are not research centres, so once you get over the novelty of asking your colleagues brainteasers or discussing techno stuff, you will need to work on things which make sense for the business – in the short term – rather than what you find interesting. IMHO this is a good thing, but some may find it frustrating or even counterproductive.

What I find a plus, but it can be a double edge sword, is that programming in banks is often more in breadth than in depth. I learned stuff about functional programming / data-mining / numerical algorithms / SQL / scripting languages / GUI writing / parallel computation / web programming / Unix and am probably forgetting few other stuff. This means I know lots of tools, but am unfortunately not an expert in any of these

What are the negative parts to the job/industry?

A large share of the work consists in very mundane tasks, such as troubleshooting existing systems when a break occurs, when risk numbers are late, or when a new feature needs to be added straightaway in order to accommodate some client request. In these circumstances, good programming practices (code reusability, structured data formats, code documentation) fly out of the window, and it is easy to get into permanent fire-fighting mode. This can be an opportunity though, because as soon as problems are recurring often enough so that it’s worth automating a fix, then a smart quant can stand out by coming up with a real fix, and make his own life easier. In other words, the developer really is the one who is paying the price of bad programming practices, or reaping the rewards of good ones.

Even though your colleagues will be people with interesting backgrounds and ideas, banks are not always the best place to let your creativity blossom. You will often face very short deadlines, where deep thinking and pondering are just not affordable. Some people just bear with it, some other get fed up, and then a third group – yours truly included – try to force some tiny bits of creativity here and there, just enough to get job satisfaction, whilst respecting the demands from the business. This may sometimes mean late nights to do things right rather than just get them to work.

Besides the technical challenges, it goes without saying that the pressure of the environment can be tiring. So being able to gain respect and trust from people, and manage expectation so you can solve the issues in a responsible way is a vital skill that some people learn better than others.

Career Path

What is the standard career path/qualifications?

Most quants have a background in Science (Math / Physics / Computer Science). Even though there are different levels (Analyst / Associate / Execute Director / Managing Director), in terms of role, the 3 first ones are quite similar. At ED/MD level people are more into team management and tend to code way less, but that depends on the particular role.

What are the prospects?

As it stands, the industry is clearly in decline, so it is not clear what the future holds. But given the remark above, the skills package is quite broad and the problem-solving and solution-oriented mind-set are pretty powerful if you can find an employer who can see beyond the pure technical skills.

The kinds of possibilities are:

–        relocate to another geography where banking is doing better (e.g. Asia)

–        working in any industry where numerical computations / algorithms are key

–        working as a chief technologist for a small company (e.g. start up or hedge fund) – or start your own start up!

–        working as contractor on bespoke projects (some companies crave for talent from good banks)

In your experience are you aware of any differences your role has between industries/sectors?

As mentioned above, a programmer in a bank is not revenue-generating but overhead. This goes together with the fact that you do not invoice internally for your services. Therefore it is very difficult for you, or your boss to figure out the monetary value of your contribution. This implies it is difficult to claim a higher pay just because the business is doing a lot of money.

Programming is often prone to over/underinvestment issues, and the fact that your product is diluted into the organisation rather than sold to customers makes it even more difficult to appreciate whether the amount of investment is right.

Reflection and The Future

What was it like coming into the industry?            

As I came from a rather academic background, I was concerned about whether I would like it to be under constant short-term pressure. Turns out I liked it very quickly. The good thing about short-term deadlines, is that… they are short-term. This means that once things are behind your back, you can breathe, feel you’ve achieved something, and move on to something else. In academia, the long-term aspect of research was quite tough to deal with, because it seemed like the issues were never going away.

One unexpected and yet fundamental things I discovered is how strongly the whole ‘teamwork’ is about. I don’t mean just meetings, because you would have these in universities as well. I am thinking about collaborative tools, such as videoconf / screen sharing / calendar sharing / project/issue tracking, and the most important one being version control systems (subversion & co). Once you get into it, it’s quite exciting to be able to make surgical changes to a massive codebase rather than building your stuff from scratch as you sometimes do in academia. Be aware that reading code is way more difficult than writing. And that the challenge is not so much to implement stuff, but to do so whilst respecting the existing codebase.

These are very important things you only learn with time, but getting involved in collaborative projects (e.g. open source) can be a good way to get exposure to that before your first (paying) job.

Do you have any thoughts on the future of your role/industry?

I still think the industry has a strong potential. Banking is a massive industry and yet, the proportion of people on the planet who have a bank account is probably below 20%. The growth in how much people are going to use banking in the future is unavoidable, as well as how much technology is going to be the key differentiating factor. Even if at the moment it all looks quite gloomy…

What advice would you give someone entering your industry?

If you are keen to rise to the top in this industry, make sure you look at the big picture. This means that you may want to prefer a role which is not as sexy / technologically demanding, but rather that puts you in a strong position. E.g. I would avoid being part of a large team where everyone’s specialized and I’m just going to be a cog in the machine. In good times, that was good enough to prosper, because everything was growing larger / richer. Instead, I would look for more entrepreneurial places where you are bound to do a bit of everything. This may mean you have a stronger bargaining power because it would be harder to replace you.

Remember that technical prowess, especially in this industry, will often mostly serve one purpose: to draw attention. This may be great if you manage to use attention to get political power. Otherwise you may do great stuff, come up with life-saving solutions, save your bosses’ ass over and over, but never become the one who gives the orders and collects the credits. It could be that in other industries, the smartest people get the recognition they deserve, but in banking I would say there’s only 30% correlation…

Some general advice: my personal philosophy is that it is much more important to learn as many paradigms / technologies as possible rather than as many languages. Becoming fluent in yet another language isn’t a particularly enriching experience, so do not do it just for the sake of it. Besides, languages keep changing and going out of fashion… On the other hand, discovering new paradigms (procedure programming vs. functional / programming of back-ends vs. front-ends / database programming / MVC and other design patterns) is something that is not just intellectually challenging, but also very enlightening. It gives you frameworks (that people have taken decades to develop) to solve complex problems efficiently rather than by reinventing the wheel.

Code quality and code reuse can make a tremendous difference between an average programmer and a good one, and as the saying goes: ‘The best line of code is the one that someone else wrote for you’.

Have you come across anything or anyone that has helped you move forward in the industry?

All along my career, I have had friends / colleagues who I identified as being way more knowledgeable about some fields than I am. I picked their brain until I could get as much out of them as possible, and that helped a lot.

Often, mentoring more junior people was a great source of inspiration. The reason is that junior people tend to notice things that you as a veteran would not pay attention to.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s