Ouch. How do your engineers ever get anything done?
Ouch. How do your engineers ever get anything done?
Another red flag is the whole "comfortable in any language" and "you can use whatever language you want" sort of thing. It speaks of bespoke reinventions of wheels all over, no modular, tested central library of common tools. Basically, these jobs make you sit physically tethered to a trader or portfolio manager, beholden to that person's real-time whim about what needs to be computed. It's literally like retail data exploration. You don't have time to blink, you just type! If it means hacking something in an ungodly amalgamation of Excel, C++, Python, and R, and slapping some duct tape on it so the trader can use it before lunch time, then by god that's what you must do. And there is such a macho attitude of "this is just how finance is" that the company is usually proud that it's like this, instead of recognizing that it's the very definition of developer hell, and, more importantly, it is totally not at all required or implied as a domain constraint of finance. Instead of allowing traders to have beholden computation assistants, you could just actually force traders to know how to do real programming. Or, you could actually trust data scientists, statisticians, and other inference domain experts who can program to also develop trading strategies. You can organize teams around common tools, common analysis motifs, etc., and build with re-use, modularity, and QA in mind, so that writing best-practices compliant, tested software is not incompatible with meeting intense intra-day deadlines.
I wouldn't feel so much resentment of this sort of thing if it weren't for the macho pride, the attitude that "this is just how finance is" -- crappy hacks, zero unit tests, slinging Excel sheets around with zero data provenance, hacking everything onto 25-year-old legacy C++, allowing traders infinite freedom to pick their computing tools (and letting them push the needless headache of integrating them all onto someone else). It's something the industry should be ashamed of and should be working exceptionally hard to change. But it's not even admitted as a problem -- it's lauded as if it's heroic. We don't need your wimpy best practices here, we just roll up our sleeves and do whatever it takes to make the system work. It's almost by definition a culture of mediocrity since the only definition of success is whether the system as-is is making money -- very little thought is given to the counterfactual money they are leaving on the table by not doing things in a fundamentally better way. If a thing is good, it doesn't mean it's better.
Note: I was inspired to riff on this issue of crowded trading floors in these jobs, but I'm speaking about the problem in general. I have no special knowledge about this specific job or whether or to what extent these issues manifest themselves just based on the post above. The trading-floor-because-it's-how-you-learn thing is a dealbreaker for me personally, but it doesn't mean it should be for anyone else.
1) First, while I know nothing about OP's firm, there are hedge funds where the programmers are in charge. Such shops tend to have sane technology stacks, sensible working hours, and pleasant (if intense) research environments.
2) Compensation for the quants at the funds I'm thinking tends to be quite high. The quants make the key decisions and they know recipe for the secret sauce, so they get the bonuses and the partnership slots. The risk-reward profile at such funds is a heck of a lot better than the typical flameout startup.