7 ms·

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

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?

hogu 14y ago
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
BklynJay 14y ago
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.
- Adrock 14y ago
  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 http://www.twosigma.com
  - mickeyp 14y ago
    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 14y ago
      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 14y ago
        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 14y ago
    Can you elaborate on what you like and don't like?
- timrobinson 14y ago
  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.
alt_f4 14y ago
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.
dagw 14y ago
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 14y ago
  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/ http://michaelochurch.wordpress.com/2012/08/26/xwp-vs-jap/
  - cmccabe 14y ago
    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 14y ago
      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.

hogu 14y ago

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

BklynJay 14y ago

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.

Adrock 14y ago
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 http://www.twosigma.com
- mickeyp 14y ago
  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 14y ago
    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 14y ago
      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 14y ago
  Can you elaborate on what you like and don't like?
timrobinson 14y ago
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.

alt_f4 14y ago

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.

dagw 14y ago

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 14y ago
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/ http://michaelochurch.wordpress.com/2012/08/26/xwp-vs-jap/
- cmccabe 14y ago
  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 14y ago
    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.