Not the best of industries to be in at the moment but it'll recover in time.

I'll give you my perspective on this as someone who has worked in finance for roughly eight years--primarily in equities--in three countries (Australia, UK, Switzerland).

Investment banking--even IT jobs--I have found to be a bit of a boys club. The easiest path of entry is to go to a decent school, get good grades and then apply for a graduate program because once you've got a few years of IB experience, it's pretty easy to work for another one later. This is what I mean by a boys club.

But if you come to the industry later it can be a lot harder. The best strategy is to get in when the economy is good. When the economy is bad you'll find a lot more candidates per job and many of those candidates will have IB experience (eg like those who worked at Lehmans), putting you at a severe disadvantage, particularly in larger cities (where such work tends to be) where recruitment is often quota-driven so you may not even get heard.

By quota-driven I mean it's common practice for certain banks to use certain recruitment agencies called PSLs ("preferred supplier lists"). A given bank may have 5 agencies on their PSL and they will take 2 CVs from each of them for 10 total. Rarely more than half will be telephone interviewed, 1-2 will be interviewed in person and from there they'll get a hire (unless noone suitable is found).

Now in London out of all the places I've worked in particular you have some extremely unscrupulous behaviour from recruitment agents that can make this a challenging (actually I've used the phrase "soul destroying" to describe this process) scenario particularly in a tight labour market. The point is that you may think you've been submitted for a particular job. The agent may tell you that straight to your face but you haven't. This can go as far as fake interviews. But anyway I digress. The main point I want to get across is that in larger cities--where these jobs are concentrated--this can be tough to break into for many reasons when the economy is bad.

All that aside, there most definitely is useful domain knowledge you can get.

The first thing to understand is that there are many areas within IB: M&A (mergers and acquisitions), information services/research, corporate finance and so on. All of these areas have IT needs. But the area with the biggest concentration of IT needs is in financial markets.

Financial markets includes but is not limited to:

• Equities: ie the stock market. Now this gets the most press but is at best the third largest of the various markets;
• Foreign Exchange: self-explanatory and a huge market but not the largest. The biggest FX market is the interbank market which is an oTC (over-the-counter) market meaning contract sizes, expiry dates and so on are customized for the buyer or seller. Futures contracts in comparison have standardized expiries, sizes and terms;
• Fixed Interest: probably the largest market of all. Here we're talking about bonds and swaps (and derivatives). This is divided into government and corporate bonds and the largest segment is US Treasuries;
• Commodity Futures: this includes grain, soy and other standardised products on, say, the CME (Chicago Mercantile Exchange) but also includes oil and metals (eg LMX, the London Metals Exchange);
• Credit Derivatives: thanks to the sub-prime fiasco the general public probably knows a lot more about these than they ever did previously. Here we're talking about credit default swaps and the like; and
• Derivatives: these can apply to any market and include most notably options (ETOs--exchange traded options, which are standardized--or OTC) and can get pretty surreal when you start getting into the increasingly popular "exotics".

Now within each of those market segments you tend to have:

• Front Office: trading;
• Back Office: settlement; and sometimes
• Middle Office: this means different things to different people but tends to revolve around risk management, P&L (profit and loss) and the like.

My experience is almost all in Front Office where you're concerned with things like market connectivity, quote/pricing systems and so forth. Market connectivity is a big one. There are more markets out there than you've probably heard of. Apart from the obvious equities markets (NYSE, NASDAQ, LSE, etc) big ones include Bloomberg, Reuters, Tradeweb, EuroMTS and many, many others.

A key point to understand with banks is that typically they are price makers (also called "market makers") not price takers. If you trade stocks online you are a price taker. Typically when you buy or sell you do so from or to a market maker who might, say, have a quote on stock ABC for 32.03/32.11 (bid/ask) with a spread of 9 cents. There tends to be an inverse relationship between volume and spread (low volume markets have a larger spread).

Market makers tend to be unfairly maligned sometimes but they provide an extremely valuable function by providing liquidity (which is the ability to buy or sell quickly).

Now I mention the above to give you a broad base of understanding to see where iT systems are required and what sort of knowledge is required.

I'd say useful criteria are:

• Any technical work that is high-volume, low-latency, involves a lot of concurrency and/or is high availability is useful;
• Interestingly languages don't tend to matter nearly as much as domain knowledge. In fact it's fairly common practice for developers to use whatever the heck they want. Sometimes a particular stack will be mandated (eg Java/Oracle or .Net/SqlServer) but often that isn't the case;
• Web/scripting languages (eg Ruby, PHP, Perl, Python) are almost nonexistent. Perl is a possible exception in that you might find it used for support tasks. Not much beyond that though (in my experience). Java, C#, C++, Oracle, SQL Server and even Sybase rule the roost here technology-wise;
• A reasonable level of mathematical competency. You may not need to ever code a bond pricing formula but you may need to understand concepts such as discounting and the like. There are also fields that are highly mathematically focused and may even require post-graduate qualifications in mathematics, typically in the realm of game theory, Monte Carlo simulations and the like. Maths will only help you
• Basic knowledge of the trading/settlement process helps. I don't mean you need to know the Australian equities settle in T+3 but Australian equity options settle in T+1 but just what the order and settlement life-cycles are; and
• Basic knowledge of relevant financial instruments (including derivatives) within at least one of the above market segments.

You might consider it worth your while doing, say, a graduate diploma/degree in applied finance. Your country may have a professional body that offers such a thing or you can do it at a normal college. In Australia and the UK these tend to be one year full-time, typically done as two years part time. That's for a Graduate Diploma. Double that for a Master's. I don't really know the American equivalent.

You don't need formal education for this but formal education can be put on a CV. It's perfectly acceptable to read about this on your own (but harder to substantiate).

It's worth noting that following the financial press is also useful. You don't need to spend an hour a day going through the Wall Street Journal or Financial Times from cover to cover. I just mean some basic knowledge of whats going on int he world of finance. If you can explain what a CDO or a negative amortization loan is (both relevant to sub-prime) then it demonstrates a certain amount of interest and/or initiative.

Now I won't lie to you and ay you'll automatically get a job by doing such a thing but the knowledge can definitely be useful and it might help you stand out in a large field of candidates enough to get an interview where you otherwise might not. It will certainly hold you in good stead if you end up working in that industry.

I work as a developer in the financial industry. When I started I had 0 domain knowledge. Having that knowledge while certainly an asset is not going to be at the top of the list.

Let me explain. Banks and other financial firms are usually large organizations with well developed IT processes. As such they have project management teams, business analysts and subject matter experts a plenty. They don't need the guy writing the code to know the ins and outs of the business.

What then is important to getting your foot in the door? The number one thing you want is proven experience developing accurate high availabilty reporting systems. Reports, reports, reports and more reports. At the end of the day all the decision makers want are good reports. The important skills and concepts here are SQL (you should know it inside and out) and data warehousing.

The number two thing you want is experience doing system integrations. Banks don't write their own accounting system, trade order management system, loan system, etc. Most enterprise systems are going to come from third party vendors. What you need to know is how to get these systems talking to each other and playing nice. What for? If you guessed reporting you are right!

If you get an interview on the phone or in person at a financial firm stress reporting. It's what it's all about. Hope that helps.

I spent 7 years with an investment bank in London, both on the business side and in IT. I wasn't in charge of hiring but had enough insight and input into our team's hiring process to know something about it. (Caveat: I've only seen that one bank from the inside, so some of what I saw will not apply to the entire industry.)

The most common hiring route for developers was through graduate recruitment programmes. Experienced/lateral hires got hired because they had proven that they had very strong technical skills and/or because they a specific need - be that low-latency transaction processing or large-scale J2EE applications. Banks are large enough for specialization to make sense. As far as I recall, most experienced people were specialists in some sense (not necessarily language specialists).

Keep your eyes open, look at recruiting sites and banks' own career pages. Get an understanding of what skills banks are looking for.

Technical skills are important but banks pay equally much attention to thinking skills and people skills. Where I worked, developers were expected to be articulate problem-solvers, good at analytical thinking, with strong numerical skills, be able to take initiative, work effectively in a team, etc etc, all the usual stuff.

As for domain knowledge, unless you're aiming for a quant position, you don't need intimate knowledge of finance or financial products. Given a choice between an excellent developer with no finance skills, and an average developer who knows finance, the bank will hire the excellent developer.

But it does help to have some domain knowledge, because it makes you more productive, plus it makes it a lot easier for your colleagues to talk to you about their needs. It would be helpful to have some basic knowledge of the following:

• the basic concepts of finance (discounting, time value of money, risk).
• the main products and markets (equities, bonds, options of any kind, commodities, currencies), what their purpose is, and roughly how they work.
• the basics of accounting and financial statements (profit and loss, balance sheet, cash flow statement).

Money is not all.
If you're looking for job satisfaction, stay away from banks.
I have been working with my own company, and as a contractor in industry and in Finance.
My wife has also worked in industry and is now in banking.
We're both financially ok, but somehow frustrated by our jobs.
I think the best way to start (your profile does not show your age) is in a company providing service to clients. You will maybe be exploited, but you will learn, and have the satisfaction of projects having an end, and -maybe- a "thank you" for the delivery.
Look at jle's post: "auditing" "compliance" "versioning";. what excitment and satisfaction can a brain with a decent IQ find there ?

To specifically address your question: banks work with 40 yers old mainframes and Excel spreadsheets full of colors. So that's what you'll have to learn. 8-/

You should start with the following:

• read "A Random Walk Down WallStreet" = this will help you "get" finance, particularly equities investment
• read "Options, Future and Other Derivatives" by John Hull - this is a must, everyone knows this book
• Read Wilmott.com and signup for the forums

If appropriate mention that you have down all these things in interviews.

To get your foot in the door, you may need less domain knowledge than you think.

I liked this book - The Complete Guide to Capital Markets for Quantitative Professionals ^[1] as I thought it gave a nice overview of the markets and types of computer systems each market needed.

Gaining experience in high volume, low latency systems would be worthwhile. Also learning how to optimize database queries.

A lot of development positions in investment banking require investment banking experience. You might be able to get some of this by working for a company that supplies systems to the industry.

Also, telecoms experience is increasingly attractive to the investment banking industry.

You may also find this book to be of interest:

Mastering Financial Calculations ^[1]

Investment banking and writing code for investment banks are very different things. I assume you're talking about the latter. From what I've read, they don't much care which programming languages you know. They're looking more at your analytical abilities and experience with math.

The hard part is coming up with the mathematical models; if you can do that, they just assume you can write the code (or it's outsourced to someone earning a lot less).

I think a degree in economics, mathematics or computer science is more or less required to get into the business. I'm sure there are exceptions, but it's going to be tough without that kind of knowledge.

• Try applying for tester position.
• Try similar niches (like insurance).
• Make friends in bank IT department.
• Get lot of certificates. They like it.
• Keep applying for positions even though it is recession in the industry. But to me it looks like IT is on the rise because everybody try to optimize their systems to cut human expenses
• Look for companies that write software for banks. Many banks are outsourcing other companies (I did this)

What is your background? What is your degree in? Did you graduate?

Most programmers in investment bank don't have to know much about finance, it's more about high speed transactions.

Those who want the money side usually work as Quants and often have Ph.Ds. in related topics.

Here are two books that I'd recommend: one ^[1] about financial modeling and another ^[2] that's a cautionary tale about modeling. Everyone quant should know who Taleb ^[3] is.

I would suggest try entering a support position in a bank to as high a level as you can in terms of support as you will notice that most of new coding comes up in banks from Support Teams. Whether it works or not but the support position will teach you a lot of fundamentals very nicely and quickly. Then you can look at becoming a contractor. Make sure you have an exposure to accounting and finance (even very very basic if fine). Regards, Andy

Spent some time in the area. If you are serious about getting in I'd look at completing CFA level 1 or some form of quantitative finance course.

The people who earn the big bucks are usually the people who understand the financial products themselves. The technical stuff is seen as an after thought in most cases.

"An Introduction to Capital Markets: Products, Strategies, Participants" is an excellent introductory book.

It couldn't hurt to know EVERYTHING about the Sarbanes-Oxley Act ^[1]. Compliance is now a HUGE industry and 'SARBOX' requires incredible amounts of transaction auditing, versioning, etc. Programming concepts abound...