Why we don’t insist on homework assignments for recruiting

My wife once remarked, “I live my life in the gaps between interruptions”.

We have a 6 year old. If you are a parent, the above statement probably resonates.

With the roles we have open in my team at the moment, we are trying to attract experts and skilled practitioners who are mid-career, probably have families, and are most likely already in comfortable places career-wise. Homework exercises are an unnecessary hurdle we put in their way. We waste many hours of their time in making them do something that could be evaluated in a face-to-face conversation that spans roughly 10 minutes. (Yes, as interviewers, we are skilled enough to do this.)

In the past, we used to give homework assignments to candidates, after an initial screening suggested they have baseline skills. Many wouldn’t get back to us after being given this task. They did not withdraw from the interview process. They just did not get back to us. This suggests something, but it’s probably not laziness. They probably intended to actually do it, but couldn’t get the time. Life is busy — something always gets in the way. In balance, after some reflection, they concluded that the effort wasn’t worth it. They were probably right, given the partial information they have about us as a potential employer.

Homework assignments penalise those without time, for instance, single parents, women, those taking care of others, people who have professional or other commitments beyond their current jobs. The list is open-ended.

OK, so how do we then assess candidates? We ask them to come prepared to talk, in-depth, about any interesting engineering problem they have worked on in the past. Anything they have a passion for. They can bring slides if they wish, but that is optional. The only requirement is that they articulate in a manner that the interviewers can understand. This is a requirement even fresh graduates can meet. We provide hints a priori on what that conversation might include. The structure is typically:

1. Problem or opportunity identification: The core problem, the technical challenge, the business case, etc.
2. Approach to solution: They can get as technically deep as they want here.
3. End results: What benefits did it bring, if any? What didn’t work out as expected? Why?

We strictly enforce a time limit of 20 minutes for this conversation. Why? Because, we realise that you can talk for hours if it’s a topic you like. That is great. However, we want to get to know you a little better too. And we would like to have the opportunity to do so in the remaining 40 minutes. Yes, we try to restrict a single interview session to about an hour, although there may be additional rounds with the project lead, CEO and so on. In each session, the focus is different.

Where we think it is necessary to assess coding skills, we prefer reviewing work that already exists. I wrote about this a while ago. However, there is more to product engineering than just coding and software development. These are hard to assess with a narrow focus on just the coding skills.

We respect your time, and we are unable to compensate you for the time you spend in doing our programming assignments and going through our interview process. And at this moment, this is the best compromise we have come up with.