Live-coding vs take-home assignments
Hiring engineers to join our talented team is one of my main responsibilities at Beerwulf and after hiring engineers for almost 2 years, I have one conclusion: It’s one of the areas that an engineering manager can be most impactful to the team success. After all, it always starts with finding the right talent.
I’m not going to claim that it’s an easy process. You have very limited time with candidates where you try to assess their knowledge, experience, ambitions, expectations. Luckily, you can explore most of these topics via a genuine conversation. Most of the times, a conversation with the hiring manager also allows candidate to get a feeling of the culture and ambitions of the team, which is very useful. But there’s one area that a conversation cannot fulfill a fair judgement of candidate: coding.
We have one simple rule at Beerwulf Engineering: never hire a developer/engineer without coding. Reaching to this simple rule took a lot different experiences by having different hiring strategies at different stages of the company. We sort of learned things from hard way, while we could’ve just look at common standards in our industry. That’s fine, this learning is still valuable and we know how important it is now.
We’ve also tried different technical assignment strategies; we had technical walk-through topics, we had take-home assignments followed by peer reviews and now lately, we decided to change all that to one or multiple live coding assignments. Why? That’s what I intend to explain in this blog post.
I think live coding assignments are far better than take-home ones, and I’ll try to explain this from different perspectives.
Time
When you give take-home assignments, you usually give candidate some time. Let’s just assume that it’s 5 days. Candidates use their personal time (let’s just assume they have the work ethic not to do it during the shift for their current employers). After time is up, you usually have some review, async or via jumping on an interview together. You carefully check the assignment, ask candidate some questions regarding certain choices they made in the code. Overall, you spend 5 days to wait, then some time to pre-review (15–20 mins) and then the review interview w/candidate, which can take 45 minutes.
From candidates’ perspective, they were busy with your assignment on their personal time, hopefully around the time you’ve devised it to take. Sometimes, local environment acts weird, or candidate have to setup a local dev environment to be able to start developing. It usually takes longer time for candidate than the time you’ve foreseen. Sometimes, if they’re perfectionists, they’ll spend every minute they have before deadline to make it even better. Given that we’re in the middle of a pandemic and we all, one way or another, have experienced how valuable our personal/off-grid time is, you’re taking some tiny toll on their personal time.
Well, now let’s consider what happens if you have a live coding assignment that requires no preparation or anything beforehand. Candidate will only spend the time of live coding interview with you, which is perfectly normal and fair. You’ll save waiting time of 5 days in this theoretic example. Win/win for both parties, time-wise.
A better judgement
One thing I’ve learned very deeply in the last years is that most difficult aspect of software development is not computers but humans. I don’t think this is something that you’re hearing for the first time. Best software comes out of teams that had great collaboration, clear communication and trust. And right technical skills and experience.
Even though take-home assignment can assess technical skills and experience very well, I tend to think you have limited exposure to other important aspects I’ve listed above. Some might say that’s okey as long as you get a good understanding of technical skills, but I beg to differ. Even though technical skills and knowledge is very important and non-negotiable, what makes a software developer great is also having skills that opens room for exponential growth and makes them a great collaborator.
One other area that you can get a better judgement is practical thinking. Some challenges will expose candidates to a context where you can have a good understanding of how candidate adopts to different situations and how they handle constraints, in this specific case, constraint of time. Let’s just face it. Engineering always works with constraints and it is an art of making right trade-offs. Putting your candidates into a pressure-cooker kind of environment will allow you to judge their ability to make right trade-offs.
When it comes to candidate, they’ll for sure get a glimpse of the culture of engineering organization. What is a better way to understand how a team works than actually pairing with them for some time? I tend to think that we’re also humble enough to admit that there are elegant solutions to the assignments that we couldn’t think of when we were designing them. Seeing your interviewer humbly admit that this is a great way to solve their problem on live should tell a lot to the candidate about team culture.
We’re very enthusiastic about this new approach we take and will be willing to share more about it as we go through interesting learnings. Until then, please make sure that you check open positions to join our expanding team.
