Technical Interviews Are Not Spec Work

We’re interviewing people to join the Corgibytes team. When I mention this to others, I hear a wide range of opinions on what exactly those technical interviews should look like.

Over the years, I’ve experienced the gamut myself. Some were intensive. Some thought-provoking. Some… bizarre. Having been on both sides of the “table,” I understand the point of view of the recruiter as well as that of the candidate.

I think the basic goal everyone has for a technical interview is to answer a simple question: “Can this person do the work that we’re asking them to do?”

The approaches taken to get an answer to that question vary drastically across the software world. Organizations may present candidates with complicated puzzles that need to be solved. Or have potential employees write code on a white board. Or ask candidates to complete a mini project. And, sometimes, these mini projects look dangerously close to the work that the candidate should be paid for producing.

I encountered one of these projects as a candidate. I was given a set of anonymized data out of the production database for the application I’d be working with. The task was to do something “interesting” with the data. The data contained a series of financial transactions, and I had recently listened to a podcast which introduced me to Benford’s law. So I wrote up a quick command line utility for determining if there was any data in the database which appeared to violate Benford’s law, and thus should be evaluated as a potential source of fraud.

It felt a little odd to be asked to try and deliver something which might be of value to the organization that was asking for it. It wasn’t clear to me who owned the code that I was writing. Was it me? Was it the company I was applying to work for? Were they planning on using any of the submissions that they got? Those were all questions that I had, but was afraid to ask, because I needed a job.

I was recently at a conference where one of the presenters, in a talk which focused on tips for growing your technical team, strongly advocated for candidates to do actual work on the system they’d be working on. Going as far as to suggest that candidates should be given actual tasks to work on. It was unclear to me if these candidates were to be compensated for their work or not.

I have a lot of friends in the Graphic Design community, and I’ve heard many discussions about the dangers of spec work. And I’d argue that the scenarios above are examples of spec work in action. I think that if that practice is considered unethical in the design community, then it should be equally unethical in the software community.

What’s the Big Deal?

Asking for spec work during the course of a job interview signals to the candidate that you value the organization’s need to determine if they can do the job over the candidate’s need to be fairly compensated for their time. And that sends a pretty clear message that the organization’s needs are going to be valued above the employee’s throughout the working relationship.

But How Do I Figure out Who Can Do the Work?

The secret to having a technical interview that doesn’t rely on spec work is to make sure that anything that the candidate is asked to create will provide them with some intrinsic value. That’s not easy. Figuring out a way to craft a screening process so that it benefits the person going through the screening is very hard.

The approach that we take for this, at Corgibytes, is to use Exercism.io during our technical interviews. And we don’t ask candidates to work the problems on their own. We like to pair with them while they do it. We split that portion of the interview in half. The first half, we work in a language of the candidate’s choosing. In the second half, we work in a language of the interviewer’s choosing. Candidates are encouraged to continue to work the problems after the interview and to submit them to Exercism, where they have the potential to receive feedback about their solutions from other Exercism users.

This gives us the ability to watch someone code in a language that they feel strong in and one that they are likely not strong in. As the employer, we learn a ton during this part of the interview. We learn how people deal with adversity. We learn how they approach problems. We learn what resources they are comfortable using to get answers to questions.

Our goal is also for our candidates to learn a lot about us. Through the process, they find out what it would be like to work with us, how respectful we are of our staff’s time, how easy we are to talk to. The reality is that in the software world, candidates are interviewing future employers just as much as the employers are interviewing them. How an organization treats people is important. And respecting people’s time should start well before they become employees.