Yes, it's yet another blog about issues with current technical hiring practices and what I'd like to see. First let's define the current Big Corp Hiring pipeline, which many other companies love to copy. Because we all know if we act like Google, we will be Google.

1. Some sort of phone screen. I imagine this is to confirm you have a pulse, at least bothered to read what the company does, filter people with unpleasant voices, filter people with thick accents (which feels like racism to me), filter people who are too awkward, and other asinine reasons that essentially come down to "gut feeling". Frankly, I don't care if you're any of those things (well, you probably need a pulse, but I'm not a zombiest). I only care that you're pleasant to work with and competent. The great part about this is it's a "skill" hardened interviewers love to say they've "mastered" and they "just know" after a brief conversation with someone. Shockingly enough, these people never seem to self reflect on their accuracy saying "it's too hard to measure". It would actually be fairly easy to measure based on how many people who pass the phone screen ultimately fail the pipeline, or who are hired yet don't perform well, and/or checking where the candidates they didn't let through end up. Measuring would likely reveal fairly poor accuracy and systemic bias, so we'll skip that.

2. A leet code question. This is to verify the person in question can "actually code". Programmers love to think most other programmers can't actually code and are dumb gorillas. What it's really testing is how well you can code while under extreme pressure, and that's actually very hard to do. It may also be under the guise of "seeing how the candidates think" or "how they explain themselves". Truthfully, I don't care how candidates think, I care about their solution. They should be able to explain their solution, but I could care less if the way they got there is a lesser demon whispering in their ear. Humans are bad at explaining how they discovered a solution to a problem, and when they try to explain, they're likely not explaining how they really solved the problem. What's likely happening is their leet code muscle memory kicked in, and now they have to ad-hoc rationalize some made up explanation. Another thing interviewers love to do is poorly define the problem to make sure you can "gather requirements". If you're not privy to this common haze, of course you're an idiot and a no hire.

3. Repeat step two a few times. This is to "gather signal". Really, it's to weed out the smart developers who may have had good enough intuition to solve a few leet code questions without grinding them a few hours every night. You don't want developers like that, you want developers who will shut up and do the leet code.

4. A culture fit round! Yep, like the phone screen we can filter out awkward people or people who are the wrong color or gender. A culture fit round gives us a free pass to do this after they've already proven themselves to be technically competent. I don't know about you, but I cannot tell if someone is a "culture fit" or pleasant to work with after a short lunch. Many studies have already shown humans are notoriously bad at judging someone based on first impressions.

tl;dr Hiring software devs is like choosing math professors based on how good they were at Math Olympiad. Clearly there's some correlation, but you'd be throwing away a lot of good professors.

Where do we go from here? Here are some options.

1. Have a public repo and a board of open cases candidates can do. Pay them for their work if you do accept their PR. Give them code review and see how they respond. If you like the work they do, hire them fulltime. This is essentially lightweight contracting. It's representative of their actual skill. The bastardized version of this are 2 to 3 hour long unpaid "take homes" which are then thrown directly into the trash are incredibly disrespectful to the candidates.

2. Let the candidate put forth their own work. Let them put forth whatever they want. Ask questions and take context into mind. Clearly a small personal project might not have an entire suite of tests and complicated CI/CD pipeline. Have the candidate do some code review on your own project.

3. Solve a problem together. Yep, solve a problem that you haven't perfectly rehearsed. As a smug interviewer looking to clap down candidates, this is incredibly scary, but representative of how working with a coworker actually is. When you and your coworker collaborate on a real problem, no one knows the answer before hand, you figure it out together. Let them lead, but work together as if this was your real coworker.

It deeply saddens me that the current hiring process is the best we've come up with and we need to do better.