Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Why are employees in technical roles in financial services discounted?
26 points by treyfitty on Aug 24, 2022 | hide | past | favorite | 46 comments
Received feedback from interview at GitHub: “culturally bad fit- person is a developer at a bank. Not a real developer.” This isn’t the first time I got similar comments, and it appears to be a pattern among technology companies. Why does this attitude exist?



At least he gave you something you could work to improve. Try not to have so much banking experience in your past in the future.

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.


And folks wonder why companies don’t give out feedback after interviews. Not a good look for GitHub.


Was this really from a github interview?? They sent this to you?

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.


Banking has a reputation for hiring developers who wear ties and got the job by proving that they could spell "Python."

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.


Whoever is doing this has no idea of the SLA and (at least aim for) five-nines culture banking expects, and the process oversight necessary to maintain a financial licence or pass the PCI tests.

Not that banking s/w is perfect, but to imply "not a real developer" because was in Fintech, bank side, is stupid.


> at least aim for

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."


FWIW I've worked in global top50 bank on a non-critical team (nothing we did affected real bank balances or transactions) and nothing of the sort you're describing was happening there. The rules were followed, even if they were extremely painful for developers. In fact, they were main of the reasons people left the bank - they just wanted to go someplace where their hands aren't tied as much. So, I guess there are good banks and bad banks.


I once worked in a "regulated" industry where the product was "certified" by a third party before going live with the customer. It handled money, but was outside of banking (picture something like sports betting.) The third party had access to the code, but didn't look at it or try to build it. They purely ran manual QA, black box-type tests, then gave it their stamp of approval.

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.


But thats all implicitly a risk in almost any large deep-time sw house. They said it all with "bad fit" -Banking isn't "why" they're a bad fit, its a niche.


Having worked in bank IT, it's possible to have shockingly bad practices and still exist.


Having family who worked behind the scenes in Bank IT and colleagues who worked in Bank IT, I totally agree.


That's possible in any industry.


But you wouldn't really want a developer from most of those either.


Bank Python


I received that same response a few times in the past year. There are a couple of reasons for it:

* 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.


> 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.


Feedback on your interviewer:

- 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


I would go as far as firing the interviewer this is extremely unprofessional. The company decided to interview this person based on their resume.


Yes. The worst interview experience is when you go through the whole loop and then get rejected based on information that was already on the resume.

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.


heh, the whole "Interviews go both ways" trope has never been more real.

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.


This is a huge embarrassment for GitHub.

Yikes.


Having worked at banking and then faang. The problem is how oblivious I found some banking people! Especially people who joined straight out of university. They think they’re doing amazing work while never looking outside. The stuff in banking was antiquated and the rules were Downright hinderances to doing dev work. So unless you keep up with how things work outside it’s hard to assimilate with normal sane companies.


They intentionally sent you feedback that said you're not a real developer?


Sheesh. Seems like somebody tried to implement a feedback system for candidates (an admirable goal), but somewhere in the pipeline it did NOT translate to the interviewing developers.

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.


Or the author intended it for HR to read with the implicit critique "don't send me trash" (from their perspective of course, saying nothing about OP)


People in profit centers have been looking down on cost centers forever.


That is ridiculous for them to send you such unprofessional feedback.

On the opposite end, I interviewed at a bank once, and ended the interview because the job sounded so bad!


The feedback certainly does not apply to fintech companies. They employ some of the smartest devs I've ever met.


That’s like saying:

“Works for Microsoft. Not a real developer.”


Many many years ago I gave recruiter instructions. If resume mentions Notepad trash it. There were way to many developers that wrote software in notepad.


What if the resume was written in Notepad in txt format?


If it was a screenshot of a notepad window, maybe.


It's not specific to banking per-se and more specific to legacy companies with low engineering skill and bad practices, which are perpetuated because skilled people either don't bother applying or are unable to make changes for the better (whether due to red tape or politics) and then end up leaving them in their mess, so over time the only thing that remains there are those who can't make it anywhere else.


i mean most people who live outside major metros don't have much option except to take positions at these banks before covid hit and remote happened.


I think you just hit bad luck because that hiring manager sounds like an idiot. I work for one of the largest American banks and like any other big company (like Github!) we have very competent people and less competent people as well - in terms of my PERSONAL estimation of competency, anyway.

Silver lining is it's good luck that you won't have to work with that team!


While the interviewer is giving terrible, imho lazy feedback, I think what they mean is they give off an impression that the candidate potentially lacks the sanitized form of “hustle” agility potentially due to enterprise-level mindsets that welcome conceiving contrived company processes as work output..?


wow....just wow and sorry. I spent nearly 4 years at a bank and made some amazing stuff...that is so short sighted


That's weird. If they already had someone in mind for the position I can see them using this phrasing to cover themselves though, especially if you absolutely rocked the interview. Similar things happen all the time.


Sounds like this person got their job at the company through nepotistic means, because no one of merit would ever think that way. I feel they're a liability to github.


I have an ex-colleague who worked at an Australian bank in America (do the math!). They still had Python 2.6 scripts. This is circa 2019.


I see nothing wrong with this. The fact that it is in "old" python just means that it has done its job for a long time, presumably without needing to be rewritten. I would love it if someone came into my workplace in 15 years and found a script I wrote today still being used.


Bank. Unsupported runtime. Extremely likely to not be secure.


It’s possibly a misunderstanding of the different environments or they have had bad experiences from previous hires.


https://news.ycombinator.com/item?id=30197940

Sorry but no email in profile - still know about Django opportunities? I'm looking for moving into freelancing, maybe..


This is an interesting thread

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


One of the teams I oversee works exclusively with FS. Here's the gist from my POV.

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.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: