I think to be successful your team needs to be strong in four key areas:
- Trading (Strategy)
- Software
- IT
- Research
There isn't necessarily one of the four that trumps the rest, and different players have different relative strengths across those four disciplines. (Which are as you would imagine, not terribly specific to HFT)
I imagine the question is developer-focused, so on the software side, I think I value most highly:
- Don't fuck up. This is obvious, and the trading adage of "Don't lose money" is overdone...but essential. Assume you will fuck up and have nets in place to catch you. Doing safeties well isn't sexy and doesn't add any edge, but I've witnessed "unlikely" safeties save trading systems.
- Understand the hardware. Undestand the strategy. You cannot write fast "generic" code. Have a sense for how fast you could optimally be on the hardware and network stack you're using. This requires interfacing with IT and, sometimes, trading, as some "strategies" traders come up with aren't easy to do FAST; you might be able to suggest something similar that is potentially much quicker on the critical path.
- If you really want to compete in low-latency, C++. If you just want to be pretty fast and your strategies aren't competing for specific orders with the other market makers, I don't think it matters. You can probably do a lot of strategies in 100us in any language. GUI can be done in anything, but it should be able to scale. Most of the GUI pieces are pre-existing. Sortable tables for fills. Ladders for displaying markets, etc. I've used Java/C#/C++ GUIs -- C++ has always worked best for me, but I wouldn't be opposed to doing the front-end in JS/HTML honestly.
- Understand the critical path. This and, to some degree, only this, has to be FAST. Obsessing about how to optimally build a theoretical value cache more quickly etc etc is often not that big of a deal. (It's not on the path)
- Linux kernel and TCP/UDP stack DETAILED understanding. (Or verilog I guess...)
- Locks. When does a mutex really need to be locked? Obviously depends on system architecture. And can often dictate architecture.
I think almost anything else I'd say would be either vague or generic. I think there's a lot of niches one can carve out in HFT and, while I personally value generalists who can holistically understand the goal (make $), there's a ton of people doing really well by just being the most badass at X/Y/Z.
A pretty small subset of HFTs are building their own hardware from my perspective; there's a lot of people claiming to be doing awesome stuff on FPGAs.
- Trading (Strategy) - Software - IT - Research
There isn't necessarily one of the four that trumps the rest, and different players have different relative strengths across those four disciplines. (Which are as you would imagine, not terribly specific to HFT)
I imagine the question is developer-focused, so on the software side, I think I value most highly:
- Don't fuck up. This is obvious, and the trading adage of "Don't lose money" is overdone...but essential. Assume you will fuck up and have nets in place to catch you. Doing safeties well isn't sexy and doesn't add any edge, but I've witnessed "unlikely" safeties save trading systems.
- Understand the hardware. Undestand the strategy. You cannot write fast "generic" code. Have a sense for how fast you could optimally be on the hardware and network stack you're using. This requires interfacing with IT and, sometimes, trading, as some "strategies" traders come up with aren't easy to do FAST; you might be able to suggest something similar that is potentially much quicker on the critical path.
- If you really want to compete in low-latency, C++. If you just want to be pretty fast and your strategies aren't competing for specific orders with the other market makers, I don't think it matters. You can probably do a lot of strategies in 100us in any language. GUI can be done in anything, but it should be able to scale. Most of the GUI pieces are pre-existing. Sortable tables for fills. Ladders for displaying markets, etc. I've used Java/C#/C++ GUIs -- C++ has always worked best for me, but I wouldn't be opposed to doing the front-end in JS/HTML honestly.
- Understand the critical path. This and, to some degree, only this, has to be FAST. Obsessing about how to optimally build a theoretical value cache more quickly etc etc is often not that big of a deal. (It's not on the path)
- Linux kernel and TCP/UDP stack DETAILED understanding. (Or verilog I guess...)
- Locks. When does a mutex really need to be locked? Obviously depends on system architecture. And can often dictate architecture.
I think almost anything else I'd say would be either vague or generic. I think there's a lot of niches one can carve out in HFT and, while I personally value generalists who can holistically understand the goal (make $), there's a ton of people doing really well by just being the most badass at X/Y/Z.