• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

BlackRock or Credit Suisse?

Joined
11/8/09
Messages
11
Points
11
Hi,

I would need some suggestions from you guys:

1. I got an offer from BlackRock for their Portfolio Analytics / Automation group. Basically a lot of Perl scripting as far as they told me.

2. I got an offer from Credit Suisse (NY office) for their Equities Derivatives IT group. Basically programming for traders on a day-to-day basis.

Both have exactly the same pay and sign-up bonus.

Q1: What would you guys suggest? I just finished my degree in Operations Research and it would be neat to move towards quantitative things, but these are the only two offers I have until now, so I have to pick one of them :). Anybody got good/bad experiences with either company?

Q2: Did anybody interview with CS during the last 2 weeks as well for Analyst positions? Did you guys also have the feeling that the process was very easy? With BlackRock I had like 7 rounds of interviews, but with CS it was 4 on-site interviews of 30 min each and that was it.

Please let me know.

Christian
 
We have many members here who work for that same group at CS. I have interviewed with them in the past, different group but the guys flatly told me their IT system isn't the greatest and you basically spend your time trying to learn and get little piece here and there to work. IT at CS has a reputation of its own. And I'm saying this in the nicest way I can.

I took class with a guy at BlackRock in that group and he seemed pretty happy with his job.
 
Yeah, I've heard the same that CS IT isn't the best. However they told me that this group is as close to Traders as you can get within IT. And given my long-term goal it might be better.

I'm just not sure about the BlackRock group. They are responsible for the day-to-day risk reports creation. Therefore I'm not 100% sure whether it is more like an Operator/Scripting job.

Anyone else with pros/contras for CS or BR?
 
Yeah, I've heard the same that CS IT isn't the best. However they told me that this group is as close to Traders as you can get within IT. And given my long-term goal it might be better.
What will be your exact role at CS? What language you will be programming etc? Do they have their own trading system? What do you mean by 'as close to Traders'. Sometimes traders may be just looking for some reports which can be written in perl.
 
The group in CS is called "Equity Derivatives IT".

They told me that we basically have to implement the things, the traders/quants come up with. It is a really small group (~8 people), therefore I assume that it is basically creating tailored applications for the traders.

Languages used are C# and VBA. They told me that there is a lot of Excel around, which they want to bring into C# (only a part of my duties).

My goal is to learn as much about the business as possible, therefore I'm a bit worried about the BR position. They have their own FM group and I fear that I won't get much insight into the business. On the other side: The CS interviews were really extremely easy - not sure whether I should take that as a important indication.

Nobody here interviewed with CS during the last couple of weeks?

Christian
 
This position has a traditional trade support flavour.

IB's usually split up their IT task force into development and support roles. Check with them what the nature of your role will be.
 
@AnoopRN: It depends. They told me that they both do day-to-day support of traders, but also have larger projects.

Is there something speaking for/against supporting roles?
 
If you search for the same job title at CS on several quant job boards, you will see the same "supporting trader" sentence in there. It doesn't mean you will be sitting on the trading desk with the traders. It will be you sitting on your little cubicle trying to fix many broken spreadsheets and curse yourself. It's a pure IT job and I hear the C# plan many times. It's ain't going to happen. Don't say I didn't warn you. You may thank me someday.
You aren't hired to learn about business. You are hired to keep the spreadsheets working, the machine humming. You can do better than this.
If this is your first job in finance, maybe it's worth a try so you learn how to identify a better job in the future.
 
@Andy: Okay thanks. I will think about it - do you think the quality of the job is also a reason for the really easy interview process? I know I keep mentioning it over and over again. But I had like 30 interviews the last 2 months and this was really the easiest by far.
 
Support deals with production and change management of existing systems. Real time support for trading systems can be quite demanding, and offers a good opportunity to study/understand the business. However, depending on how you approach it, this understanding has a tendency to be strictly functional.
 
I don't know the quality of your particular job position but I was warned against taking a similar job from someone who works there and started in the IT group. My interview was pretty much similar (phone, in person with several people in the group, 30 minutes each). I interviewed with 2 similar groups so I was able to cross examine what the job is actually involved.
All that said, there are things valuable to be learned if you take the job. If that fits in your future plan, so be it. If not, it may be hard to leave and may not give you any competitive advantage on your next job.
 
@Andy: Okay thanks. My goal is basically to make the transition to a quantitative group or become a trader.

Which job did you take in the end?

Christian
 
No firsthand knowledge on either of these (I am still in school), but I have heard both sides of the coin re BlackRock.

A downside might be work hours. Do they still work Sundays? Before I decided to return to school to ease my transition from engineering/military, I interviewed at BlackRock with PAG. I think my response to work hours really did me in. Also, one of my headhunters said they could pay the bills only placing people out of BlackRock, which is also an upside.

Another upside: My friend use to trade MBS at Citi (and was able to transition to a new role) and had a colleague who started in PAG at BlackRock. He said this guy was the sharpest guy on the desk and had gotten a pretty good education in finance at PAG. (Do either of these have formal training, or is it all on the job?)

Completely anecdotal evidence, so don't assign much weight to these, but they may help you ask yourself a few more questions.
 
@herron: Which job in PAG do you mean? I interviewed for a 10 person team - they basically create the scripts which create the Risk reports on a daily basis. And fix it in case something goes wrong.

Nope no formal training whatsoever. You will learn on the job.
 
I don't know the quality of your particular job position but I was warned against taking a similar job from someone who works there and started in the IT group. My interview was pretty much similar (phone, in person with several people in the group, 30 minutes each). I interviewed with 2 similar groups so I was able to cross examine what the job is actually involved.
All that said, there are things valuable to be learned if you take the job. If that fits in your future plan, so be it. If not, it may be hard to leave and may not give you any competitive advantage on your next job.
When did you interview with CS? It must be several years ago. They already started migrating the spreadsheets to C#.

@Andy: Okay thanks. I will think about it - do you think the quality of the job is also a reason for the really easy interview process? I know I keep mentioning it over and over again. But I had like 30 interviews the last 2 months and this was really the easiest by far.
It is surprising you had 7 rounds of interview for a Perl scripting job and only 4 rounds for C# job. Which one you want to do? Do you want to do advanced perl scripting or basic C#.
 
@Elliot: Both are Analyst positions. C#/Perl are simply the languages they said they use.

-> In don't really care about the language. For me it is more important to be able to learn as much about the business as possible. C# is neat, but Perl is fine too.

-> 7 is more or less the average number of interviews I had for all companies I interviewed with. Except CS.
 
All other things being equal right now, if someone has on their resume that they spent the previous two years at BlackRock, that looks better than saying they spent the previous two years at Credit Suisse.

That said, the C# job seems more interesting to me. I'd much rather be working on Excel spreadsheets than in Perl. Where I work, perl is used mostly for batch processing and other infrastructure work and not a whole lot of business decisions get made by Perl scripts. I work at an investment bank like Credit Suisse.

The group you're getting hired into sounds like the equities version of one of the fixed income analytics groups I work with. It sounds like that position is at least as close to the business as any financial programmer gets, but it sounds like 80% of your work will be development (probably actually fixing other peoples' code) while only 20% will be finance. Compensation in most of these positions tends to look like a hybrid of IT and research or a quantitative group, but make sure you ask, "Will my bonus look like a trading assistant's or an IT bonus?"

With C#, you have the opportunity to interact with the users and there might even be a lot of business logic built in. BlackRock carries a stronger name, but if you like finance, you should think about the CS job. Working in an analytics group is a difficult and sometimes thankless job that often feels entirely like an IT position, but ultimately, you get to become an expert on your product. Salespeople and Researchers (and sometimes even traders) will come to you and ask why a number is a certain way, and you'll be able to explain to them why a certain number changed after a stock split or why the system is giving an "unexpected" P&L for a covered call position after a dividend payment. It's a nice (but demanding) job for a programmer who likes finance, and if someone with a quantitative background puts up with a few years of fixing bugs and answering questions that traders don't know the answers to but expect "IT guys" to figure out, you might be well-qualified for an algorithmic trading position in the specific market you worked in.

---------- Post added at 11:34 AM ---------- Previous post was at 11:18 AM ----------

If you search for the same job title at CS on several quant job boards, you will see the same "supporting trader" sentence in there. It doesn't mean you will be sitting on the trading desk with the traders. It will be you sitting on your little cubicle trying to fix many broken spreadsheets and curse yourself. It's a pure IT job and I hear the C# plan many times. It's ain't going to happen. Don't say I didn't warn you. You may thank me someday.
You aren't hired to learn about business. You are hired to keep the spreadsheets working, the machine humming. You can do better than this.
If this is your first job in finance, maybe it's worth a try so you learn how to identify a better job in the future.
I'm pretty sure I have that job on the fixed income side at a different bank and it's not pure IT. Often, YOU are asked questions that the traders can't answer, and if you can't answer them, it winds up having to go to one of the quants. I am expected to be able to explain in broad terms every single one of the numbers we generate and why they might move a certain way. This includes everything from random spreads to durations, and sometimes, you have to look to a general picture of the models your system runs to explain why a number makes sense.

Yes, it's 80% IT. Yes, you will spend twice as much time playing detective and hunting down bugs at 2AM than you will spend time in front of a Bloomberg terminal. The pricing systems require first and foremost a very strong CS/Comp. E background rather than a financial background. But it's not pure IT. You have to become an expert on your products and have the ability to translate from pricing-engine-speak to financial-speak and you'll certainly work with a few quants- at least well enough for them to know the quality of your work- during your time at the firm if not also research people, risk managers, and maybe a trader or salesperson. This is something that people in infrastructure, middleware, and the booking system typically don't get to do.'

Two of the people in my group sit on the trading floor. Other groups have rotating seats. They may be exaggerating a bit when they say, "it's as close to the traders as IT gets"- there may be other groups under your MD that might be closer, but it's difficult to call this a purely back-office IT role.

An MFE should be able to do better in a decent economy, but working in equity analytics at a major investment bank is not the worst possible place to land. In particular, as the market moves more and more towards algorithmic trading, this will certainly give you the proper tools to make the transition. Our group usually has a few people transition to the business side every year- the door from our "middle-office" roles to the front office is pretty narrow, but it's clearly open.

---------- Post added at 11:40 AM ---------- Previous post was at 11:34 AM ----------

@herron: Which job in PAG do you mean? I interviewed for a 10 person team - they basically create the scripts which create the Risk reports on a daily basis. And fix it in case something goes wrong.

Nope no formal training whatsoever. You will learn on the job.
This screams "pure IT" to me. Our risk system is sandwiched between the trade display interface and the pricing systems and basically manipulates the ordering of the numbers and does a little accounting work. It's an important system, but it has no direct contact with the business and is pretty devoid of financial logic. The perl scripting part- rather than at least database or Java work- just accentuates the fact that they need a code monkey.

All things being equal, it might be better to have a foot in the door at BlackRock than CS, but I'm under the impression that the position at Credit Suisse offers more relevant business and quantitative experience. Hence, I would lean towards the CS offer. Ideally, if you have an MFE, I'd look for an offer from Sales & Trading, but Credit Suisse Equity Analytics is still a respectable place for a financial engineer- even from a top 20 school- to land during a recession.

These are the opinions of a financial programmer at a different investment bank who doesn't work in equities. I also have only worked at one firm in essentially one role for two years, so your experience might be different than mine.
 
An Illuminating post!

Pertinent to note in this thread that some IB's specifically categorize individuals who collaborate between Business and IT teams as 'Business-Analysts'.
 
An Illuminating post!

Pertinent to note in this thread that some IB's specifically categorize individuals who collaborate between Business and IT teams as 'Business-Analysts'.
You see that, but a lot of the banks, including the one I work at, don't always have business analysts. Many of the programmers are C++, Java, and Perl developers, production services people, and Business Analysts all rolled up into one that center on one, two, or three different systems along with a team of another five or six programmers.

The term that many banks use for these guys is "Analytics Developers". The designation typically extends to people who work on the pricing systems and quantitative research/trader tools, and the designation sometimes extends to product maintenance, trade display, and market data. Analytics used to be considered part of the business but is now getting shifted towards IT. I still think it's a good place to start a career if you want to eventually get into algorithmic trading in the particular product you serve. You learn all about the products and the numbers these systems need to manage their books and you get a lot of development experience.

I've never worked in algorithmic trading, but I'd like to think someone with a C# background from a Credit Suisse equities analytics group would be considered a safer bet for an equities trading system than a hire directly out of an MFE program. I can't say the same thing for someone who wrote risk infrastructure scripts- especially in a group that wasn't product or at least market-specific.

Analytics is a great place for a developer to land in a bank (the third best place short of a pure quant development or algorithmic trading group). For MFEs, there are much better places to land, but I think it's still pretty respectable with 15% unemployment in the financial sector.
 
The group in CS is called "Equity Derivatives IT".

They told me that we basically have to implement the things, the traders/quants come up with. It is a really small group (~8 people), therefore I assume that it is basically creating tailored applications for the traders.

Languages used are C# and VBA. They told me that there is a lot of Excel around, which they want to bring into C# (only a part of my duties).

My goal is to learn as much about the business as possible, therefore I'm a bit worried about the BR position. They have their own FM group and I fear that I won't get much insight into the business. On the other side: The CS interviews were really extremely easy - not sure whether I should take that as a important indication.

Nobody here interviewed with CS during the last couple of weeks?

Christian

There isn't much detail about either job. With information available, I would tend to agree with GoIllini and choose BlackRock for the brand-name.

Furthermore I would stress out that it is useful for anyone to know Perl (or some flavor: PHP, Ruby, Python etc). It offers a clean and flexible language for quick coding. Pattern, matching, hash structures are easy, get results in 5 minutes.
I agree that it doesn't have a solid theoretical foundation, limited OOP, but many times you don't need complete software design. This is especially true if you are in trade support.
And for people that spend more time on it, Perl has significant depth. You can just thing about ~17,000 modules that can be plugged into any code.
 
Back
Top