Ask HN: Why are employees in technical roles in financial services discounted?

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.<p>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&#x27;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&#x27;re working from. You think &quot;it&#x27;s a signal we need every signal we can get cuz hiring is so hard&quot; - no sympathy here, I&#x27;ve long, long been of the mind that companies actually fuck the hiring process over by obsessing so insanely over the dreaded false positive.<p>If you like the other candidate&#x27;s background better, then go ahead and hire the other candidate because you think they&#x27;re a better fit! Hire whoever you think best! But don&#x27;t fucking tell the first person that it&#x27;s because they worked at a bank! You can&#x27;t ask the bank person the same filtering questions you ask everyone else? You didn&#x27;t ask them to describe what they did there? YOU DIDN&#x27;T SKIM THEIR RESUME BEFORE YOU WASTED THEIR TIME AND INSULTED THEM FOR THEIR TROUBLE? Jesus at least if you&#x27;re a bigoted snob don&#x27;t fucking announce that fact to the candidates so they can go tell Hacker News.

Was this really from a github interview?? They sent this to you?<p>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&#x27;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 &quot;Python.&quot;<p>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.<p>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 &quot;outlier&quot; 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.<p>Having worked for a bank, I would not hire someone who had spent a very long time there.<p>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.<p>Not that banking s&#x2F;w is perfect, but to imply &quot;not a real developer&quot; because was in Fintech, bank side, is stupid.

I received that same response a few times in the past year. There are a couple of reasons for it:<p>* 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.<p>* Financial services industry moves slow. A frozen mammoth runs faster. That means no panic mode of indecision. Some software companies will expect you to <i>pivot on a dime</i>, or rather compensate for their planning&#x2F;architecture failure elsewhere.<p>* 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.<p>—-<p>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.<p>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.<p>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.<p>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.

Feedback on your interviewer:<p>- Can&#x27;t or won&#x27;t assess individual skills<p>- Relies on low-signal stereotypes to form opinion<p>- Doesn&#x27;t add hiring signal in an interview loop<p>- Recommend removal from hiring process<p>- Return will require comprehensive retraining

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&#x27;re not a real developer?

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

That is ridiculous for them to send you such unprofessional feedback.<p>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&#x27;ve ever met.

That’s like saying:<p>“Works for Microsoft. Not a real developer.”

It&#x27;s not specific to <i>banking</i> per-se and more specific to legacy companies with low engineering skill and bad practices, which are perpetuated because skilled people either don&#x27;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&#x27;t make it anywhere else.

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.<p>Silver lining is it&#x27;s good luck that you won&#x27;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&#x27;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&#x27;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.

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

This is an interesting thread<p>TL;DR:<p>My primary goal in writing this is to connect with the audience of hiring managers who receive applications from candidates at banks<p>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.<p>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.<p>The rest of the post is mostly a pyramid-style case-build in a wall-of-text making this case.<p>Net point I want to make is that there is no one global characterization of developer capabilities for folks in a large FI &#x2F; 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.<p>Long Version<p>I want to offer evidence: from fact but somewhat anecdotal because the one 1 bank I know lots about != all banks ...<p>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 <i>most</i> FIs as much as possible. Please bear with my generalizations for those reasons<p>I am &#x27;developer&#x27; 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&#x2F;dev leadership role<p>First some context:<p>Banks, especially the big ones, are actually so big that they cannot be characterized as <i>one company</i> from both management and tech perspective.<p>It is better to think of them as a conglomerate of independent companies.<p>The org structure actually reflects this: you will find leaders who are responsible for everything, including P&amp;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.<p>Look at HSBC here for example and note how many leaders there are with CEO titles <a href="https:&#x2F;&#x2F;www.hsbc.com&#x2F;who-we-are&#x2F;leadership-and-governance&#x2F;senior-management" rel="nofollow">https:&#x2F;&#x2F;www.hsbc.com&#x2F;who-we-are&#x2F;leadership-and-governance&#x2F;se...</a><p>**<p>Most relevant for this thread - this operating structure means tech decisions are made independently, for each internally group, at the P&amp;L business unit level, not at top of house.<p>Saying this a different way - there are no bank-wide decisions for production tech choices. There are only <i>P&amp;L group</i>-level tech decisions. Full responsibility for P&amp;L means full responsibility for choosing where and what to spend tech money, among all other monies, on.<p>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.<p>**<p>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<p>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<p>With the the context above, the net of things is that, depending on where you are in the org, you could be in:<p>- a part of the financial institution that behaves like a startup, with startup incentives, management and results<p>(examples could be digital only banking, innovation groups etc etc)<p>- a part of the financial institution that behaves like how banks are traditionally characterized<p>(examples could be core banking platforms and systems dev., relationship banking groups eg private or commercial banking )<p>- a part of the FI that is stuck doing development work based on tech decisions being made elsewhere<p>(examples could be integration teams, reporting team etc etc)<p>- 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!!<p>( examples could be mission critical production user facing or batch green screen COBOL&#x2F;FORTRAN environments on mainframe - this is where the real big $s are, with FANG-type pay for folks with platform and environment specific experience )<p>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 &#x2F; sending it on to another set of tools.<p>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.<p>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&#x2F; skills and needs&#x2F;capability. The key driver, as with any other business is return on investment<p>Examples of the spectrum include:<p>- 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<p>- access DBs to manage some proceed or fill some need with zero return ( eg compliance doc tracking) run by a gal&#x2F;guy with zero programming&#x2F;dev training<p>- completely home-grown self serve platforms with security &amp; 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&#x27;s the gist from my POV.<p>It&#x27;s hard to get fired from the bank. This leads to a downward spiral. Good developers are pushed out because they don&#x27;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.<p>&quot;We&#x27;re all going to pretend this work is really complex and takes forever to do.&quot;<p>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.