"... no remote workers. We all sit on the trading floor."
Having worked in quant finance, 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, bullpen, or cubicle bank, 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 one 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, award 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 daily noise to focus will even 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, 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. As a result, the steady-state of most of these organizations is a state in which all of the transient signals from good engineers and culturally progressive technologists have been beaten down to noise, either because such folks only last a short while before quitting, or else because they ultimately decide keeping their heads down and collecting the paycheck is better than fighting endless culture battles.
Another red flag is a requirement that a programmer is "comfortable in any language" (what the hell does that even mean?) or possibly a false promise that "you can use whatever language you want." It speaks of bespoke reinventions of wheels all over; no modular, tested central library of common tools. I once interviewed for a firm that highlighted my interest in Haskell. They said one of the perks of the job would be that I am personally in charge of maintaining my own software tools for rapid prototyping and so if I wanted to write it in Haskell I would be free to do so. At first blush this sounds interesting -- being paid well to write and learn Haskell! But on closer inspection, it's total poison. Wait until you're forced to port some of your nifty Haskell constructs into R or Java and interoperate with some legacy system. Then you'll badly wish there had been enforced standards from the beginning, even if said standards had removed your so-called freedom to homebrew all of your own Haskell gadgets in the first place. This is the kind of dubious ploy that is attractive to inexperienced programmers who haven't lived through a shitstorm of work surrounding migration and integration headaches. Progressive technology culture isn't about draconian, bureaucratic standards (the things that led us to enterprise Java) but it also isn't about having zero standards and zero foresight into the modularity of the larger system
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 retail data exploration. You are those caricatures of scientists and engineers that you cynically mock in Michael Bay movies butchering tech jargon while they show the joint chiefs a monitor full of gibberish that will save us from the Russian alien robots. 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. Documentation? Who has time? There was a standard library module that already did everything you just spent 4 hours re-inventing? Too bad there was no time to research a rational approach to the system's design. Someone needs to reproduce a result you calculated 6 months ago? Good luck, buddy: here's my 5000 lines of undocumented R code.
The kicker is that 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 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, instead of underemploying them as data secretaries. 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 20-year-old legacy C++ and legacy Java, allowing traders and economic domain experts infinite freedom to pick their computing tools (and letting them push the needless headache of integration 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 being left on the table by not doing things in a fundamentally better way. If a thing is good, it doesn't mean it's better.
Sadly there are all sorts of political and market inefficiencies in the industry. Clients don't do a good enough job of holding investment managers accountable for returns, research, or technological best practices. When large institutional clients are involved, the deals made between them and the respective investment managers are often borne out of bizarre political alliances, nepotism, internal career politics, and so on. Firms spend inordinate amounts of money constructing marketing apparatuses to spin every market outcome as though it either could not possibly have been avoided or else proves the investment acumen of the firm, and institutional clients sadly buy it.
It's sad to say but the most likely way for this nonsense to be fixed is outsourcing. Cloud computing frameworks will be created that present simple interfaces to the domain experts, and the start-ups that create such interfaces will be separate and free to employ whatever technological best practices they see fit. Simply by shifting the burden of the problem outside of the stodgy, politically dysfunctional finance firm, it can suddenly be solved. It could easily imply significant layoffs for this sort of commoditized retail data analyst role. It reminds of the Max Planck quote: "Science progresses one funeral at a time."