Typically C++ although there is a growing number heading off to other languages (ML family being one that is growing influence-SML, OCAML). I am no programming guru (far from it). My only problem was the fact that the poster i replied to had no idea about the value of quant and quant traders in their ideas of risk management, implementation of strategy and research.
what level of C++ understanding do the wall street quants have in general? 1-2 courses? a friend of mine who says he taught himself C++ says you can already do a lot if you know how to mess around with variables, write if statements, and do loops. for other more specific things that you need to do for your project, you can search google, look at exampes, and tweak them to fit your needs. is this true?
Just learn any programming language. It doesn't matter which one. Once you learn one you can evolve into knowing others. I have run profitable trades written in: C++ VB C# perl python Excel I have backtested and designed profitable trades with: easylanguage CQG R (S-Plus clone www.r-project.org) MATLAB Tradestation/Easylanguage eSignal You quickly learn that it is the algorithm that matters about a thousand times more than your programming language or choice. Each of the tools above is best in different scenarios. What will matter most is the execution speed and restrictions of the order routing and pricing APIs you are using when you start trading real time. In my case i use the XTAPI and TT FIX API. I used to work closely with a quant/trader who was very bright (option vol arb strategies, option market making, futures stat arb trades, etc.). He had a couple of courses in C++ and knew perl. That was plenty enough for him. What was a lot more important than his programming skills were his other skills like: market experience, patience, discipline, knowledge of GA and other optimization techniques and so on. Bottom line its the algorithm that matters.
one last tip... I've found that the fastest way to learn a new programming language is to try to solve a real problem with it... so pick a project... ideally a market related one that isn't too difficult... and dive in. maybe get some price data and research a question you've always wondered about. try to frame every thought you have (or read on ET) about the market as a scientific hypothesis that you can design and experiment around and test. be rigorous. Try to vet everything that relates to your trading. Programming languages often are a convenient way to do that.
Isn't this how all companies work ? You are paid X and expected to generate many multiples of X for the company. There are degrees of this expectation however. Some companies are happy if you make them money and reward you for your contributions. The vast majority do not, and prefer to build their employee base by mining information, extracting it, and then removing the expense: the typical attitude in the engineering professions where projects last about 12 months these days after which time you are expendable. My point was that if you really are able you can disconnect yourself from these types of jobs and put your IP to work within an entity that you control and thus bypass the vultures to some degree and ensure that within your comapny the vultures and hyenas are never hired in the first place .....
Not really, almost all the quants on wall street have to get used to the libraries that have been coded up over the years within the ibank. Hardly any application is developed without reusing some piece of existing code. And depend on the history of the group (or even the ibank), there can be significant amount of historical / legacy / library code. For instance, the I went to London to help out the european modeling group back in 2000 in cleaning up their base libraries (18 libraries in all), just their core library takes about 6 hours to compile, on a dual-proc 2.2 (fastest at the time). There tends to huge amount of historical code in all languages (S-Plus, C/C++, Lisp, etc), getting used to them is a huge part of the learning process. The problem is that they tend to be poorly documented, hacked together, and often the author(s) are now no longer there. I have to say, the code base I saw ranges from out-right brilliant (one person wrote entire set of monte carlo for tranche pricing in probably the most creative use of template operators) to down-right terrible (the code won't even compile in latest version of C++), etc. So the coding skills for the Quants varies greatly. There are plenty of job specs for "Quants" that read like developers (this is a slightly new thing for the last 2-3 years), but I have been out of the modeling game for that long. I am somewhat suspicious of those type of specs, I think it probably is just a "cover" for the business side to hire coding grunts of their own (which i have seen many many many times). Real Quants spend most of their time doing research and modeling (in code), but not system building.
Exactly my experience: The key point here is that the classic definition of "quant" really does not apply anymore. Yes, there are still "pure" quant jobs where you spend your time doing only analysis and model design. However to one degree or another, most jobs labled as "quant" involve software design and implemenation. Rufus is dead on when stating what was encountered - many libraries of varying quality often writen in different languages. Consolidation of these libraries most large firms is still (today) a wish or is stated with a slight smile. At many of these companies the lack of documentation is completely rational: there is no way the architects and maintainers will help with consolidating their way out of a job. This is the key problem at many firms - they are in fact held hostage by their own employees who in some cases hold the only true understanding of how these hodge podge systems are put together. If I were to tell you the firms that still have this issue today you probably would not be too happy about having your funds under their management ......
i'm not sure if i understand. how much C++ does one need so that he can claim he knows enough to do the coding work of a quant analyst? 1-2 courses or many more?