Seriously though, I participated in many an interview loop as interviewer at FAANG and elsewhere. This is unprofessional, tactless, ignorant, and elitist to the point of delusion. This interviewer needs a talking to at the least. So do some of the people in this thread. I don't give a shit if you worked at a bank yourself and it was bad. Way to pull that ladder up behind you. I think you should meditate on personal bias and the sample size you're working from. You think "it's a signal we need every signal we can get cuz hiring is so hard" - no sympathy here, I've long, long been of the mind that companies actually fuck the hiring process over by obsessing so insanely over the dreaded false positive.
If you like the other candidate's background better, then go ahead and hire the other candidate because you think they're a better fit! Hire whoever you think best! But don't fucking tell the first person that it's because they worked at a bank! You can't ask the bank person the same filtering questions you ask everyone else? You didn't ask them to describe what they did there? YOU DIDN'T SKIM THEIR RESUME BEFORE YOU WASTED THEIR TIME AND INSULTED THEM FOR THEIR TROUBLE? Jesus at least if you're a bigoted snob don't fucking announce that fact to the candidates so they can go tell Hacker News.
Sorry I just am trying to imagine an interviewer saying this to a candidate, let alone thinking it in the first place. Terrible attitude on their part. I can see why someone might not make the same assumption of a developer at an old financial services company (i.e. that is still lagging behind tech adoption) because it might mean using older tech or something, but to imply you aren't a real developer is crazy.
I interned as a developer at a bank. We lied about security and development practices to auditors. We had some PCI compliance stuff to do and they turned on a bunch of features and created a change request form for a day for audit purposes. We pointed a develop server at production for several hours, allowing anyone to login to accounts. We turned off our tests rather than fix Jenkins.
A friend is currently with a bank you have heard of. He is not quite a developer, but on a team that does dev work. They have standards for reliability and productivity. He fakes them. He gets to toss any bad data as a "outlier" and sends the rest up to management for its rubber stamp. He is upfront about it in the way that bankers are (a pile of weasel words), but realizes that VPs are Banks are not technical.
Having worked for a bank, I would not hire someone who had spent a very long time there.
I would expect to be getting someone who viewed the solution to security issues as releasing a memo proclaiming there are no security issues or just bleating about best practices. As that is what we did.
Not that banking s/w is perfect, but to imply "not a real developer" because was in Fintech, bank side, is stupid.
I am a former bank dev. The "aim for" is where the argument really falls off the wagon. It would be one thing if banks actually achieved anywhere near that. They don't.
Banking tends to aspire to that in its memos and docs, but falls utterly short and when it falls short, it doesn't look introspectively, but rather just edits the documents and data or changes definitions or slowly lets the initiative die by having people shuffle roles.
PCI? One of the things that was supposedly for PCI was proof of controls on code, i.e. that someone had reviewed the code and someone approved the release and who those people were. PCI Requirement 6.3.2.
Sometimes we theoretically had the controls, i.e. approval by another dev was required to merge code. But plenty of times, they turned them off due to the ticket burden. Even when controls existed, the approval would come seconds after the PR was created. There was no review.
In the docs, only our lead could send something to prod. In practice, anyone could. There was no management oversight or approval really required and nobody was monitoring it.
Also, we once sent the dev site to prod. There was no significant segregation between development and prod environments. It was considered too much work. This is also a violation of PCI requirements.
Banks theoretically work to strict standards. At least at the one I was with (someone tried to buy it for 30 billion or so), massaging whatever we had to meet the standards was how things worked. We didn't rise to the standard. We didn't change how we did things. We edited, weasel worded, and frankly, probably lied our way to meeting them.
A friend is currently with a bank you have heard of. He is not quite a developer, but on a team that does dev work. They have standards for reliability and productivity. He fakes them. He gets to toss any bad data as a "outlier" and sends the rest up to management for its rubber stamp. He is upfront about it in the way that bankers are (a pile of weasel words), but realizes that VPs are Banks are not technical. Called the supposed procedures they follow a "load of horseshit they are never going to check."
This was in the old days, years before git or GitHub. There were no code reviews. There was maybe 5 unit tests in the whole code base, and they were run manually.
As developers, we had full production / root access with essentially zero oversight. I had a VPN into this stuff from my house. If I screwed something up bad enough, we probably would've received a visit from a Tony Soprano-like character, so that was probably enough of an incentive to keep things working.
* Banks are extremely well regulated for obvious reasons. Software is not regulated at all to the point of extreme immaturity and gross negligence. Nobody in software even wants to talk it.
* Financial services industry moves slow. A frozen mammoth runs faster. That means no panic mode of indecision. Some software companies will expect you to pivot on a dime, or rather compensate for their planning/architecture failure elsewhere.
* Some companies want you to play with a 1000 different tools and live in trend bullshit. You likely aren’t doing that at a bank. Configuration hell isn’t really programming so consider that as a missed loss.
—-
I learned a lot from interviewing at more than 2 dozen places. Software is incredibly immature. The lower the barrier to entry the more immature and discriminatory it becomes.
Keep in mind developers talk a lot of bullshit during interviews. Everybody claims to want high performance, but almost nobody measures performance in any regard. I dropped out of a Facebook interview over this stupidity.
Everybody claims to want simplicity. When you can prove or talk through extreme simplicity most developers find it abhorrent. Instead they want familiarity and any deviation is met with disgust or arrogance.
I also learned that I had a lot of free time at a bank in which I could learn to become a much better developer. Strangely, almost nobody in interviews wanted to talk about actual engineering of software. It made me realize I’m old and software is a game for young people looking to make big money in a job where expectations are extremely low.
You can play this game at any age. When you're older, you just don't have any delusions about what it is exactly that you're participating in.
- Can't or won't assess individual skills
- Relies on low-signal stereotypes to form opinion
- Doesn't add hiring signal in an interview loop
- Recommend removal from hiring process
- Return will require comprehensive retraining
The company has no confidence in its own interview process. The interview is just for show. They actually hire you based on whether you've been at Stanford or FAANG or something.
I konw a lot of fintech companies have pretty awful tech stacks, and antiquated practices. So those would be valid criticisms of a candidate, if relevant to the job. But honestly if someone is able to be productive in the toxic, bloated, ancient fintech environment I think that might impress me even more than excelling at a traditional tech company.
Yikes.
Though, thinking about it more... I can't imagine ever saying that about someone even on an internal-only private feedback form. It's not even substantive -- it's basically an ad hominem attack on OP! As crappy as that feedback is, I guess they kind of dodged a bullet by not joining that team. Seems like a toxic team, org, or company if that kind of shit flies.
On the opposite end, I interviewed at a bank once, and ended the interview because the job sounded so bad!
“Works for Microsoft. Not a real developer.”
Silver lining is it's good luck that you won't have to work with that team!
Sorry but no email in profile - still know about Django opportunities? I'm looking for moving into freelancing, maybe..
TL;DR:
My primary goal in writing this is to connect with the audience of hiring managers who receive applications from candidates at banks
My goal is to convince you that 1 bit of info - that a resume is from a candidate at a bank - is not enough information to make viable assessments about the quality of the candidate. There is more info hidden behind that bit if you dig.
This additional info is based on the position that large FIs are so big that you cannot characterize developers working in them in any generic way.
The rest of the post is mostly a pyramid-style case-build in a wall-of-text making this case.
Net point I want to make is that there is no one global characterization of developer capabilities for folks in a large FI / bank that holds true to any extent. You have to know more by understanding where in the bank they worked, the technical environment they were in and what type of work they did.
Long Version
I want to offer evidence: from fact but somewhat anecdotal because the one 1 bank I know lots about != all banks ...
Warning - this is a long post and is a bit all over the place because I wrote it fast to get it out before the post gets too old. I also tried to be as generic as possible in my arguments so that they align with most FIs as much as possible. Please bear with my generalizations for those reasons
I am 'developer' who has worked in FANG, government, startups, healthcare, big-4 type consulting and other roles: currently at a 50k+ person bank in a hands-on tech/dev leadership role
First some context:
Banks, especially the big ones, are actually so big that they cannot be characterized as one company from both management and tech perspective.
It is better to think of them as a conglomerate of independent companies.
The org structure actually reflects this: you will find leaders who are responsible for everything, including P&L, for an entire group of say 1k-5k people (out of a total 100k employees) 1, 2 or even 3 levels down the overall org chain. These leaders will will have a title that, literally, says CEO of $X Business at $Y Bank. They are actually running fully independent business under the larger FI umbrella.
Look at HSBC here for example and note how many leaders there are with CEO titles https://www.hsbc.com/who-we-are/leadership-and-governance/se...
**
Most relevant for this thread - this operating structure means tech decisions are made independently, for each internally group, at the P&L business unit level, not at top of house.
Saying this a different way - there are no bank-wide decisions for production tech choices. There are only P&L group-level tech decisions. Full responsibility for P&L means full responsibility for choosing where and what to spend tech money, among all other monies, on.
The only top of house decisions would be around integration, data exposure and reporting tools. Never ever ever banking process production and production-support systems.
**
A by product of this is that moving orgs within the bank is literally like moving companies. You go to a new office, have new colleagues, with a different culture, working with different tools, on an entirely different tech stack
You might also likely, as a tech person, never interact with group you were in before. Different HR, legal and tech support folks, different leaders, different colleagues, literally like starting at a new company
With the the context above, the net of things is that, depending on where you are in the org, you could be in:
- a part of the financial institution that behaves like a startup, with startup incentives, management and results
(examples could be digital only banking, innovation groups etc etc)
- a part of the financial institution that behaves like how banks are traditionally characterized
(examples could be core banking platforms and systems dev., relationship banking groups eg private or commercial banking )
- a part of the FI that is stuck doing development work based on tech decisions being made elsewhere
(examples could be integration teams, reporting team etc etc)
- a part of the FI that is mission critical and everyone is loath to change - think platforms that NO ONE wants to touch because they JUST WORK and have been working forever and would cost the earth to touch!!
( examples could be mission critical production user facing or batch green screen COBOL/FORTRAN environments on mainframe - this is where the real big $s are, with FANG-type pay for folks with platform and environment specific experience )
I have also found that there are no internal prod tools that run across the org. All tools that are org-global are, by definition, reporting, aggregation or integration tools - taking info from some combo of tools and displaying it / sending it on to another set of tools.
This is the reason why $bn products and companies selling message buses platforms and green screen scrapers exist (TIBCO et. al) and make billions of dollars a year - these companies provide tools and products to connect independent systems (and thus businesses ) in the environment I described above, at scale.
I have worked on maybe 3 of the 4 environments I have described above at the bank where I am now and have found that the spectrum of skills, experience and tools across these orgs runs the entire spectrum of software dev. experience/ skills and needs/capability. The key driver, as with any other business is return on investment
Examples of the spectrum include:
- true, in production, internally built ML platforms for scoring stuff in real time (think card transactions flagging) that are probably close to best in class, that save hundreds of millions in losses annually run by true data scientist Phds
- access DBs to manage some proceed or fill some need with zero return ( eg compliance doc tracking) run by a gal/guy with zero programming/dev training
- completely home-grown self serve platforms with security & data segmentation built in serving groups with 3k+ individual users (which is a lot for a in-house corp tool ) run by the type of small scrappy team you would find at a typical startup
It's hard to get fired from the bank. This leads to a downward spiral. Good developers are pushed out because they don't want to do the work of people who hide for a living. The hiders create a game with management that makes their job easier.
"We're all going to pretend this work is really complex and takes forever to do."
The longer you play this game, the less exposure you get to real challenges and skill growth. The cycle causes change in banking systems to be the slowest of any industry. This causes banks to be more than a decade behind everything else. This causes FS devs to be unable to catch up to modern best practices.