So You Want To Be A Wall Street Programmer?

<>

February 2006

So You Want To Be A Wall Street Programmer?

By Andrey Butov

The financial industry is a big playing field. As domains go, the type of specific work varies greatly, and what is applicable to me may not be applicable to you. So 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 being 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, you are still welcome to the advice presented here, but your mileage may vary. So what is 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 API’s 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. With that being said, there is 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 Wall Street trading systems are by definition 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, but 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 will 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 email. Everything from checking log files to debugging core dumps is done in a UNIX environment, and as such, 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 am not referring to the integrated debugger built into Visual Studio. At this point in your career, you are 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). Welcome to the trenches…I look forward to working with you. Andrey Butov works in New York City as a Software Developer in the Fixed Income division of an International Investment Bank.