One of the most common deciding factors in many modern tech interviews is the code test. Oddly, this spans many career categories: engineering, product management. I’ve even heard stories of folks in marketing being given a test to see if their tech knowledge was up to snuff.

I’ve been around the block a time or two. I’ve been a developer for many years, a Developer Advocate for the most recent. I’ve always entertained folks looking to interview for places where I’ve worked or places wanting me to work for them. In a few cases, the deciding factor is the code test. And what does it always start with?

FizzBuzzBack in the heyday of youth with when teachers were teachers and the common core meant you shared an apple with someone, we played a game called FizzBuzz. Simple rules, any kid could understand it, but it meant thinking fast and on your feet. Any threes or multiples thereof were “Fizz”. 5s and multiples thereof were “Buzz”. Multiples of both that crossed, such as fifteen, “FIZZBUZZ”!

Mess it up, move to slow, and you brought disgrace upon yourself.

So, nostalgic people that we are, we make this a code test, a kata to see if someone has the chops to get the job at the big startup with the huge VC backing and a sweet ping pong table. Some folks think this will weed out the slow witted or those unable to kick out code under pressure. Especially if the code test is administered under duress, code it up in as many languages as you can in the next half hour while we watch on Google Docs, for example.

What does this serve to prove? That we can play children’s games and produce code?

All we learn from this is if someone can work in an artificial environment under artificial pressure for an artificial result. It was so frustration I actually created a repo called FizzButtz - because if we’re going to be childish, be childish all the way.

We need to find better ways to find our best developers.

One of the more productive ways to get a good idea of how someone codes or how well they might work within the company might be to actually bring them to the company and give them a spin. Have them sit with an experienced developer on the team who knows the code and knows the business logic.

This might seem like the most logical thing in the world. Granted, steering people away from the Intellectual Property that makes a business run is tough, but there is always some feature or some new thing that you can have someone work on.

It’s not about them working on the code so much as working within the confines of the team you’ve built. Every team, engineering team, marketing team, community team - every team comes with its own culture. The culture fit can be more important than talent or skill or whatever it is that makes someone amazing at what they do.

There’s a lot more to learn from a person in person than their performance on a test.

The Junior Developer and You
To go along with the idea of pairing, it might be beneficial to take a look at some new streams of influence. No one sees the world quite like someone with new eyes.

Yes, a Junior Developer comes with less skill than a seasoned developer. Yes, it will take time to bring a Junior Developer up to speed.

Here’s the big win though - no baggage. Junior programmers are new blood on the team. They bring perspective that a more seasoned developer might be too jaded to bring to the table.

And here, a code test would be as near to worthless as possible. The katas and simple “tests” and games are things they’ve been doing coming through bootcamps or weekend warrior training or where ever they may have built their love of programming.

Conclusion
They say teachers shouldn’t be forced to teach to the test. That’s about the students. Developers shouldn’t be forced to code to the test either. Find other outlets, other ways to see if the person you are looking for is the person who is right for your team.