So you wanna be a Wall Street techie? Or anyway, get paid a lot
Interviews considered as gang sadism
For at least a couple of decades now, if you’ve been a technologist and wanted to get paid as highly as possible for your work, there’s been pretty much only one place to go: the financial industry.
Have a seat, chum... we'll be in shortly to pick up the questionnaire on the syntax of complicated and rarely used Java functions. By the way, how many piano tuners do you reckon there are in the world?
From a purely tech point of view, there’s now more interesting work going on elsewhere (mobile, robots), so Wall Street no longer has the lock on top technology talent that it once had. But unless you’re lucky enough to be the owner of a start-up that gets acquired by Apple, that doesn’t change the cold monetary facts: The gap between the compensation for programmers at investment banks and those working anywhere else remains massive.
If the reports on technologists’ salaries that appear in the press periodically (and don’t include Wall Street techies, who are considered to be working in “finance”, rather than “technology”) are any indication, the highest salaries in the world of non-finance-related tech are often what a low- to mid-level Wall Street technologist will make.
To be specific, the numbers given in these reports for the most senior people seem to hover around $100,000 (£64,000) — or what someone with a few years’ experience at a reasonably profitable Wall Street firm can earn. For more seasoned programmers at these firms, with years of accumulated knowledge about markets and financial products, “total comp” numbers (base salary + bonus) from $200,000 to $400,000 are not uncommon. Along with this generous compensation come benefits that are almost always better than average: plenty of vacation days, tuition reimbursement, subsidised cafeterias.
For those reasons as well as some less tangible ones — for example, the fact that the builders of high-frequency-trading or derivatives-pricing systems are the awe-inspiring, inscrutable wizards of the moment — there can be a certain, er, superior attitude among Wall Street techies.
The stereotype of the Jaguar-driving, bespoke-suit-wearing finance guy with $800 bedsheets applies more to traders, salespeople, and investment bankers (who can easily take home several times as much as any technologist). But tech people in finance, while not generally hurting for money, will flaunt their position in other ways – not by being conspicuous consumers as much as conspicuous braniacs, several rungs of intelligence above the common herd, as determined by the job "market".
To be fair, there’s generally a collegial, democratic work ethic among tech team members on Wall Street. But getting onto those teams is a different story. The main screening process for these coveted jobs, like most jobs, is the interview. But interviews for Wall Street tech positions can be very different from anywhere else. And when I say "different", I mean more intense, more harrowing, more intimidating, and often (not to put too fine a point on it) more merciless.
You DON'T have what it takes
If you’re interviewing for a position on a team of, say, eight people, there’s a good chance you’ll be interviewed by all eight of them. If the team sits on a trading desk or has frequent interaction with people on the “business side,” you can expect to be interviewed by a few traders as well.
The basic impulse behind the full-team interview is a benign one. Teams like to get consensus on potential candidates, which is sensible enough; there can also be hurt feelings if some team members feel that their opinions don’t count. But for you, the interviewee, what this means is hours of interviews by a large number of people, many of them with big egos and very high self-opinions – people who sometimes see their goal as digging for proof that you don’t have what it takes to be one of their elite team.
I’ve been on more than one set of extremely tough interviews that literally filled a day — 9.30am to 6pm, say. Even half that many hours of intense grilling on technical arcana, with the focus and approach shifting completely every 45 minutes when it’s a new interviewer’s turn, can leave you punch-drunk, exhausted, deflated and eager simply to get the hell out of there.
A certain amount of detailed technical grilling is obviously necessary for a job that involves, say, shaving microseconds off the messaging in a high-frequency market-making system, or building an engine to process millions of trades a day. It’s perfectly reasonable to do an appropriate skills-assessment of someone who will possibly be designing and developing, with little supervision, systems that handle vast sums of money. But the fact is, the number of positions that require memorisation of ultra-low-level details of the operating system, or the precise syntax of complicated and rarely used Java functions, is pretty small. And those are the very kinds of things a tremendous number of interviewers seem to focus on, rather than assessing a candidate’s more general ability to solve problems logically and (most of all) build usable and maintainable systems.
This common approach to tech interviews on Wall Street is to a large extent pointless since, on the job, it’s not unusual or disgraceful to fall back on a reference manual occasionally. Worse, it can be a serious mis-measure of a candidate’s capabilities. Everyone’s heard the old programmer’s cliche that it’s better to teach a person to fish than to give him a fish. In a similar vein, would you rather hire someone who’s merely crammed the contents of 10 manuals into his or head, or someone who can think in a logical way, find answers quickly, and absorb new information easily?
Just how polymorphic are you?
I’ve seen several very real manifestations of this problem. I’ve worked with two people, at two different companies, who could virtually recite the C++ language reference manual from memory, sure to impress almost any interviewer, but resigned after half-finishing the development of major systems. This isn’t necessarily a bad thing in itself, but in both cases what they left behind was so convoluted, overly complex, and incomprehensible to anyone but themselves that the remaining team members, all highly skilled, had no choice but to scrap it completely and start from scratch — months of labour and tens of thousands of dollars (at least) up in smoke. The fact that you know the most arcane details of polymorphism in object-oriented programming languages, or that you're an expert on how to use functors, doesn’t mean you know how to design and build a usable, flexible system that other people can understand and maintain (as they will surely have to do at some point).
I experienced a truly absurd variant of this kind of small-minded “measurability” a few years ago, when a headhunter gave me a long questionnaire to complete and flat-out refused to submit me to any of her clients until I’d done so.
Among the crucial information I had to provide was how many total lines of code I’d written in each of several languages (about as meaningless a statistic as I can think of) and what my score on the SAT (Scholastic Aptitude Test) was. This was in 2008, when I was in my late forties. I took the SAT in 1974, when I was 15. I never filled out the questionnaire or contacted this headhunter again.
But back to interviews: While many people ask decontextualised reference-manual-type questions rather than trying to genuinely assess a candidate’s design skills, flexibility, and general ability to think, there are some whose approach to interviews borders on sadism — approaching the task with the intention of stumping the candidate with the most complex problems they can possibly come up with, or technical questions that virtually no one can be expected to answer from memory.
Sponsored: DevOps and continuous delivery