What do programmers at investment banks do?
Several people on this thread have stated most NY programmers work at investment banks. What exactly do they do? I vaguely know what derivities are, and I know there's various formulas to compute their value--are investment bank programmers just filling in a spreadshet with the appropriate formulas or something? Or is there at least a little bit of interesting work?
Wednesday, March 19, 2003
I am not sure that MOST of the programmers work at banks, although that may well be true. They do a lot of programming there.
Banks manage large amounts of data and therefore have to interact with databases often. They have customer data, company financial and stock price data, deal data, the list goes on. Then they have their Intranets and their public websites. They have customized documents and document management. They have financial models, some of which get really complex. Also some have real time trading systems which have to be reliable. This is only a partial list.
Derivatives (generally options, futures and swaps) math is generally done by a PhD somewhere and implemented by a programmer. It is a specialty.
There is (my opinion) a decent amount of interesting work but it is mixed in with even more tedious work. And there is lots of maintenence programming of systems that have been shredded by a parade of different short-lived consultants.
Thursday, March 20, 2003
At the very very top tier investment banks, they have a tendency to hire the best and brightest programmers at high salaries simply because they like to buy the fanciest everything; these programmers, like all programmers, love to play with fun toys, and so they persuade the banks that what they REALLY NEED right now is to rewrite the entire trading system in (.NET/Java/Python), and often they get away with it.
Seriously, though, even at the best iBank programming jobs, most of what you'd be developing is In House Code which means (a) only a handful of unhappy people ever use it (b) once it kinda works, any additional improvements are not valuable so "good enough" is the mantra (c) programmers at iBanks are a cost, not a profit center, so your career path is limited compared to working for a software co.
On the other hand there are also a bunch of actual software companies in New York that develop software for the financial industry. All else being equal these might be a better place to work than pure banks because as a programmer you're the profit center.
Finally -- there are a handful of elite hedge funds doing trading strategies that are implemented entirely by computer; at places like DEShaw and Tower Research Capital what you're coding is an actual investment strategy so programmers are very much in the middle of things.
Thursday, March 20, 2003
I have a little different spin than Joel on what it is to be a programmer at an investment bank. I worked on Wall Street for about 12 yrs in different roles, some of it involved programming.
Most senior managers at investment banks (especially those that derive a lot of revenue from trading vs. fee based business) are extremely concerned with risk management. They realize that good systems are crucial for good risk management. They do not want any Allied Irish Bank or Barings kind of blow-ups.
So even though the programmer does not generate revenue, he or she provides a very important service to management, and management wants and needs good programmers and program managers around.
I know of a few programmers who made pretty successful careers through being good at what they do and completely aware of how they can add value to the running of the organization.
Monday, March 24, 2003
It seems that very often in finance you are working very close to the traders or agents or analysts or whoever it is that use the software. I've also heard stories of them running into the room, throwing heavy equipment at the developers, and storming out. Sounds like someone needs a better QA team.
I think your milage will very between dev teams even within a single company. I interviewed with Goldman and was extremely underwhelmed, but given a different group supporting a different product and I'm sure it would be a different story.
Tuesday, March 25, 2003
I've worked for one of the top-tier investment banks that Joel mentioned above since I graduated in 2001, a place I also interned at for two summers prior, so I'll share some of my experiences etc here.
With most investment banks, there are two distinct pieces, which by nature must operate independently: trading (ie all non-banking activities) and investment banking.
It's very, very important that trading and banking are physically and logically segregated.
I personally work on the banking side of things, so I can't speak so much to the trading side. I know their focus is more on real-time systems, of course, but beyond that I don't know specifics. And there are also specific groups within that that have a different focus/goal/direction based on the business unit they support.
I've worked in software development / engineering. Essentially, the applications that help the bankers make better decisions. Some of that is in deal analysis, financial modeling, and so on; some of it is CRM.
Within our department, there are many aspects of IT, of which software development is just a small piece. You have operations - which includes things like the help desk. You have a big InfoSec-ish group, because as Charles points out risk management, security, and things like business continuity and disaster recovery are very important in the financial industry (the latter two especially so post-9/11). There's infrastructure, who deal primarily with hardware and platforms and 3rd-party products that are delivered to the bankers. There's also groups that interact with the bankers and know their business and work to develop strategic solutions that deliver more value.
As I mentioned, software development is just a small piece of the overall IT picture in a financial institution. It's size and focus also varies largely from firm to firm I'm sure.
I've been blessed with the ability to work on some pretty neat projects from a technical perspective though, and I've learned a lot about enterprise and frameworks development - so in that sense it's been pretty rewarding.
That being said - as Joel points out above - you're not revenue generating, you are essentially in a support role. And to be honest, to many bankers (some of my friends included), if you're in technology you might as well be on the helpdesk answering phones. There's no difference to them. If and when I were ever to leave this firm, I would definitely want to be in a revenue generating position.
Oh well :)
Wednesday, March 26, 2003
As a programmer at one of the "top-tier" investment banks, I can say programming jobs vary WIDELY between various groups. On one end of the spectrum you could be doing maintence work for a legacy technology, or you could be working on a cutting edge project that meets every requirement of the "Joel Test" for software development. Some of the people at these banks are absolutely brilliant, everything however is dictated by the business side of things. There are alot of situations where a computer system has to be up and running, and you are told to take every shortcut needed to meet that goal. (Conversely, there are situations where you are required to thoroughly design and test things) It is basically an environment where there is a willingness to embrace and invest in technology, as well as take risks with it.
Thursday, March 27, 2003
How well the market is doing also dictates that. When times are good, and there's a ton of work to be done, you take the shortcuts because even a small gain in productivity translates to real dollars.
When times are slow and there's not a lot of deals going on, it's more important to manage risk (reputational or otherwise) and save money.
You essentially use the "down time" of a slow market to position yourself to be ready when things turn around.
Friday, March 28, 2003
I worked for the Fortune 1 company - Citigroup in the a technology department at one of it's many segments.
What projects are undertaken and the direction of the company - expand/contract tends to be cyclical. This means:
a) a lot has to get done in little time to catch up with the comptition who was on a different cycle and therefore is now more cutting edge than you
b) you end up with legacy systems nobody knows how to integrate.
Another thing is when you have a company that's large enough, with enough different sections, and is the result of enough mergers, you have a LOT of legacy systems. So the merger happens so that company A can also sell the products that company B sells, from a programmer's perspective that means integrating totally unrelated systems.
So you have system A that has 7 address fields, all 25 characters long and system B that has 2 address fields, all 100 characters long, and you want to make both available to the client in something approaching realtime via your award winning banking website, how do you do it?
And when he gets a statement in the mail that says he has $50,000 in the bank, goes online and sees he has $56,000 in the bank and calls his banker to ask which is right and is told he has $43,000 in the bank because all 3 are on different reporting timelines, he gets pretty pissed.
Also, old banks have a lot of paper processes and informal processes (phil calls joe and asks if he can send over form x and please process Mr. Gates' yacht loan applicaiton). All this gets exposed when you go online. "Why isn't my Yacht application showing up when I sign into your website?"
Saturday, March 29, 2003
Oh yeah, not to mention processing ATMs, debit cards, credit cards, checks, loans, transactions via your website, interest, delinquant payments, bankruptcy, automatic billpay, stock transactions, 401k disbursement, transactions at the teller, risk assessment, fraud flags for credit card transactions, and more, again, in something approaching real time.
Saturday, March 29, 2003
What do programmers at investment banks do?
Well, where I work they either look for work elsewhere, resign themselves to sticking it out until after bonus time, complain incessantly or cry themselves to sleep at night (when they are not being woken to do tech support at 3am, that is).
And, of course, cover their behinds at all costs.
And deal with layers and layers of beauracracy filled with stunningly incompetant people.
Other investment banks may not be the same.
Sunday, March 30, 2003
Gustavo - I doubt it. At least, not at the large ones. That's basically what life is like at the larger Investment Banks... and I doubt it's just for the tech people.
Sunday, March 30, 2003
Quote Joel "(a) only a handful of unhappy people ever use it"
why should they be unhappy? For me one fo the best part of doing intranet apps has always been the happiness that I bring to the users. Since most of the time they had been fed crap for so long you don't have to be a brain surgeon or rocket scientist to make them happy.
Tuesday, April 8, 2003
I worked for a couple investment firms. Please remember that the most important people to a firm are those closest to the type of firm. The CFO of a Finance company pulls a lot more weight than at a software company and vice-versa. If you want more say and input, I recommend a software company rather than an in-house programmer at a non-software company.
Friday, April 11, 2003
Fog Creek Home