Lots of monocultures exist in hiring even without an algorithmic scoring system. That's roughly how every stupid hiring fad works, and how it's always worked, because most employers have no idea how to identify great potential employees.
Hiring managers and companies choose algorithms and hiring fads because they don't know how to be really certain of who to hire, so they'll settle for either assuming someone else's expertise will save them, or for some rubric that "everyone is doing" so it "can't be that bad".
When I first became a hiring manager, I was working for a public university. Our salaries were limited, being staff rather than faculty and being public servants, to between 1/3 and 1/2 the going salary for equivalent cybersecurity professionals in the private sector. I did not have the option to hire the people everyone else was trying to hire. I also faced one of the key risks of working in a public institution: once you keep someone past their probationary period, it is very, very hard to fire them. So, it's important not to get it wrong. I learned some things that I have carried forward into every hiring manager or senior leadership role since:
1. I base hiring practices on Manager Tools behavioral interviewing systems (https://manager-tools.com). No affiliation, they've just made my work life better.
2. I became really good at understanding what my team or organization really needs. Most hirers focus way too much on "years of experience" and specific technologies than is usually wise. As my favorite former supervisor said, "I can teach a smart person cybersecurity, but I can't teach a dumb [or unmotivated] cybersecurity person to be smart."
3. I became really good at developing people, and ensuring that the managers under me were as well. We couldn't lay someone off just because their technical specialty became irrelevant, so we couldn't afford to hire people who weren't lifelong learners, or to fail as coaches to ensure that learning was always taking place.
4. I cast as wide a net as my HR and regulatory overlords would let me (and now, as a business leader, I cast a huge net). I look for things that aren't just useful at the moment, but are useful long term, in my candidates. I don't care about pedigree.
I end up paying less for good employees due to simple supply and demand: I often go for the diamonds in the rough that don't have 10 competing offers.
I end up having really good employees who generally stay with me long term, because I apply long-term thinking in hiring, and structure my teams around constant learning and development.
I dodge a LOT of bullets... people who have just the right pedigree to look like great hires worth a lot of money, but who'll disappoint me until the day they leave.
When it's a tight labor market -- too few candidates for roles I care about -- I'm tapping a hiring market that other managers aren't aware enough of, and still finding talent while they have roles that sit open for months.
I began my career as a software engineer, eventually moving up to architect before going to cybersecurity full-time, going from Senior Analyst to Chief Analyst to Deputy Director, followed by the sorts of executive roles I'm now in. There's a lot that my younger self didn't understand about office politics, and needed to know, so I'll try to help the rest of you be wiser than I once was.
*What office politics is and isn't:*
There are lots of definitions of "office politics". Younger-me thought that it meant a situation where those in power let ego and cliques get in the way of getting things done. While this can happen, it's not what office politics really is. Some of the engineers who have worked for me now once believed that office politics was "all the stuff that doesn't matter, like emails, meetings, conferences, and holiday parties"...I don't think most still believe this, as I try to be a good teacher.
An experienced SWE knows that technical work at any scale requires an infrastructure. If your ticket tracker, revision control system, test suite, and automation are not up to snuff, the code produced in that system is going to have serious problems. As a matter of fact, I've seen projects collapse under their own technical debt because they didn't take good care of that sort of infrastructure, and couldn't see the technical debt accumulating in their code base as a result.
It turns out that any organization, including those producing code, has a bunch of non-technical infrastructure, too: money and systems for managing it, relationships, decision-making systems, people-development systems, communication systems, legal and policy systems, marketing and sales, ethics and culture... if any of these is screwed up or neglected enough, it can derail the life of software engineers just as badly as a revision control system that lies to you, or a test suite that never throws an error. Office politics is a catch-all term for how these non-technical systems are operated and maintained: sometimes well, sometimes poorly.
*How much should office politics matter to a software engineer?*
Junior and mid-career ICs (individual contributors, aka people who don't manage anybody else) can safely ignore a lot of office politics. You'll need to grow into more should you start moving up toward a technical leadership role (e.g. architect, incident response lead, project manager) or a people leadership role (e.g. team lead, manager), but you can start with just these three things early in your SWE career:
1. Become a good communicator. Your commit messages, answers to tickets, documentation, and code comments are all part of the job of coding. If you have the right idea, but can't explain it well enough for your architect or team lead to buy in, that is your failure. Good engineering communication is dense and succinct, clear and precise, absolutely correct in spelling and grammar, and has solid reasoning that takes into account all the facts that matter, but none of the ones that don't. Don't be a catastrophist or a Pollyanna, especially around clients/customers. Not everyone will meet this standard, but if you do--or at least if you constantly work your way closer--you'll be a better programmer than technical skill alone can make you.
2. Build strong relationships. This doesn't mean being the life of the party, and it's not about charisma. It's about showing up (including to the office Christmas party), learning people's names, being cordial and professional (not the person who got drunk at the office Christmas party), being clear and direct (no passive-aggressive behavior), being trustworthy (no lying, no gossip, don't cheat, do more than the minimum), being reliable (keep your word, under-promise and over-deliver, manage your time well), never blame others for your shortcomings, and don't be the workplace grump. Learn what other people are dealing with so you can be a better colleague.
3. Take responsibility for your own growth. It's not your organization's job to build your career, but many junior SWEs expect it. Go to conferences. Read books. Take trainings. Read news relevant to your job and the industry you are in. Share what you learn with your team. Start giving talks and trainings. Build a professional network so that you can learn from others. Find a mentor if you can.
Beyond that, you can focus on learning and improving at the technical and self-management parts of the job.
*A bit about my experience:*
At age 20, I was a junior SWE. I cared about technology quality, not what the customer wanted or my boss believed. I think the leadership at my first SWE job only put up with me because I was cheap and I solved puzzles here and there in elegant ways they hadn't thought of. Despite flaming out of college, I had a chip on my shoulder based on years of FOSS development.
Life intervened. I had to take about 18 months off to be a stay-at-home mom, and then divorced suddenly. To get on my feet financially, I ended up starting my own company and freelancing. It gave me a new appreciation for everything that makes a tech job possible. Eventually, my little company grew, and I started getting more interesting gigs. One was with a pair of investors who wanted to use me to turn around SaaS companies they'd invested in, but which were failing. The investors had a finance background, not a tech one, so in my mid-20s I was their go-to for a cheap last ditch to save these investments by putting the right technologist in the mix.
I learned the hard way that technical problems of a certain magnitude are usually people problems wearing a hat. Bad hiring, personnel turnover, failures of communication and relationship building, lack of delegation, problems making and sticking to decisions, broken or ill-defined company culture, perverse incentives...the list goes on. Getting tech debt under control, fixing bad architecture decisions, and getting code delivered at a decent quality meant sorting out those people factors in the process. Some of the cybersecurity crises were especially interesting to me, so that's where my career went next.
It took the best boss I'd ever had six months to convince me to become a manager. I wanted to stay an engineer forever. However, after watching three incidents where engineering teams suffered due to bad management, I gave in. Office politics here I come...except, it wasn't as bad as I'd imagined. It turns out that if you have enough spine to be honest with people, and enough responsibility to be a bit proactive, and are willing to accept that management is a whole new career you have to learn, it's not that hard to do it well.
My manager introduced me to Manager Tools ( https://manager-tools.com -- no affiliation, just an extremely satisfied user), which was immensely helpful. Their advice is actionable, not pie-in-the-sky, and it doesn't include the kind of BS advice that leaves you feeling like you're trapped in Game of Thrones. I've been to several of their events and built an amazing network. Today, I'm leading one cybersecurity start-up as Managing Director, and I have another project still in stealth.
I've seen the good politics and the bad. Less of the bad politics was due to some sort of evil villain actor than most people imagine. Most is due to learned helplessness, poor decision-making skills, people being set up for failure, or being in the wrong job, or simply being untrained and believing the BS they read on LinkedIN (and yes, sometimes HN). Having the right mentor(s) makes a huge difference in how well you can take advantage of the good and fix, shield against, or leave the bad. I can't write something that will tell you how to deal with every possible situation you could run into. Building relationships with folks further ahead on the road than yourself gives you the opportunity to tap their experience when it's needed, for the situation you are actually in, rather than worrying about vague and sweeping statements about the importance of politics.
Hiring managers and companies choose algorithms and hiring fads because they don't know how to be really certain of who to hire, so they'll settle for either assuming someone else's expertise will save them, or for some rubric that "everyone is doing" so it "can't be that bad".
When I first became a hiring manager, I was working for a public university. Our salaries were limited, being staff rather than faculty and being public servants, to between 1/3 and 1/2 the going salary for equivalent cybersecurity professionals in the private sector. I did not have the option to hire the people everyone else was trying to hire. I also faced one of the key risks of working in a public institution: once you keep someone past their probationary period, it is very, very hard to fire them. So, it's important not to get it wrong. I learned some things that I have carried forward into every hiring manager or senior leadership role since:
1. I base hiring practices on Manager Tools behavioral interviewing systems (https://manager-tools.com). No affiliation, they've just made my work life better.
2. I became really good at understanding what my team or organization really needs. Most hirers focus way too much on "years of experience" and specific technologies than is usually wise. As my favorite former supervisor said, "I can teach a smart person cybersecurity, but I can't teach a dumb [or unmotivated] cybersecurity person to be smart."
3. I became really good at developing people, and ensuring that the managers under me were as well. We couldn't lay someone off just because their technical specialty became irrelevant, so we couldn't afford to hire people who weren't lifelong learners, or to fail as coaches to ensure that learning was always taking place.
4. I cast as wide a net as my HR and regulatory overlords would let me (and now, as a business leader, I cast a huge net). I look for things that aren't just useful at the moment, but are useful long term, in my candidates. I don't care about pedigree.
I end up paying less for good employees due to simple supply and demand: I often go for the diamonds in the rough that don't have 10 competing offers.
I end up having really good employees who generally stay with me long term, because I apply long-term thinking in hiring, and structure my teams around constant learning and development.
I dodge a LOT of bullets... people who have just the right pedigree to look like great hires worth a lot of money, but who'll disappoint me until the day they leave.
When it's a tight labor market -- too few candidates for roles I care about -- I'm tapping a hiring market that other managers aren't aware enough of, and still finding talent while they have roles that sit open for months.