Summary

The author learned that code testing alone is an insufficient and potentially biased method for hiring engineers, and that a more holistic approach focusing on problem-solving, creativity, and communication is essential.

Abstract

The article recounts a conversation between the author and a programmer who criticized the practice of using code tests like HackerRank to screen engineering candidates. The programmer argued that such tests eliminate candidates who think outside the box, emphasizing that engineers should be hired for their ability to solve problems and challenge the status quo, not just their coding skills. The author, initially agreeing to the employer's demand for code testing, was challenged to reconsider this approach. After reflection and consultation with a lead engineer, the author concluded that code tests should not be the primary factor in hiring. Instead, the author advocates for a hiring process that includes a human conversation, a whiteboard test, detailed discussion of an engineer's code, and finally, a code test. This approach aims to evaluate the candidate's thought process, communication skills, and potential to contribute to creating innovative software.

Opinions

Code tests are seen as a method that can stifle creativity and potentially embed bias in the hiring process.
The ability to regurgitate code during a test does not equate to the ability to think critically or develop life-changing software.
Engineers who can communicate their thought process effectively are more valuable than those who cannot, even if they are technically proficient.
The hiring process should prioritize understanding how an engineer thinks and solves problems over their performance on standardized code tests.
Resumes can be misleading, as engineers may tailor them to fit a role, making job titles and experience less reliable indicators of their capabilities.
The true measure of an engineer's potential is their ability to work collaboratively with other talented engineers, fostering an environment where new teams can form through the process of mitosis.
A code test should be just one component of a comprehensive hiring strategy, with the human elements of conversation and collaboration being paramount.

A Programmer Explained to Me Why I’m an Idiot and a Moron in the Same Sentence

Tests rule out the people who think outside the box.

I was an idiot and a moron. A self-help junkie like me should have known better.

We met for the first time. He works client-side looking after teams of engineers. I work with clients like him to help them build engineering teams at scale and expand through mitosis (members of a successful engineering team branch off and create new teams).

I explained to him how his employer wanted me to code test any new engineers with HackerRank and I agreed with their decision. (This was ironic because I’m not a coder and can’t read code.) It was at this point where he got fired up. His face turned a little red.

“You are an idiot and a moron if you think you can code test engineers to try and find good ones.”

I was a little taken back. We weren’t even friends yet. Should I be offended? He continued:

“Code tests rule out the people who think outside the box.”

He started rattling off example after example of gun engineers who performed poorly on a HackerRank test. He showed me the work these engineers produced and then their poor HackerRank results. This next line got me:

“You hire engineers to think and solve problems. Being able to regurgitate code like you’re studying for a high school math test means you can follow orders. I don’t want engineers like that. I want the rebels who are brave enough to challenge the team, therefore helping to create life-changing software.”

I’d fallen into the trap of following orders. I took what his employer said about code testing too literally.

I got home from work that night and thought about what my new programmer customer friend had said. I thought about it for hours. Can you really box someone into a corner and test whether they think differently using standardized thinking? It hit me hard: no. A code test is a tool, yes. But a code test shouldn’t be the defining factor used to select engineers for a project.

Code tests can kill creativity.

You can block engineering talent from ever finding your project if you use a code test designed to embed bias in your hiring process.

Code tests, in a way, are like racism. They judge people on an arbitrary measure.

I went back and spoke to my lead engineer. I asked for his help.

“Could we be smarter about how we hire? What would it take to test the way a person thinks instead of just their engineering skills?”

The response was classic:

“Only a human can properly test how someone thinks.”

It’s not just their thinking either. The lead engineer also taught me that it’s how an engineer communicates their thinking that is key. You can think outside of the box and come up with life-changing code, but if you’re a nuff-nuff that can’t explain your code in English, then nobody is going to listen to you — and you probably can’t build an entire software platform on your own.

Now I’m no genius engineer thought leader. But I did radically change my approach to hiring engineers after the initial conversation that pointed out I was a moron and an idiot in the same sentence.

I made the call to focus on:

A human conversation.
A whiteboard test.
A conversation about an engineer’s code that asks them to explain their thinking in a lot of detail.
Finally, a code test.

The least important part of an engineer’s hiring process was their resume. I learned quickly that engineers were like chameleons: they could change color based on the role they were applying for.

Someone who was more front end than back end could quickly reshape their resume to sway their profile in either direction. I also learned that job titles were ridiculous. Many engineers attempted to call themselves “lead engineer” when they weren’t really.

When you overlay a global recession on top of this engineering picture, you realize why engineers decide to bend the truth a little. People need work so they can pay their bills. A few white lies for an engineer who needs to pay bills and get on an engineering project ASAP is expected. There’s no point being mad at them if you have at least a tiny bit of empathy left inside of you.

A code test isn’t the answer to the question “Can this engineer excel at their job?” A code test is one tool in the toolbox for hiring engineers.

The real secret to hiring amazing engineers is to have an already excellent engineer, who can think outside of the box, do the interview.

Talented engineers attract talented engineers. These engineers then breed while on a project together and allow the process of mitosis to occur and create new teams that spawn off the original project. A code test on its own is useless — and biased.

Put the human back in hiring engineers.

A Programmer Explained to Me Why I’m an Idiot and a Moron in the Same Sentence

Tests rule out the people who think outside the box.

Join my email list with 40K+ people for more helpful insights.