There's an old saying: "Don't ever take a fence down until you know the reason it was put up."
The phrase "hiring is broken" comes up dozens of times in HN searches. If something appears broken to you, but persists for a long time, it's time to start considering that the apparently broken thing actually serves a purpose you can't see to someone you don't know.
Hiring is not broken, there's simply wayyyyy too many candidates for any opened position, so companies get to be extremely picky and reject 100 people to fill one position.
And to be clear I'm not talking about having too many unqualified candidates who can't do a hello world (there's some but don't pass a screening test), I am talking about an oversupply of candidates of all levels who are able to pass the marathon of interview questions and exercises.
That might be true in some areas but... in almost every company I've been, it's been ridiculously hard to find enough qualified applicants for a given role. There wouldn't even have been 100 people to reject. I think programming is still mostly an employee's market.
The 100 applicants are down to 10 people for an onsite, 2 or 3 get an offer, 1 is accepting it.
Sometimes when I look back at the last few people I interviewed onsite, I'm pretty sure they could all have done the job just fine. It's crazy that they're all getting rejected, there is nothing wrong with them, the company is overly picky for no reason.
Digging down there's probably 1 who got an offer and rejected it. Companies always forget to mention that half of their offers are rejected, hiring would be easier if they improved on that.
Same. Pretty much every candidate we interview is more than capable of doing the job technically. Overwhelmingly, why my team picks one person for the job and reject the others is for non-technical/behavioral reasons.
Then again my company is a boring investment bank, not a hot tech company. Top quality candidates are not in a rush to trample each other to join us. 90% of the candidates we get would not be able to brute force naively solve an leetcode medium or even a harder leetcode easy, let alone come up with an optimal solution. We would never be able to hire anyone if we rejected everyone that wasn't able to code an optimal solution in 40 minutes.
Yet if hired, I have no doubt nearly all of them would be able to do the actual job more than well enough - and that has been the case with everyone that I've interviewed and gave the thumbs up to.
It's also true that it can be ridiculously hard to get a company to respond to an application, and to get an interview.
Assuming the job requirements aren't unnecessarily restrictive, there is something in the screening process that is actively harming both applicants and hiring managers.
I'm not saying that the process is perfect, and I do think that it can be difficult to get a particular job you want, but - at least where I live - it's ridiculously easy to get a job as a dev, even if it's one you're not excited about. This is a vast improvement over many other professions where people are stuck within their roles for a long time because they would struggle to find employment elsewhere.
On the other hand, hiring gets discussed endlessly on HN and there doesn't seem to be a compelling reason presented for the status quo.
At some point you have to accept that the fence maybe doesn't serve a purpose, or its purpose may be forgotten and not applicable, and its worth the risk to take it down and see what happens.
>On the other hand, hiring gets discussed endlessly on HN and there doesn't seem to be a compelling reason presented for the status quo
Disagree. After reading and participating in the endless HN hiring discussions, I'd say I've come to an understanding of why, at least in SF, interviews are done the way they are.
It seems to be a lowest-common-denominator approach that serves candidates and companies in different ways.
For the candidate, they can do one set of study (leetcode/system design) and that effort is applicable at a wide range of companies.
For the company, they are finding the intersection of people who are at least intelligent enough to grok CS fundamentals (I know it's just pattern matching after you've studied it), and willing to jump through enough hoops.
Hiring works a very different way outside FAANG leetcode style interviews. It's mostly a chat between a couple devs about what you've worked on in the past and how applicable that experience is and trying to get a sense of where you're at in your career and if you seem like you'd be good to work with. It's a lot less standardized, so it can be very hit and miss sometimes as sometimes you get quizzed on knowledge of their particular stack. Often the study you do for one company isn't necessarily translatable to another.
Just remember that taking down the fence is easy but not enough. You also need to find something else to do the job. Which often turns out to be very hard.
There is a long history of dysfunctional processes being replaced with other processes that often turn out to be as dysfunctional as the previous one. Just in a different way. See Scrum and Agile as examples.
The compelling reason is the massive success of FAANG companies. How are they making unimaginable amounts of money if their engineers are from "broken hiring"? How is FAANG on a resume such a strong signal if it just means they got through a broken system?
Aline has said some good stuff but she loses me at: "There’s no substitute for chemistry, in dating or in hiring."
Hiring is not fucking dating. You are not having sex with your coworkers, you are not discriminating on gender, race, body type as everyone regularly does in dating. Dating is not a healthy system that you should aspire to in employment. It's very much broken in comparison with swipe apps and the like, just broken in different ways.
> The compelling reason is the massive success of FAANG companies. How are they making unimaginable amounts of money if their engineers are from "broken hiring"?
Two possible expanations:
- What works for a big company of FAANG type is not necessarily a good idea for other companies.
- Because the FAANG companies have found a formula for printing money, they can afford such a hugely broken hiring process.
> If something appears broken to you, but persists for a long time, it's time to start considering that the apparently broken thing actually serves a purpose you can't see to someone you don't know.
What does this even imply? That someone benefits from this broken system? The recruiting firms? It is indeed broken as engineers are not happy with going through the middleman gauntlet, companies are short on developers and would ideally want to hire asap. The only problem I see for companies here is find the right candidates (filter the bad candidates) but all these obstacles don't seem to be doing that at all. So back to the drawing board...
It implies that the things that people complain about in interviews may serve a non-obvious purpose. For example, giving hard algorithm problems may not be to test whether you are a good programmer, but to test whether you are invested enough in landing the job to study for the interview.
This kind of logic can be used to rationalize anything and does not satisfy first principles thinking. Processes and tests should serve obvious purposes, otherwise there is no metric for measuring their effectiveness.
An example of this is coming up with "how many golf balls can you fit in a bus?" riddles, in the vain attempt at "seeing how the person thinks"/"problem solving"/"creativity".
I'm not trying to defend it (and as a hiring manager I don't do it) - I'm just explaining the implication of Chesterton's Fence as applied to interviews. "Processes and tests should serve obvious purposes" seems very wrong to me, though - they should certainly serve useful purposes, and those purposes should be documented, but there is no real reason they need to be obvious to a layperson. Google specifically dropped those riddles because they did not find them effective, which means they have some metric for testing efficacy. They have not dropped algorithmic challenges, though. I wonder why?
That's just a way to reduce the number of applicants if you don't care about getting the goods hires because bad hires can game the interview just as much as good hires.
I'm skeptical of this claim - I believe bad programmers could study for years and still not be able to fake their way through an algorithmic interview administered by a competent programmer, and lazy programmers are probably not going to put in the effort to game it. I agree it will reduce the number of applicants though.
The fence is there because the risk of doing something new is hard, especially because testing hypotheses in hiring is expensive.
I am a hiring manager. I've also put significant thought into how we can change the hiring process, if only to get better candidates. However, it comes down to this: I only get 2-3 hires a quarter. Trying to get a meaningful result on changes I make is difficult. If one doesn't work out, did it not work out in a way that my original process would fix?
And so, we get conservative because even though it rejects a lot of qualified candidates, it also gets good candidates.
There are 20 more that you could have named. What is their temperament? What kind of initiative do they have? Are they collaborative or more independent? How do they collaborate between teams and is that something you need? Do you need someone that can go in front of a customer?
So, do you customize your hiring process for each hire? What if multiple teams need different types of people? How big is your organization?
And if you get a discrimination claim, can you prove you have a fair process? The bigger the company, the more standard the process generally is.
My interviews aren’t heavy algorithm interviews, unless I need it. However, those questions you mention and many others are hard to analyze. How do you test that someone is an expert, especially if you don’t have an expert on staff? How do you know if the person writes maintainable code or just talks a good game?
That gets to the difference between a generalist and a specialist. Sometimes, I need to hire a specialist because we need someone who can provide high level expertise to a group of generalists. (E.g. a specialist on visual design and interactions with javascript, react, and best practices regarding such.) If we are looking to hire for that skill, trivia isn't going to work but neither do we want to hire someone who can talk a good game but would be quickly exposed by an expert, and will lead us down the wrong path.
Now, I can give you all sorts of answers here. My point is that unless you're going to put a lot of effort into redesigning the interview process from first principles for your company due to some need (like Google), or you are putting your effort into a startup like interviewing.io, you're likely going to take an existing process and tweak it. And that explains why the fence is there.
As one very junior in my career, this comment was really eye opening for me. I am feel a lot of the frustration and stress of the 'broken' hiring process, but was quite comforted by the introspection your comment caused.
> a nice person vs a person that will fight for "doing the right thing" (e.g. is possibly strongly opinionated)
Maybe it's just a matter of wording, but the implication that people who will go to bat for an important choice can't also be "nice" strikes me as strange and contradicts my experience. Good comment otherwise though.
If you conceptualize a hire as "this decision costs me $100k to $200k, and six months", you'll understand why folks are conservative. That's my finger in the wind cost of a bad hire, in terms of their salary, the salary and opportunity cost of their first two weeks buddy, plus all the other related efforts to onboard and train. Plus, again, if it's a bad hire, by the time we spend 2 months getting to the termination, and a 2 month search, and a 2 month onboarding, I wait 1/2 a year before I get the employee I need.
>The fence is there because the risk of doing something new is hard
This is the exact wrong lesson to take from the proverb. Instead of considering why something is still in place, you should consider why it was put in place to start with.
Coding tests came about because some developers can talk a good game but are very poor at software development, and it can take months to realize in more complex code bases. Algorithm tests came about because when interviewing CS majors, you can assume they have had an algorithm class. Many of us know why the fence was put up. We don’t tear it down because it is a complex problem. It just takes one successful company to create a better process and the fences will start coming down, just as whiteboarding has become much less prevelent in the last decade as laptops have become common for developers.
You're adding a value judgment to the comment you're replying to that wasn't there.
> serves a purpose you can't see to someone you don't know.
Does not mean "good, but you're too stupid to see it."
edit: after one figures out why something is a certain way one could come to the conclusion that it must be changed immediately, and the reason it was that way was more destructive than one could have imagined.
Or alternatively it's a hard problem, in a domain where nailing down a good solution may be non-obvious, or perhaps even really defining the problem domain is not yet done.
When I think about how I'd like my work to have a big, positive impact on the world, one of the first things that comes to mind is fixing hiring/job hunting. I'm moderately intelligent and have felt this way for a couple decades, and I still haven't done anything about it because I still don't know how to make it not suck, and I've yet to see anyone else working on a good solution either.
I've seen a lot of very smart, capable, and talented people have trouble finding a decent job, and eventually settle for underemployment for a good while. A system that could properly utilize their productivity would be vastly superior to our current system. There's a lot of money on the table for anyone who implements that system.
I don't know what that system looks like. I just know with certainty that there's a massive amount of wasted productivity under our current system.
What I can tell you is that when I graduated college, the way you found a job was to use Monster.com--a big job search engine--apply to various openings in a tedious process, and interview. Today, you use Indeed.com--a big job search engine--apply to various openings in approximately the same tedious process, and then interview in approximately the same way.
There's money on the table for anyone who can improve the system, and no one has. This tells me it's hard. (The fact that I don't know how to improve it a bonus.)
> There's money on the table for anyone who can improve the system, and no one has. This tells me it's hard.
In other comments on this article, I wrote my arguments why I don't believe that detecting good candidates is hard (I wrote suggestions there).
I believe the hard problem is rather that most companies/recruiters don't actually know (or won't say) what skills they are really looking for, so they use dubious processes to rationalize why they chose a specific candidate.
> Although these approaches are rational under existing constraints, they’re neither particularly efficient nor particularly fair to the individuals subject to them. This doesn’t mean that we can’t improve the system … But before we talk about what we have the power to change, let’s dive a bit deeper into the constraints we face today.
“it's time to start considering that the apparently broken thing actually serves a purpose you can't see to someone you don't know.”
That sounds a little like conspiracy theory. My theory is that hiring is just really hard and it’s difficult to do that at scale.
I know people who are really good at interviewing. I think I myself can interview reasonably for people who have to work with me. But that takes a lot of time and energy. So “specialists” from HR take over. But they don’t understand the real requirements for the job so they have to come up with a lot standardized indirect measures which don’t work well.
> hiring is just really hard and it’s difficult to do that at scale
Yes, talking to people about their previous work and employment history is a good way to judge their fit for a position. It also takes about half a working day of 2-3 people each time to do it properly.
Like Soylent Green, a software company is people. If you have hiring authority and you don't think it's worth your time to spend half a day a couple of times a week to get the right people into your organization, you have the wrong job.
I can confirm that putting in this time is imperative to getting the right people hired.
But if you require that any engineer involved should spend a quarter to half of their week on hiring, and that you yourself consider anyone with less commitment unsuitable, don't you agree that scalability becomes a problem?
How many half-recruiters, half-engineers do you think are available, compared to the overall need for engineers with hiring authority? I don't have data on the former, but it's apparent to me that, if you hire people to do this full-time instead, you're hiring a recruiter. That's what gets you exactly the system everybody seems to complain about.
I think that phrase is a thought terminating cliche. How can one argue with the claim that every construct has a valuable hidden purpose despite evidence to the contrary?
I don't think the claim is "every construct has a valuable hidden purpose". It's "if you can't explain all the important purposes of a construct, you aren't ready to take it down."
I remind myself of Chesterton's Fence every time I encounter some WTF code.
The phrase "hiring is broken" comes up dozens of times in HN searches. If something appears broken to you, but persists for a long time, it's time to start considering that the apparently broken thing actually serves a purpose you can't see to someone you don't know.