> We all sit on the trading floor.

Ouch. How do your engineers ever get anything done?

Having worked in quant finance myself, this is now my litmus test. There is absolutely no good reason why researchers and programmers need to be physically co-located in a loud, crowded trading floor, especially given modern workplace chat programs and convenient issue tracking tools. Any organization that says programmers or quant researchers need to sit in the trading floor so that you can absorb information, learn the tradecraft osmotically, or whatever, is blowing smoke. It's business-speak for "our company is mired in legacy tech, bureaucracy, and outdated standards." Such jobs have to pay above market rates, bonuses, and give disproportionate raises each year, because it's the only way people who are thoroughly burnt out from the sisyphean task of overcoming the noise to focus constantly will bother coming to work. For better or worse it seems that the only people interested in staying in these jobs for long only do it for the money -- there is a huge culture of self-selling and an extreme willingness to bottomlessly compromise on tech culture standards, almost like a proud martyr. If you join the firm as a technologist with actual skill and some common sense opinions about software culture and best practices, you just get chewed up by the politics and nothing changes.

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.

Two comments:

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.

I don't dispute the existence of such places. My claim is that it is extremely rare, and in the majority of firms the lack of technology culture is not only not seen as a problem but is enshrined in macho pride and insistence that the lack of technology culture is indicative of some difficult constraints that finance poses from a first principles point of view, constraints which weenie technology culturalists can't stomach.