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!

Reply to thread

Message: <blockquote data-quote="GoIllini" data-source="post: 28130" data-attributes="member: 2252">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 ---------- 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 ---------- 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.</blockquote>

Verification