Banks are where tech careers go to die. Expect to be caught in a myriad of "initiatives" that are all fluff. Remember, if you're not making the bank money, you're costing them money.
I live in NYC so many of my friends and colleagues have had tech jobs in the well known banks. Here are some of the data points I've collected.
Person 1 says there is a lot of politics, ass-covering, and throwing under the bus
Persons 2 and 3 says back in the 80s and 90s there were a lot of exciting projects, but now it's all maintenance work and making sure money train does not stop.
Person 4 says at his company they tracked how much money your bugs cost the firm, and at the end of the year if that number is too high, you're fired.
Person 5 corroborates what Person 4 said, adding that no one is allowed to touch production -- you touch production and you might cause an outage in some part of the company you never heard of, next thing that happens is Security shows up at your desk with cardboard boxes telling you to pack your stuff.
Person 6 says for the same reasons no one is allowed to touch the base classes you inherit from -- people just make their own copy of the base class and make their changes to it. The code base is littered with many copies of the same file each different in its own way.
Person 7 flat out told me "you are too nice, you will get eaten alive at a financial services firm"
Person 8 says he was not allowed to talk to or collaborate with a colleague because they worked for competing managers, they had to leave the office to collaborate
> Person 4 says at his company they tracked how much money your bugs cost the firm, and at the end of the year if that number is too high, you're fired.
As someone who almost never ships a bug but is a bit slower because of that, I would love it ;)
Anecdotally, 80-90% of my bugs are business logic “errors” that came about because either 1) the client didn’t tell us about the special edge case that is now happening, or 2) the person who wrote the requirements didn’t capture the business logic quite right (usually the reason is because of #1, but not always).
Very few of my tickets are directly from programming mistakes, but I do own up to them when they happen.
Want one? I'm not OP, but I hope this is enjoyable.
Ok... I was hired as a DevOps expert by a bank. They had this "user friendly" click-click platform nobody was actually using for automation. I mean, they were trying, but there's a reason modern stuff is Configuration as Code.
I wanted to use Jenkins and a bunch of Python scripts.
The local "tech expert" shot that down, told me that Jenkins was for "builds". I was like, ok, in that case let's use something else to trigger the launch of the scripts. While that was in the pipeline, I started working on the Python scripts.
I worked a bit on them, got them working form my workstation. Then during the "review", I was asked which version they were. I said, Python 3. Nope, the servers only have Python 2. Ok, I'll make them backwards compatible. Finished that, then I was told that we can't run unapproved Python scripts (!!!).
At that point I figured, you know what, what if I write just some local automation to cut down on my tedium, and maybe I share the scripts with the team later on.
I asked what I could use for sure, and they told me: whatever I had pre-installed on the workstation.
So I wrote a bunch Powershell scripts that controlled the IO of plink.exe (SSH client bundled with PuTTY) to send shell commands to servers. I basically reinvented a dumb version of Python fabric...
And I programmed that using Vim bundled with Git Bash, because that was the only decent "simple" editor that I had access to (actual devs were only using company sanctioned Java IDEs with limited plugins allowed, i.e. Eclipse).
My scripts ran well, but when it came around to sharing them with the team, I was basically told that it would be more prudent to keep my head down and let people do what they'd always been doing (i.e. deploying manually...).
To be fair you could have gathered the requirements and proposed your solution, wait for the approvals and then start the coding work instead of working on the solution.
I did try all of that, was basically told no, use the official solution, and meanwhile deploy hundreds of applications manually on Linux servers, using shell commands.
And for the official solution, I kid you not, they had me fill in a huge Excel spreadsheet, print it, have my manager sign it, then attach the PDF scan to another Excel I was supposed to email.
And that was for a review by the architects team. One step out of tens of super similar steps (including the print and scan part).
I presented my project as a small, "skunkworks project", to try to get approval on the side of the main solution, to have some automation so I wouldn't go crazy.
If they were better organized and frankly less political, I would have tried to help them more. But at every step the impression was that they didn't want me there, I was a troublemaker...
I know quite a few people making insane amounts of money working at banks. Sure it’s not glamorous, but their careers are doing just fine. I would agree it’s not a great place for fresh grads and extremely junior developers. Way too easy to pick up the bad habits and negative aspects of the industry.
I’m increasingly convinced banking IT is one of the trades of software. There are glitzier gigs. But you’ll need connections or student debt to land them, and their net ROI won’t be as high ten years out.
On the other hand, your HN peers won’t look down on your cereal-bowl ad-targeting (granted, fabulously compensated) gig at Google.
>I’m increasingly convinced banking IT is one of the trades of software.
Banks an Insurance have just really bad marketing, but fraud-detection (aka ML.."AI"), analytics..it's all really interesting, and if you have a good manager who shields you from the internal-wannabe-politicians you can produce software that you can be really proud of (enough time to test/plan etc).
And hell, Mainframes are such a interesting field no one talks about (but one could learn some really good lessons).
As a former bulge bracket investment bank software developer, I certainly did not make anywhere close to insane amounts of money. As a "vice president" 10+yoe senior SWE equivalent my TC was probably a tad bit higher than the higher end of a FAANG junior SWE TC. This is in NYC. Ditto for my colleagues.
The only kind of SWE I can see making great money at a bank are those working in the algo trading and maybe the quant space, but those are highly niche roles.
In my city there's a few service centres for banks, and the interview process for engineers seems to be "can you spell Python?". I'm sure there are good people there, but there's so many bad people, that having the name of a bank on your CV is often seen as a negative.
On the other hand I know someone who is a DBA. A few years ago she decided to switch to a bank, and the work-life balance is much better than any other company she has worked for. This year they let her work remotely from another EU country for 3 months.
If the skill level there is so low it's an opportunity to exceed their very low standard and still finish the workday in a couple hours and then enjoy the rest of the time or use it to work elsewhere/build a side-project/etc. Seems like an amazing deal to me.
You can do that, yes, but it’s surprisingly tricky and stressful to manage.
Bear in mind that most of the people there won’t actually realise that they’re low skill level. In fact, they probably think they’re high skill level because they’re working in a bank and banks are elite, right? That is a toxic combination.
So actually you spend much of your time fending off requests to change your work in stupid ways or making futile attempts to avoid the codebase turning into spaghetti code.
It’s not the case that you can just turn in two hours’ code and everyone’s happy with your day’s achievement.
It is exhausting to have to argue the case for every minimal piece of good software design (eg validating inputs, designing minimal interfaces, avoiding god classes).
Eventually you give up and/or they think you’re stupid because you find their spaghetti code hard to understand. The app becomes increasingly slow, hard to maintain and full of weird bugs. Everyone wonders how this could have happened and the rewrite begins.
> In fact, they probably think they’re high skill level because they’re working in a bank and banks are elite, right?
Over last two years I had to work with few people who worked in banking as C# developers, they all had 8-12 years of experience and they wrote worst, most outdated, unreadable and untestable spaghetti code I've ever seen. First week on the job I've added StyleCop to all our projects because I just couldn't stand people being unable to press one shortcut to format their own code(or install an extension to do that for them). This way it wasn't me pointing out ugly code, it was the pipeline, 'pls fix'.
Obviously there are people and people, but so far I've only noticed that developers who worked in banking institutions usually have a lot of experience in that one or two particular companies and they barely can do anything of value on their own.
I did a small stint at a mid tier bank and this is exactly how it went. You try to advocate for better methods and you constantly hit inertia and a deep institutional belief in years of service.
"You use git? Interesting but our director (15 YOE) says it's a waste of time. Do you claim you know more than him? You've only just started here!"
In the end you could easily do the assigned work in 10h a week except you are hobbled by bad practices, poor infrastructure, cheap leadership (you want an IDE? our division didn't approve the expense) and so so much Legacy code.
"It is exhausting to have to argue the case for every minimal piece of good software design"
So don't do that. It's rarely worth it. I'm happy to bill $150 an hour while a couple of colleagues argue vehemently about directory structures on S3.
If you care that much about every minimal aspect of software design, then you need your own personal project. Landing on a team that all have the same good sense about software development with the ability to express that is just pure luck.
You're right, that's the way to look at it. If you can be transactional, it's ok and maybe you can get away with a 10hr week.
But it's still tiring to see code being merged and thinking "that's going to make X, Y and Z harder for me to do". Or being asked/told to make bad changes. Or being the one who has to do the emergency fix for the non-null assertions causing runtime exceptions in prod (which you had flagged in review and been told "the compiler is wrong, we know they can't be null").
Also expect hostility between teams. Everyone is competing against each other for their fluff to be noticed. Everyone is just looking to get promoted without caring if they're actually delivering anything useful. It just has to have the appearance of bringing value.
Apologies, but this is one of the first times I’ve heard that certain industries in tech are better or worse then others. Is there a place to read up more about this?
That seems naive? All sorts of industries have nice side/nasty side, and it's often very dependent on both which company and which job title and even which individual manager you get. This is why Glassdoor is a thing.
At the end of the day it's all anecdote, but the plural of anecdote can be opinion even if it's not data.
The cost center heuristic is good: is the work you're doing an important part of a product being sold? If not, you're just a cost like office cleaning, and will be treated and paid accordingly.
Apart from banking (process-driven, often boring, can be well paid) the other big stereotypes are consultancy ("body shop": cheap and nasty; higher end consultancy can be hugely lucrative but very political) and games (almost uniformly appalling, only work for a games company if you really want to be able to tell your friends you do so)
