Perhaps you saw that Wired article "Tech Job Interviews are Out of Control"? If not, the very short summary is that now that employers are back in the driver's seat on hiring, they are bringing back long, complex interview processes that make it hard on candidates.

Tech hiring is a deeply complex topic, because each company has different needs for new hires, has a different culture, and operates in totally different environments. There really can be no on-size-fits-all interview process.

This leads to today's topic, which is "there is no such thing as a good programmer". Most myopic and abusive hiring practices are based on the opposite: that there is some general notion of a "good programmer" and that their process will filter out the bad ones.

A Programmer is Part of the System

To borrow from last week's email on synthesizers briefly, you could solder a brand new knob onto a keyboard to repair it, but if it's the wrong type of knob, the keyboard won't work. It might even work worse than without any knob!

The reality is that a programmer is part of a system. That system includes the software they are writing, the other programmers they will work with, the other non-programmers they are working with, the company domain, the business environment, etc.

To think that there is some mythical programmer that can be plopped into any combination of those variables and be successful is just a fantasy. And yet, tech executives engage in it all the time.

Jackie, who can't do l33tcode

Way back, I was part of one of these types of interview loops. The candidate would have a technical phone screen, a take home test, and then an all-day battery of interviews that included behavior and whiteboard sessions.

I was in charge of the whiteboard coding interview, which was a so-called l33tcode test. In my case, we asked the candidate to implement long division, without using division or multiplication directly.

Usually, if a candidate failed this test, they were rejected, and usually, they also failed other parts of the interview. Until I interviewed Jackie (not their name).

Jackie did great on the phone screen and take-home. Jackie got enthusiastic high marks on all the in-person interviews except mine. I'd like to think I conducted a kind whiteboard interview—as kind as these things can be—but Jackie just could not get to any sort of solution in the 45 minute timeslot.

When the interview panel met up after, it was a tough call. This had never happened. We decided to ignore the signal from my interview and hire Jackie. I agreed with this decision, and was curious how Jackie would work out.

Jackie was…amazing. One of the best fits for our team. Jackie understood things quickly, fit into the team, got work done without incident, helped other team members and generally was a great hire. Jackie worked out better than other people who had passed each interview with flying colors.

What gives?

"Good Programmers" Don't Do Long Division

This experience told me that whiteboard interviews, and "programmer purity tests" weren't good at signaling what we wanted in a new team member. At this particular company, I don't think we changed the interview process, but I wasn't keen to use the question any more.

When I was in a position to set up an interview process at a subsequent company, I did not include a question like this. But we did end up with a take-home, and our process was pretty long—just as described in the Wired article.

Our process was designed to avoid any false negative—better let a good fit get rejected than hire the wrong person.

As alluded to in "Code Compactness and Accessibility", I think we could've had a less exclusive process if we had built-in post-hire training to bridge any gaps in technical knowledge.

That would've reduced the number of interviews as well as the requirements of assessments. But it's still not easy.

Hiring is Exclusionary By Nature

Hiring can be extremely hard to get right. You have to balance these factors

• Hire someone who you strongly think will do a good job
• Don't exclude anyone for reasons other than job fitness (i.e. be unbiased and inclusive)
• Have an expedient process that gets to a hire/no-hire quickly, i.e. don't create a zillion hoops for candidates to jump through
• Ensure new hires get up to speed quickly and effectively

A take-home test can give great signal, but it can be exclusionary and extend the interview process. A two-step process with a phone screen and a pairing session can get a hiring decision quickly, but provides way less signal on candidate fitness. Plus, it can exclude people who aren't good at pairing (and if your company doesn't do pairing, why are you pairing in an interview?).

So, I can understand the use of generic purity tests. In theory, any programmer can reverse a linked list in whatever language they understand. But, in practice, and in an interview, this is not true. These purity tests can be passed by memorization or deferring to an AI and thus, are useless.

The United States Pretty Much Prevents a Really Great Method

An extremely good method of interviewing is to pay a candidate a competitive hourly rate to do a real task over a few weeks. You will learn all you need to know by doing this.

Unfortunately, in the United States anyway, this is pretty much impossible. For a candidate to spend a few weeks full time, they obviously can't be working for another company. But that other company provides their health care.

So, the only way to do this as a candidate is to pay for your own healthcare (or be covered by a spouse's plan). The company doing the weeks-long interview can't reasonably provide it. At best, they could cover the cost for the candidate, but this is fraught with administrative complexity on both sides.

This is the system view - effective hiring practices aren't possible due to cultural and legal norms in the United States. Wild.

Navigating Interviewing as a Programmer

To navigate the mess of protracted, purity-test-style interviews as a programmer, you have three options:

• Don't participate in these sorts of interviews. This is the best option, since it will eventually put pressure on companies to stop doing them. But, it requires that you have multiple alternatives and enough in savings to be out of work while you navigate them.
• Play the game and memorize the answers. This is probably the most practical. You can learn and memorize the various l33tcode questions you get and generally play the game to get a job. This is a ton of work, requiring time not everyone has, but it would present you with the most options for employment. In theory, and if you are coming it at a high level, you could improve the process from the inside (though probably not).

• Cheat. This is the option more and more candidates are choosing. They see these purity tests and hoops as pointless and non-indicative of their skill so they do what any good lazy programmer would do: automate the problem away with LLMs or fast Internet searching.

  Lying and dishonesty aren't a great way to start off a business relationship. But given that the most practical option here requires a lot of extracurricular study—requiring time a lot of people just don't have—it's hard to blame someone asking ChatGPT how to reverse a linked list. Honestly, that's how many of you would solve this at a real job!

  The proliferation of LLM-based cheating could actually put a nail in the coffin of these hiring practices. It's extremely hard to screen out cheating, especially with remote interviews, so companies will have to find another way.

Navigating this as a Hiring Manager

If you have agency, here is an approach:

• Write down the minimum skills the person needs to do the job
• Write out the values on your team and company. What general mindsets must someone have to be successful on your team?
• Write out how much of the above you are willing to train a new hire on (vs require them to have on day one).

The gap is what you need to suss out in an interview, and I think you'll find that a more expedient process can do this.

This exercise also reveals flaws in your organization. While a shared culture around common values is a good thing generally, an rigid monoculture is bad for many reasons. As a hiring manager, it makes your job harder, but it also makes your team less effective and more likely to fail.

I don't want to make this sound easy, but as a hiring manager, what could be a higher priority?

Unless otherwise noted, my emails were written entirely by me without any assistance from a generative AI.