- Joined
- 5/2/06
- Messages
- 11,752
- Points
- 273
The financial industry is a big playing field. As domains go, the type of specific work varies greatly, and what is applicable to some IT professionals may not be applicable to others. Here's a primer.
In order to put things in perspective: I write code for distributed enterprise trading systems. From the perspective of a techie, this amounts to writing tons of highly multi-threaded client-server code. While the code ranges from dealing with incoming market data and prices, to managing load-balanced engine processes that calculate the optimal prices for outgoing quotes, in the end it all comes down to necessarily efficient client-server code.
That said, there are plenty of jobs in the financial industry targeting database administrators, system administrators, quantitative analysts, maintenance script coders, QA personnel, and GUI developers. If your niche is one of these, much of the advice presented here still applies though your mileage may vary. So what's expected from an experienced developer looking to join the ranks of trading systems programmers? Well...here it is, in a nutshell.
C/C++
C is heavily used, not only as part of maintaining legacy code, but also as a way of dealing with APIs distributed by electronic exchanges and data feed providers. The 'extern "C" {...}' statement is a common occurrence, so it's important for a developer to not only be comfortable with cross-language linking semantics, but also with concepts such as memory alignment and padding (dealing with complex structures on the stack and otherwise), as well as void and function pointers (a well accepted mechanism for calling C++ methods from within C callbacks).
C++ is the predominant language on Wall Street for the work that I do. While Java, and to a lesser extent C#, are slowly gaining in popularity, trading systems prioritize speed over stability. The quote going out to the exchange can pass through your brilliant, well-designed, object-oriented, design-pattern-supported system with no exceptions, but if it hits the market a few milliseconds late because the garbage collector decided it was time to clean up the place a bit, you lose money.
At the same time, there's no concern regarding the extreme outskirts of the C++ language. As an example, there is no business or technical motive to explore the techniques of template meta-programming. Silly template tricks are the stuff of computer journals, not enterprise systems. You are however, expected to be comfortable with the nuances of general template programming, some common design patterns (nothing more complicated than Singleton), common issues arising from static instantiation dependencies, proper order of object instantiation in an inheritance chain (virtual and otherwise), problems arising from object copy semantics (especially with pointer members and copy-on-write implementations), and virtual table concepts.
Client-Server Concepts
By definition, Wall Street trading systems are distributed systems. Almost all firms, from tiny market makers to international investment banks, build their systems on top of some framework abstracting UDP. At a higher level, inter-module communication is done with some combination of TCP and UDP. UDP (or rather layers on top of UDP which guarantee packet delivery) are used heavily since the systems are built with parallelism in mind (once again, speed over stability). As such, you should be comfortable with C level socket concepts such as socket(), bind(), poll(), and select(). In all likelihood, you will never use these directly, since these things will have already been abstracted away into socket libraries by the time you arrive on the scene. However, you will be expected to know these concepts, as they are the building blocks of any system you'll be working on.
Threading
Client-server code and threading go hand-in-hand. In fact, you will often encounter this combination in the work you'll be doing. Issues come up dealing with typical TCP server design, load-balanced server design, and high-throughput server design. At the very least, you should be comfortable with the typical academic reasoning: "Fork a process once a request comes in and let it deal with the client, so that the server is free to listen for subsequent requests." You also need to be comfortable with pthreads(), fork(), mutexes (and semaphore concepts in general), as well as higher level things such as Java methods synchronization.
Databases
Note that the topic is Databases, not SQL. Aside from knowing how to do simple select statements, you should have an understanding of the useful properties and limitations of stored procedures, the concepts behind database indexes (clustered and otherwise), and the distinction between table-level, page-level, and row-level locking.
UNIX
UNIX (primarily Solaris and Linux) is still the platform of choice for trading systems. While you will have a Windows machine under your desk, you'll mostly use it for e-mail. Everything from checking log files to debugging core dumps is done in a UNIX environment, and so you really should be comfortable with commands such as tail, sed, grep, awk, tr, and top. It also helps greatly if you are comfortable with either vi, vim or emacs, and have enough experience to not be surprised at the kind of problems that stem from an incorrectly configured $LD_LIBRARY_PATH.
Debugging Skills
I'm not referring to the integrated debugger built into Visual Studio. At this point in your career, you're expected to be able to analyze a core file with dbx, or gdb (from the command line - there won't always be an X-server available). While you won't be spending the majority of your time doing this, when a situation calls for a debugger, it pretty much cannot be addressed with anything else but - so know your stuff.
On a final note, let me ease what I know to be the primary concern of developers looking to make the transition into the financial field. No one expects you to have a deep understanding of the financial markets or specific knowledge of financial instruments. This is domain specific knowledge, and you will attain it almost through osmosis, if not explicit training, as you progress through your career. When applying for subsequent jobs, the interviews will involve financial domain discussions, but at your first interview on Wall Street, if you let it be known that your current experience does not cover topics in the financial arena, no one will hold it against you (assuming that you are not applying for a job where such knowledge is of utmost importance).
Source: http://news.efinancialcareers.com/ADVICE_ITEM/newsItemId-10336
In order to put things in perspective: I write code for distributed enterprise trading systems. From the perspective of a techie, this amounts to writing tons of highly multi-threaded client-server code. While the code ranges from dealing with incoming market data and prices, to managing load-balanced engine processes that calculate the optimal prices for outgoing quotes, in the end it all comes down to necessarily efficient client-server code.
That said, there are plenty of jobs in the financial industry targeting database administrators, system administrators, quantitative analysts, maintenance script coders, QA personnel, and GUI developers. If your niche is one of these, much of the advice presented here still applies though your mileage may vary. So what's expected from an experienced developer looking to join the ranks of trading systems programmers? Well...here it is, in a nutshell.
C/C++
C is heavily used, not only as part of maintaining legacy code, but also as a way of dealing with APIs distributed by electronic exchanges and data feed providers. The 'extern "C" {...}' statement is a common occurrence, so it's important for a developer to not only be comfortable with cross-language linking semantics, but also with concepts such as memory alignment and padding (dealing with complex structures on the stack and otherwise), as well as void and function pointers (a well accepted mechanism for calling C++ methods from within C callbacks).
C++ is the predominant language on Wall Street for the work that I do. While Java, and to a lesser extent C#, are slowly gaining in popularity, trading systems prioritize speed over stability. The quote going out to the exchange can pass through your brilliant, well-designed, object-oriented, design-pattern-supported system with no exceptions, but if it hits the market a few milliseconds late because the garbage collector decided it was time to clean up the place a bit, you lose money.
At the same time, there's no concern regarding the extreme outskirts of the C++ language. As an example, there is no business or technical motive to explore the techniques of template meta-programming. Silly template tricks are the stuff of computer journals, not enterprise systems. You are however, expected to be comfortable with the nuances of general template programming, some common design patterns (nothing more complicated than Singleton), common issues arising from static instantiation dependencies, proper order of object instantiation in an inheritance chain (virtual and otherwise), problems arising from object copy semantics (especially with pointer members and copy-on-write implementations), and virtual table concepts.
Client-Server Concepts
By definition, Wall Street trading systems are distributed systems. Almost all firms, from tiny market makers to international investment banks, build their systems on top of some framework abstracting UDP. At a higher level, inter-module communication is done with some combination of TCP and UDP. UDP (or rather layers on top of UDP which guarantee packet delivery) are used heavily since the systems are built with parallelism in mind (once again, speed over stability). As such, you should be comfortable with C level socket concepts such as socket(), bind(), poll(), and select(). In all likelihood, you will never use these directly, since these things will have already been abstracted away into socket libraries by the time you arrive on the scene. However, you will be expected to know these concepts, as they are the building blocks of any system you'll be working on.
Threading
Client-server code and threading go hand-in-hand. In fact, you will often encounter this combination in the work you'll be doing. Issues come up dealing with typical TCP server design, load-balanced server design, and high-throughput server design. At the very least, you should be comfortable with the typical academic reasoning: "Fork a process once a request comes in and let it deal with the client, so that the server is free to listen for subsequent requests." You also need to be comfortable with pthreads(), fork(), mutexes (and semaphore concepts in general), as well as higher level things such as Java methods synchronization.
Databases
Note that the topic is Databases, not SQL. Aside from knowing how to do simple select statements, you should have an understanding of the useful properties and limitations of stored procedures, the concepts behind database indexes (clustered and otherwise), and the distinction between table-level, page-level, and row-level locking.
UNIX
UNIX (primarily Solaris and Linux) is still the platform of choice for trading systems. While you will have a Windows machine under your desk, you'll mostly use it for e-mail. Everything from checking log files to debugging core dumps is done in a UNIX environment, and so you really should be comfortable with commands such as tail, sed, grep, awk, tr, and top. It also helps greatly if you are comfortable with either vi, vim or emacs, and have enough experience to not be surprised at the kind of problems that stem from an incorrectly configured $LD_LIBRARY_PATH.
Debugging Skills
I'm not referring to the integrated debugger built into Visual Studio. At this point in your career, you're expected to be able to analyze a core file with dbx, or gdb (from the command line - there won't always be an X-server available). While you won't be spending the majority of your time doing this, when a situation calls for a debugger, it pretty much cannot be addressed with anything else but - so know your stuff.
On a final note, let me ease what I know to be the primary concern of developers looking to make the transition into the financial field. No one expects you to have a deep understanding of the financial markets or specific knowledge of financial instruments. This is domain specific knowledge, and you will attain it almost through osmosis, if not explicit training, as you progress through your career. When applying for subsequent jobs, the interviews will involve financial domain discussions, but at your first interview on Wall Street, if you let it be known that your current experience does not cover topics in the financial arena, no one will hold it against you (assuming that you are not applying for a job where such knowledge is of utmost importance).
Source: http://news.efinancialcareers.com/ADVICE_ITEM/newsItemId-10336