Many programmers today either work in, or want to work in, the financial arena.
Based primarily in capital cities like London, New York or Paris, the financial industry offers great rates of pay and scope for career progression rarely seen in other sectors.
This article aims to give you an overall knowledge of what it takes to work in the financial arena, what you need to know, and how best to prepare yourself for any opportunities.
Working in finance. The good and the bad.
First let's take a look at some of the reasons why so many technically minded people want to work in finance.
It pays more than other jobs that require similar skills. Make no mistake - negotiate your salary/rate badly, and
you'll quite happily be paid a fraction of your equal. Yet if you can find out the essentials of getting paid what you're worth
you can add tens of thousands in a very short time.
Check out our (soon to be published) article on how to avoid being underpaid.
- Size and scope.
This varies from company to company, but there is something I have always noticed:
If you want to work in some area, if you want to learn something, it can be done.
It may take some time and you might have to work at it, but the size of the industry and its scope allows you
to shift focus and try different things, making progress all the time.
- Large projects with adequate funding
Not always the case, but something lots of people that work in finance really enjoy is the scale of the projects they work on.
Applications can be highly distributed (running on multiple servers, sometimes numbering in the thousands), presenting an enjoyable challenge for Developers.
The same goes for global applications. It's not unusual for an application to run in multiple countries (eg: London, New York, Singapore, Tokyo).
Projects tend to be well funded, running on up-to-date hardware.
Application teams can consist of hundreds of staff. This allows for knowledge transfer, and you can learn fast from highly skilled people.
If you find yourself working on a good project, with a good team, the days can roll by very quickly with you learning huge amounts
of valuable information.
Now let's take a look at some of the things people don't like about working in finance.
Generally speaking, you can expect to work more hours in this sector. Reasons for this
being the case can vary from the silly to the practical.
When the time comes to make a major release of a product, don't be surprised to still be in the
office at 10PM. Around releases, everyone puts in the extra effort. It's not a daily thing,
and its not normally the result of bad planning.
Something I personally disagree with are working environments where 10 hour days are simply
expected of you. No real reason. No looming deadline. Just a culture that in my opinion
should be avoided.
There are so many reasons, so many different situations, it's difficult to summarise them.
On average, the hours are far longer. My advice is to be flexible, set your limits, and take
a lunch break somewhere away from your desk.
It all depends on the role, the personalities involved, the project management, and many other
things. The same can be said of any sector you might work in.
Finance as a technical working sector is well above average in terms of the pressure you might
find yourself under. It's just a part of working in this sector.
The best advice I could give is to focus on the problem at hand, and always remember that your life
is yours and yours alone.
Another topic common to almost all technical working environments. In finance, it can sometimes
be geared up a level. Personally I have never found this anything more than an occasional minor
irritation. Having said that, it's something that many people don't like about the sector.
What do I need to know to break into finance ?
As always, it depends on your specific scenario. However, one thing the vast majority of financial
companies have in common is the use of screening interviews/tests. The best thing to do here is to
revise. Cover all areas of your target role (eg: C++, Java, Agile/Scrum) and commit to memory.
It really is that simple. You will be asked obscure questions that do not seem practical, and you
need to have the answers to hand. Classically, "what is polymorphism?". I have personally heard lots
of candidates struggle to put this into words, though they clearly understand what it is.
So you have covered the basic syntax. Next up is getting to grips with data structures - maps, lists,
vectors etc... Most if not all roles in finance will need a good knowledge of data structures.
Typically this means STL, sometimes it means knowledge of boost.
Next up, if you don't already work in finance, and you want to move into that sector, there is some
terminology you can learn that will give you a huge advantage. Simple things like NPV (net present value),
the very basics of instrument types (bonds, equities, options, warrants, interest rate swaps, credit default swaps,
forex), sell-side vs buy-side, front office, back office, trades, long and short positions, MIFID,
ISIN's and sedol's, risk, the greeks and lots more. You do not need to be an expert, but having a basic
understanding and knowing these terms and their meanings will make a big difference.
Next up comes some research into the most common logic questions. These questions typically appear in
stage 2 of the interview process, during a face to face meeting. Look up common logic problems and
work through them. Very common examples are "balls on weighing scales - find the heaviest ball",
or "Something a little trickier
General types of technical roles within finance.
If you really enjoy programming, this is likely the role for you (at least initially).
There are many different types of programmers - web programmers, server side programmers, GUI programmers.
A lot of programming positions in finance will begin with bux fixing activities, this being a good way to become familiar with the code base you will be working on.
A lot of time will be spent bug fixing or upgrading legacy code. Opportunities for genuine greenfield development are actually in the minority, and are highly
When a program (or rather, an application or system) has been created and deployed, someone needs to look after it !. This is where the support role comes in.
Support basically involves dealing with queries from application users, investigating problem complaints from users, and proactively monitoring an entire system
to try to make sure everything works as it is supposed to.
This can often involve programming activities (usually involving scripting type languages like Python or Perl).
First line support means you are the first line of support from an actual query (eg: an application user will report any problem to first line support). These will
typically be common or repeated problems/questions.
Second line support handle the more non-standard issues, problems that require more investigation. The idea here is to allow second line support to investigate problems
without being distracted by continuous phone calls or other issues.
Sometimes there will be a third line of support, dealing with even more complex issues. Sometimes this is simply called "dev support",
In the most general sense, you will be testing an application. Problems found or just requested reports
you will write up a good and detailed enough description of the problem containing a suitable amount of
supporting reference data (which account you used ?, screenshots, a sequence of steps to reproduce etc...).
Testing roles can be highly technical, and have the benefit of immediate exposure to finance domain knowledgeability
by virtue of using the application as would a normal user.
- Business Analyst
A business analyst operates as a kind of interface between the technical folks and the business
behind the application concerned. More business focused than technically, but with plenty of exposure
to the technicalities of the application.
- Technical Analyst/Architect
A technical analyst or systems architect position is usually a role held by an experienced
technician. Responsible for such activities as overall system design. Which technologies will be used ?
Will it be Windows or UNIX ? How will data be stored ? In part it is a design role.
This article is in iteration and is currently incomplete.