[spaghetti]

What's a typical day like for a software engineer working in finance? I've worked in a variety of environments so I know that arrival times, perks, leaving time, meetings etc can all vary a lot. However I've never worked in finance or known anyone that has.

I'm under the impression that algorithms and data structures knowledge is very important. But do software engineers in finance really deal with this on a day-to-day basis?

[BklynJay]

Bottom line: everything about financial software is what Joel Spolsky warned you about. If you want to work on software, go to a software firm. If you want to just pay the bills and are not passionate about software, finance software is..well, read below.

I've worked in finance as a software engineer at several large investment banks for many years. The software consists of a mash-up of legacy stuff incorporated into generally very "safe" architecture choices. Unless you work in some highly specialized (and very rare) type of group, you won't be making any decisions as to what language to use, database, environment or any other project specific choices. They do not value the product. Expect no documentation of anything and consider it a gift if you ever see an internal wiki. While documentation may be the exception in some circles, any developer worth his salt knows the true value of writing stuff down, or at least commenting code, so you can come back to it at a later date. This isn't the type of software environment where they're going to appreciate the years you spent in school, learning how to measure time-complexity of various algorithms. For the most part, those algorithms are already written and those data structures have been decided upon for you. I literally have conceived maybe a handful of algorithms over the years.

You will spend your time maintaining hacked together code that was assembled by literally 30 other people who came and left before you. There will be little to no testing before software is deployed into production. You will likely not have an adequate test environment. If you are lucky enough to have a test environment, chances are that it won't resemble production in any meaningful way. This test environment may be called "your development environment." You will work with many people who do not understand, nor respect, the art of writing good software. You answer to "the business," ie: traders. Traders for the most part, will not appreciate what you do. Its too nebulous for them, and most people not in tech at the IB, for that matter. I'll never forget when we rolled out our new auto-trading system and the IBank laid off several dozen traders that day.

Depending on how your group is organized, you may be on call 24/7. Some groups have coverage structures, with people covering production software in shifts. Expect to be interrupted on holidays. Expect to work on at least one of the following holidays every year: Xmas, New Years, Thanksgiving, Easter, any other national holiday. Projects will be scheduled poorly. Timelines will exceed aggressive-scheduling and wander into "insane" territory. This may be the norm, depending where you work. The quality of the software you write will suffer for it. Your lifestyle, health, social-life, family-life, interests, hobbies and life will all suffer for it as well.

Politics will rule everything. Politics will stifle your productivity, unless you have a great manager who keeps you away from all of it. Unfortunately, I've never met a great software manager in finance. I'm sure they exist, but I've never had one. There will be many meetings. The meetings will run on and on and many topics will be discussed that concern none of you, which could have easily been hashed out in minutes over email. But you will spend hours in meetings because thats the corporate attitude, and finance is as corporate as it gets. The excessive meetings will impact your productivity and result in regular 12-14 hour days, year-round. You'll have far less resources than you require to do the job even adequately, because the people making the decisions about funding view tech as a cost-center. You'll frequently realize, when you read hacker news, that there's a great many exciting things happening in software outside of the world of finance software. You will see none of these exciting things.

I know this seems like a long, negative entry, but I assure you - my experience was not unusual. I strongly caution anyone passionate about software against going into finance software. I've worked as a software engineer and (unusually) in the front-office on the trading side.

[halbermensch]

You'll also be exposed to: near-stupendous degrees of waste, inefficiency, and general head-in-the-sand-i-tude.

Like: signing up for a $140k/year "consulting" gig, but having a secretary pick your sole "workstation", a 12-inch, low-memory Lenovo model normally given to sales people.

Or: going through an grueling process ostensibly designed to assure that you have truly l33t skills in analytic and quantitative thinking skills... only to be herded into a dungeon-like cubicle farm with crass overhead lightin, poor ventilation, non-stop chatter and blaring overhead TVs, making it impossible to think straight for more than 5 seconds... where you end up plugging away for 10-, 12-, 14-hour days.

Or: being hired ostensibly for your senior-level experience in platform X, only to have every decision "vetted" by utterly inexperienced H1-Bs, whose personal coding style reminds you, without irony, of something you last flinched at seeing on The Daily WTF (http://thedailywtf.com/).

Not to mention: not infrequent episodes of not just hot-headness, but outright bullying and borderline psychological violence.

And generally: a stifling atmosphere which makes it basically impossible to have an honest conversation with anyone in upper management about the day-to-day realities of the environment they ostensibly expect you to be delivering this supposedly highly valuable, mission-critical software under.

Granted, this was at "mid-tier" companies, and I (thought) I knew what I was getting into. Still, the reality was far ruder -- and far more weird and just plain absurd, at times-- than any of my worst expectations.

[timrobinson]

I think this is a little too cynical. I've seen elements of what you describe in previous jobs, but never all at the same time, and never to the same extent.

Then again, the culture and the work varies in different cities and in different roles. In London we tend to get excellent developers joining the industry (traditionally there hasn't been much else for good developers locally) so you can typically expect to have skilled colleagues. And the closer you get to the front office, the more money there is for IT projects, and the more remit you have for writing good software.

[michaelochurch]

I think most finance jobs are somewhat better than what he described-- it sounds like he's taken some crappy jobs-- but I don't doubt what he is saying. Code quality issues in finance are well-known and seem to be systemic. Hours are widely variable; there are 9-to-6 IT jobs and there are others that involve more stereotypical (read: awful) finance hours.

I think finance is a great place to work (yes, even as a full-time programmer) if you have a strategic reason for being there (VCs like financial experience, there are some interesting machine learning problems) but I would say that, in general, you're best off if you know you have the social and political skills to get the best work and, if you don't, finance is not likely to treat you well.

[BklynJay]

It's funny you should mention London - our London counterparts always did speak differently of their hours, managers, and opportunity for growth. So I agree with you!

I worked exclusively on front-office systems nearly for the entirety of my time as a developer for an investment bank. I didn't even get into how there are very few opportunities for growth and other, more HR-related/culture aspects of the job.

I'm glad you have good things to say about your work! I just wish I could describe the time that I and my colleagues spent at those banks in a better light. It was utterly life-altering when I left. I felt like I was living for the first time since college.

[Adrock]

This is the exact opposite of my experience working at a very technology-focused hedge fund [1] for the past 5 years.

[1] http://www.twosigma.com

[mickeyp]

Hedge funds tend to be a lot more blue chip and technology-driven than IBs. IBs are usually filled with a lot of legacy crud -- some of it well-written, a lot of it.. not so much -- and a completely different culture as the earlier poster cynically talked about at length. I don't agree with everything he says and it sounds like he's in NYC and not London where things are generally of a higher calibre as Finance generally pays above and beyond what you can get in other industries.

[BklynJay]

Right on - London vs. US is very different. I envied my UK friends who left work at 4pm on Fridays to have a drink with their colleagues, when I'd regularly be working till 8 or 9pm.

[shicky]

I currently work in finance in London and have experienced very different! I was nervous, expecting to be working with MIT gods who would make me feel like an embarrassment of a human being. The reality is I am working with borderline retards from Utah who do no work whatsoever and when I explain in detail, they don't listen one bit. I'm the one left working 50-60hours to cover their lack of work.

[foobarqux]

Can you elaborate on what you like and don't like?

[yen223]

Holy hell, this brings back awful memories of back when I was a software engineer working for a large consulting firm.

The biggest problem with working in non-software companies is that, software engineer salaries are treated as overhead, not investments. This means that they aren't going to spend tons of money to hire the best and brightest talent, they are going to hire the cheapest labour that can get the job "done".

[BklynJay]

I've been out of it for quite a while. It was somewhat unsettling to reflect back upon my experiences. Usually time softens the edges of a harsh experience, and you recall the "good times" far more frequently than the bad. Usually.

[alt_f4]

I work at a top (some might say the top) financial services firm as a Software Engineer. I joined relatively recently, so I still haven't formed a full, well-grounded opinion about the environment and my employer, but I will try to go over the main points concerning your question.

A typical day goes like this:

8.55am I arrive at my desk. Login and start checking email.

9.15am Head off to the cafeteria to buy breakfast (yep, no free food!)

9.20am Eat at my desk whilst reading clicking through my inbox. We get a lot of email. Some people on my team are already on conference calls with Bangalore.

9.40am I open up Eclipse and start working on my assigned project. This goes on till about 6pm. The coding is actually the easiest part. It takes a lot of effort to go through the rest of the process - code reviews, testing (all kinds of testing), UAT, sign off. The PM constantly comes to ask for your ETA (oh, you need to fix this threading issue? How long will that take you? Like an hour?)

12.30-1pm Lunch at my desk. Although sometimes when I have less things to do, I get to go out and spend 45 mins enjoying a burrito.

1pm - The New York team comes in. The 'serious' conference calls and meetings begin. Over the rest of the afternoon, about 2.5 hours are spent on conference calls.

6pm - The contractors leave on the dot. I can leave on the dot, too, but then everybody hates me. It's considered acceptable to stay at least till 6.15pm. Sometimes when I have issues (e.g. I have the fortune of doing production support that they) I might not leave till 8pm.

This is my typical non-support day. A support day is similar, except you have to add a couple of hours of nightmare in the middle.

About the work: Varies team by team. Some teams make iPad apps for bankers. We work on large-scale distributed systems. We have hundreds of processes that exchange and persist information with a few dozen external systems, as well as internal systems to the firm. The biggest challenge is the complexity of the flows and scaling this architecture to peaks.

I'm sad to say, but you will rarely implement fancy algorithms. A good knowledge of messaging protocols, data structures, databases and concurrency is very important though. And the thing that is essential is business knowledge.

So, if you had to make a good old Pros & Cons list, it would go something like this:

Pros: 1) Excellent compensation for the average developer.

2) You get to work with smart and dedicated people.

3) You'll rarely have time to kill.

4) Looks good on your CV, provided you work for a top firm.

5) The work can be interesting, if you're inin distributed systems and architectures.

Cons:

1) Stressful when doing support. A lot of money is on the line.

2) Compensation is very highly correlated with firm performance, which, in turn, is very highly correlated with market performance.

3) You can earn more and work less elsewhere, if you know your stuff. Not really much recognition for "star developers".

4) You'll be using only tried and tested technologies. Good luck getting permission to use any of that RoR you picked up on the weekends.

5) There is A LOT of process.

6) Promotions seem to be based around people's perceptions of you, rather than the quality of your work.

7) Combining (5) and (6) leads to a lot of office politics.

and, finally, (8) If you get unlucky and hired into a shitty team, you're going to have a bad time.

But the best part for me so far is that every once in a while something truly bizarre happens. This makes the rest of my week.

My advice, to survive in that industry as a software engineer, one needs a healthy dose of distrust towards management and a good sense of humor.

[yen223]

I am a software engineer at a rather large factory, handling assembly line robot software. My average day is remarkably similar to yours.

I suspect that any software engineer working in a large company (in terms of # of employees) will have the same routine.

Also my job has all the cons, and none of the pros...

[mickeyp]

I see you're in London; the only way to fly as a developer in Finance not on a profit share or massive front office bonus scheme with the trading desks is to be a contractor.

[michaelochurch]

I had to break it to you, but a lot of these cons apply to 99% of all software jobs, especially promotions being based on perceptions rather than skill or talent, stressful support, and bad luck if you're hired into the wrong team.

Programming is awesome, but 99% of the software industry is a toilet. Finance at least pays for your suffering in cash you can spend rather than lottery tickets.

[pgeorgi]

"Finance at least pays for your suffering in cash you can spend rather than lottery tickets." As do most other non-startup companies.

[dagw]

I think it really depends on which part of 'finance' you end up in. I knew one guy who was 'just' a programmer and worked on maintaining some backend infrastructure code and he had a pretty miserable time. Sure the pay was decent, but it was a thankless job, with a shitty legacy code base, incredibly conservative about trying anything new and he basically had no say about anything.

One the other hand I have friends with degrees in mathematics and serious finance backgrounds whom are working in a more R&D style environment and they have an entirely different situation. They work a lot more with hard algorithmic and math based problems and given more freedom to pick their own tools and define their own work.

[michaelochurch]

You nailed it. The work quality you get if you're in the R&D world you discussed is quite high. It's like being a data scientist at a startup, but with more money and an environment that is less political.

You have to convince people you're more than "just a programmer" to get good work. A quant, a crack low-latency guy, a data scientist, possibly an "architect". By age 30, if you're not some X (as in: "X Who Programs") along with being a good programmer, you start losing.

http://michaelochurch.wordpress.com/2012/08/26/xwp-vs-jap/

[cmccabe]

By age 30, if you're not some X (as in: "X Who Programs") along with being a good programmer, you start losing.

Or, you could work in an industry where software engineers are respected and valued because what they do is part of the core business. If you work at a company whose core business is X and you don't do X, then of course you are going to feel peripheral-- because you are. In computational finance, if you're not a quant, then you're just a member of the support staff and should expect to be treated as such. I fully believe that those firms would contract out this work if they could, but because of confidentiality reasons, they can't.

[michaelochurch]

Right. To be fair to finance, there are a lot of companies (and groups within large institutions) that do value technology. Arbitrageurs, for example, rely on technology. (Financial risk in arbitrage is extremely low; but the danger is that, if your technology sucks, you'll be running at a high burn rate and making few trades.) People are starting to get it, even if it takes a long time.

The across-the-board startups = good / finance = bad mentality makes no sense to me. It may be true in the aggregate, but I haven't seen enough data and what I have seen shows no correlation. If you're in the back office of a huge bank, you're probably not in the best environment for an engineer. On the other hand, high-frequency trading requires a certain technical acumen that's fairly rare and that people will pay a lot for... and if you're really good at that stuff, a lot of the politics works itself out.

I think it's essential to become an XWP ("X Who Programs") even in mainstream software shops. Unless you have a national reputation as a great software engineer, you need some credibility that's independent of your performance as an engineer. Why? Because if the architecture's bad or nonsensical, good engineers won't perform well because they don't think in FactoryFactories and inheritance hierarchies. You need control of the architectural landscape in addition to engineering ability to perform at a 1.5+ level. Otherwise, if you take a typical software job, you're at the risk that you perform at a mediocre level because of architectural decisions made by other (less competent, but more powerful) people and never be able to convince people that you can take the architectural reins. You need that X (data science, project management, quant finance) to convince people that you're substantial regardless of your performance in the particular environment that's given to you.

I am doubling down on data science, machine learning, and statistics right now. (I was a math major in college, and had a couple of 50+ Putnam scores, but I've been away from math for too long and have to review linear algebra to make sense of a grad-level textbook these days.) What I learned in my last startup (where the unambiguously best engineer was demoted and an overpromising mid-20s bullshitter became unofficial VP/Eng, and threw the company into a "rearchitecture" that nearly killed it and ruined the culture) is that architectural issues get political fast. Very fast. Like, tachyon fast. To perform well as an engineer, you need to influence (and, one hopes, to improve) the architectural landscape, and you need some "hook" that is independent of said landscape in order to convince people that you're smart enough to change it as you need.

[cmccabe]

I think it's essential to become an XWP ("X Who Programs") even in mainstream software shops.

Well, it wasn't essential to Linus Torvalds, or Doug Cutting, or Joel Sposky.

If you enjoy data science and machine learning, do data science and machine learning. There's a lot of cool stuff going on in that field. But don't use it as an excuse to look down on people in different fields. There's too much of that going on already (and yes, developers do it sometimes too.)

[dagw]

I can't speak for Doug Cutting, but is my understanding that both Torvalds and Spolsky are XWP for values of X=Really good at managing projects and programmers, and in the case of Spolsky also pretty good at the whole running a business thing.

Certainly in Spolsky's case I don't think he writes much if any code at Fog Creek or Stack Exchange. Torvalds probably still codes a fair amount, but certainly when it comes to Linux most of his value comes from the architecture and management side of things rather than the lines of code he writes.

[michaelochurch]

But don't use it as an excuse to look down on people in different fields.

Oh, I don't look down on "pure" developers (as opposed to XWP) at all. I just think that it's hard to establish a reliable stream of good work on engineering cred alone, because the people who make decisions in most businesses can't tell the real deal from the charlatans in software engineering. The X is the "hook" that gets you enough clout to ensure you get interesting work and continue to get better as an engineer.

[hogu]

There's a big spread, and it depends on which institution and where in the institution you are.

the closer you are to the money (front office vs back) the more money you make, but the more stress you get

the smaller the firm, the more freedom/autonomy, the bigger the firm, the more beauracracy you have to deal with. Imagine working at microsoft vs your own startup.

Other than that, it's not much different than any other technology job