What is the difference between being an IT in investment bank and a professional IT company?

Question

Suppose there are two positions:

1. IT in investment bank: developer for the infrastructure or the platform
2. a famous IT company: embedded developer, linux

As far as I understand, since in the investment bank not everyone will have the chance to work for the core trading system, most people just do the same job as they do in a normal IT company. And some of the tasks can even be outsourced.

But in a professional IT company, you will have more chance to practice your coding skill and enhance your professional knowledge. So there are many choices when you want to change your job while the IT in invest bank not.

Is this correct?

Answer 1

In my opinion, the difference you list actually takes a back seat to the bigger difference. The biggest difference, by far, is that if you work for an investment bank, the bankers are the guys who make the money. You're basically a cost-centre: a necessary evil, and the software is merely a means to an end.

For a company that sells software, the developers are the guys who make money: software is the product.

So those two things make for very different priorities for management. For an investment bank, it's going to be about keeping costs down and getting things to the point where they work "well enough" for the real employees to get their job done, but there's no incentive to improve the product beyond that. For a software business, you're competing with all the other software companies, so you need to polish your product to the n'th degree. There's a lot more room and a lot more freedom to work improving the software and it's a great place to be if you're a real perfectionist.

The difference in priorities manifests in other ways, too. You're likely to get much better fringe benefits in a software company (things like free coffee/energy drinks, better hardware, etc). Probably others, too, but the above is the main reason I prefer to work for a company whose actual business is software, not one where software is secondary.

Answer 2

The work in investment banks varies widely. This can range from helping a banker debug his excel spreadsheet, coding wire protocols for a ancient stock exchange interface, statistical analysis on markets, coding the front end for trading systems, to, nursing an accounting package. (Note you may be surprised to learn that this list was ordered most to least interesting).

So you may get stuck with some incredibly boring out of date code, or, you may do the most interesting project of your life; its pretty random. One thing is for sure you will meet the most interesting and varied set of users, and, may end up understanding the details of the more exotic financial derivatives.

Life in a software house can vary greatly as well. A few good ones are striving to produce innovative products and prize code quality and innovative ideas. Most just want to squeeze more revenue out of the products they already have for minimum investment. Some are only interested in collecting license and maintenance fees from existing customers and only need coders to fix severe bugs. You need to suss out which category a company belongs too.

The other big variable tends to go with size. Small companies tend to be more flexible and expect you to get involved in all aspects of the life cycle : design, build, test , deploy and support. Large companies tend to plug you into a specialized pigeon hole like "SQL author" and expect you to do nothing else for a couple of years.

Answer 3

There are 2 parts of IT in many investment banks: the infrastructure side and the trading side. The former handles the boring, standard IT systems and such for the bank. You are definitely a cost center and on the short list to have your job shipped to someplace cheaper as soon as possible. The second group is great to be in -- it is part of the income producing trading desk and tends to get some table scraps from that. Plus you are solving more interesting problem than report formatting and compliance with SOX.

Answer 4

I can't answer with respect to working in a software house, but working in an Investment Bank can provide just as many technical challenges and career opportunities as I imagine you would get in a software company.

I'll start with the technical challenges (my favourite part of the job); the closer you get to developing front office applications (applications used by traders), the challenges will get more difficult and the pressure for bug free code will be greater. You will often have complex business logic to develop in a well though-out, OO designed manner while still thinking about the "more important" stuff, such as performance, reliability etc. You will be able to use most open source software in any way you want (depending on each firm's policy) and you will often have to justify this use to your colleagues, leading to stimulating debate and improved decision making.

Alongside the technical challenges, you have the stellar career prospects and the opportunity to go as far as you could want to in your career. If your happy being a programmer with an extensive knowledge of financial instruments, you are capable of doing that. However, if you want to move up the ranks and start to manage a team etc, there are plenty of opportunities to do this too. Granted, this is the part of the job that most people don't look forward to and this can be difficult in an Investment Bank because it can sometimes come down to personal loyalties and networking over the course of many years, but for a programmer who wants that kind of environment, Investment Banking will provide that for you.

These are just some of the positives of working in an Investment Bank. There are negatives too, which have been mentioned before such as being treated like a cost centre and not being looked after like you would be in a software company (decent keyboards, high end PCs etc) but I definitely wouldn't cast aside a career in an Investment Bank because you think it won't be a good techy place to work. The technical challenges are some of the most difficult you will find anywhere else but you will have to put up with some of the internal politics in return for that.

Answer 5

The culture of pretty much all investment banks is to have people work insane hours (because every minute an investment banker is not working can be a missed opportunity to make millions of dollars) and pay them lots of money for it. From what I've heard, this also goes for their IT staff to some degree.

Of course, some IT companies have a similar culture (with far less justification), but many do not.

Answer 6

The difference is that in a professional IT company there is bound to be more programming and more focus on the code itself.

Keep in mind that most banks want something that works and when they get it up and running they don't change it very often. (hint hint you'll have to support old oooooold code)

You should pick the place that will help you grow as a developer the most.

Answer 7

I disagree with the person above who says software companies will respect developers because they are making the products on which the company's fortunes are founded.

I've worked for software companies, the sort who sell to dozens of customers rather than millions (but charge billions rather than hundreds), and banks. Currently I'm in a bank.

At a bank your customer is part of the same company and you will probably work quite closely with them. The days of a layer of business analysts protecting the business from code monkeys are pretty much gone now.

At a software company you will generally not deal directly with your customers. These companies have dedicated teams to deal with the customer. Your requirements will be fed through them.

Being close to your customer is important. At the software company the sales guy will get the kudos, at the bank your customer will be able to say that you did a good job. That pays dividends.

I certainly wouldn't go back to a software house.

Answer 8

I knew someone who worked for a while on the core trading system for an investment bank. He was a finance major - they found it easier to teach finance majors programming than to teach programmers enough finance. So, at least at his bank, you would never have the chance to work on the core trading system.

Which means that you would probably have a more valuable resume and more valuable skills as an embedded linux developer at a famous IT company.

Answer 9

What is the difference... good question.

Well, generally I would warn against joining development in bank without substantial prior experience in a mature software company.

• Thing is, professional software development experience gives an important point of reference helping to distinguish reasonable business-specific needs from dumb issues caused by immature IT culture.
   
  Without being able to figure that one risks getting stuck in wasting efforts and losing programming skills because of silly dev process mistakes that have been solved in software development industry 10... 20... 30 years ago

If one is willing to take above risk anyway, consider at least some preliminary investigation of how hard it could be at "target bank".

• Try to learn about background of your prospective team members. If there are guys with past experience in respectable professional software companies (the more the better), this naturally tames the risk since this means there will be someone with proper frame of reference in the team.
   
  Another way to learn things is "counter-interview" - you know, after you're done with answering, interviewers typically ask if you have questions. At that moment, just ask them to describe their typical way to develop and release some typical feature. Listen carefully, take notes, ask for clarification when needed. Study the non-verbal signs - if their story sounds accurate, relaxed and "routine", you seem to be on a good track. Note the subtleties for future analysis: frequent mentions of stuff like "for this part, we have documented clear step-by-step instruction so that we don't bother memorizing details" could make a big difference against repetitive "well in the process of doing this you will have a chance to meet and chat with many interesting new people from business side". :)

---

Another thing worth taking into account is "insane hours" support. There is a good discussion in comments in one of prior answers. My take on this is this is not "endemic" to banks but rather to the nature of trading software. I for one have been doing this kind support for trading application even in an extremely mature professional software company.

• If you do complicated trading code for worldwide use, there will always be a chance that your help will be urgently needed to save a few tens millions dollars somewhere at opposite timezone - no matter if you wrote that code in bank or in professional software company.

Still, there is a right and wrong way of doing such a support and in bank, there is a risk of getting it done the wrong way - simply because they may have insufficient experience in professional IT process.

I think it is difficult to find out beforehand, but one simple thing always worth checking is the typical "support duties schedule".

• In my experience, there was a tremendous difference between weekly support shifts done by 3 and 6 developers.
   
  Shifts "rotated" between 6 developers are to me as good as it gets. Yeah there is certain level of stress of having to be ready to pick up a phone 24x7 but it is far compensated by learning value and fun (yes fun - no kidding). Getting my hands in the heat of real application usage was very educative and inspired a lot of ideas on how to improve it - no amount of detailed spec/design discussions and controlled QA testing could substitute that.
   
  On the other hand, if there are 3 developers doing shifts, I would think twice and double-check if the salary compensates for what I lose. To start with, in my experience amount of distractions caused by spending 1/3 time on support duties was making a noticeable impact on programmers productivity - and that was the case even when support issues were infrequent.
   
  But probably the worst thing about it is that at this point, bus factor really rears its ugly head. Just think of it - imagine one of 3 guys having vacation or business trip or sickness - this immediately brings you into wasting 1/2 of your time on support. Note also it's like walking on thin ice - I mean even when things go smooth you have to always keep in mind that every little shake can "throw you under water" - that is, there is sort of permanent stress you have to live with.