Puzzles as a Service

Table of Contents

An image of my fursona (a blue and white anthro husky with a pink nose and green eyes) dressed up fancily and staring to the left with great concern. To the left is a Hangman game with five spaces, three of which are already filled in: Blank I R blank D. Underneath are letters already tried: H, O, P, M, T. All the letters are in white comic sans on a light tan background that consists of C code. The background is rotated 45 degrees counter-clockwise and is blurred to keep it from stealing attention from the foreground. The original artwork of my character was made by Koidel Coyote. Original artwork of my character by Koidel Coyote who can also be found on the Fediverse at @KoidelCoyote@meow.social.

Intro

You know I couldn’t have a blog without spitting fire out the gate on the first real blog post. This is probably going to be highly divisive and upset several people. I’m not talking to/at anyone in particular, but if the shoe fits, oh well.

This post is about hiring practices when it comes to programmers/engineers and what I believe to be the incorrect approach for a technical interview process; especially when working with potential candidates who are (more likely than not) neurodivergent. You may disagree (and you’re free to), but that doesn’t invalidate anything I have to say here.

You might be driving away excellent talent because you or your company are stuck in a really lame way of interviewing that doesn’t uncover the full potential of the candidates and in the end, the only real loser is you as that talent will just go somewhere where they’re actually understood and appreciated.

Note that this post comes entirely from the perspective of someone on the candidate side of the hiring process who considers themselves neurodivergent for various reasons. I’ve assisted with the hiring process before and I’ve provided hiring managers with personal advice on what not to do. We got some excellent engineers as a result.

So let’s start with a very fiery statement to really get people riled up.

Solving Programming Puzzles Does Not a Good Engineer Make

Too many companies out there are obsessed with this idea that if you say you’re a programmer you should be able to solve a random “little puzzle that’s not too hard, don’t worry about it!” on the spot. I get why they do this, as understanding the problem-solving approach and skills of a potential engineer is a good thing. Using this approach to hire engineers? Sure there are engineers that can do this and you might think that’s perfect, but being able to work under sudden social pressure is no indication of that person’s ability to solve actual real problems that they might run into or may have already ran into (and solved!) in their career already.

Consider that this approach isn’t too much different from, “Oh you like house music? Name every house artist.” It’s obnoxious and doesn’t prove nearly as much as you might think. Someone’s ability to solve a silly puzzle doesn’t say anything about their actual problem-solving skills. Some people don’t even like puzzles, but that doesn’t mean they don’t enjoy finding and fixing problems. I don’t even like doing puzzles outside of my free time, but that doesn’t make me any less valuable when it comes to the skills and knowledge I bring to my team when it comes to solving very real, very difficult problems.

The ability to perfectly solve fizzbuzz or 2sum or any other puzzle does not at all reflect on someone’s ability to properly engineer excellent solutions. It also doesn’t take another factor into consideration…

Many of Your Best Engineers are Neurodivergent

And neurodivergence is not directly compatible with the mainstream when it comes to engineering. Neurodivergence is a hell of a trait and many of us were born with it. Some of us developed it later on due to trauma or other factors that are far outside of our control.

Being ND means that some things rub us differently than others. You may have just had an all-star cishet neurotypical white guy “rockstar” straight out of a grad program who aced the shit out of your high-pressure puzzles, but the ability to solve a puzzle under pressure says nothing about their actual engineering abilities.

Many ND people don’t do well under sudden intense pressure (and especially when it’s sprung on them due to piss-poor HR/talent acquisition efforts that don’t tell them exactly what to expect). Having someone hover over you (even figuratively with something like Codepen while on a call) while you code and realizing that every little judgment they’re silently formulating may be what makes or breaks your ability to pay rent next month causes an unbelievable amount of anxiety. People who are neurotypical or who don’t have anxiety disorders likely don’t “get” it. If you’re one of those people, this is your wake-up call: You’re probably rejecting extremely talented engineers with your strict and narrow approaches.

The idea of solving a puzzle under high social pressure is strange and I believe we should reject this approach and instead seek out a better approach to assessing the technical abilities of candidates.

A Better Approach

The absolute best approach I’ve seen is a two-fold approach.

The first part of that is asking questions and picking the brain of a potential engineer to see how they might approach a common problem. You’re not looking for an exact perfect solution. You’re looking for how they approach the problem and if they’re capable of understanding the problem and its impact. Don’t make up a one-in-a-million scenario. Focus on practical issues that you see on a day-to-day basis. If the potential engineer asks questions, don’t berate them or immediately write them off as not understanding things. Instead take into consideration why they’re asking the question. Maybe you’re pitching your questions/problems wrong or maybe (JUST MAYBE) they’re an excellent engineer who’s neurodivergent.

The second part of this approach is a coding/hands-on test, but not an on-the-spot high-pressure “solve my fizzbuzz CS 101 homework” test. Instead, give a “take-home” test. Provide a virtual machine in AWS/Azure/whatever, get them connected and ensure they can reach it, then give them a real problem that needs a real solution. Have them document their entire process and write up a small blurb about how they approached the problem and why they chose the solution they did. Give them a couple of days or maybe even a couple of weeks if you’re able to. Offer your email address or phone number or whatever else for any and all questions they have and keep track of these questions and the answers you give so you can help out however you can with as little stress and pressure as possible.

You want to test their abilities to solve problems and reach solutions, not their ability to not break down with anxiety attacks and stress. If you’re testing for the latter, your company probably fucking sucks.

About “Cheating”

Now here’s the elephant in the room: “cheating.”

“But if we give them a take-home, they can just cheat by Googling it or asking ChatGPT!”

Buddy, I have news for you: If that’s cheating then we’re all doing it. I can’t remember the last time I didn’t have to Google for something as basic as remembering how to pull an index out of a for-loop for Python and I’ve written a ridiculous amount of complex frameworks that did that on the regular over the span of several years. This isn’t “cheating.” Using reference materials based off searches is not “cheating.” What makes a good engineer a good engineer is being able to locate these resources and implement their own solution based off the resources provided, expanding on those with their own knowledge and experience to get the job done. A direct copy-paste job might be “cheating,” but if they can fully explain what the code is doing and why it’s written that way in their own words that make sense? I’d say their knowledge, abilities, and willingness to reach a solution were properly tested, which was the whole point.

“Our engineers don’t use Google!”

You’re either lying or ignorant. Or maybe they’re using Bing. Or possibly DuckDuckGo. Or maybe Mojeek.

I don’t know a single engineer that I deeply respect who doesn’t have to occasionally (and even sometimes frequently) look up how to do something. The expectation that people should be a walking, talking, typing collection of man pages is ludicrous and expecting that tells me a lot about your management skills. Reflect on that a bit before you send me an angry email.

Conclusion

Set your candidates up for success with as little stress as possible during the hiring process and you’ll have very happy, very smart, and potentially interesting (and likely even ND) engineers you can count on to fix the problems that being able to write/solve fizzbuzz couldn’t.

Got hatemail? Send it here and I probably won’t respond.

Also be sure to check out my email policy before you hit send.

Thanks and have a great weekend.