Hiring for the role

Hiring for Tech
June 22, 2020

An overhead shot of string players in an orchestra

Like in an orchestra, there are different roles you need to hire for. Photo by Samuel Sianipar on Unsplash

In my last post about professional licensing, I said “there’s no one definition of a software developer.” Let’s dig deeper into that statement, starting with the fact that different roles require different skill sets.

Today’s post is based on Key Hoffman’s A Tail of Two Coding Interview Projects, and their personal experience perfectly captures how companies can tailor their interviews to the role they are hiring for:

If you’re hiring someone to contribute to your existing codebase, give them a starting point. Ask them to add a feature and fix bugs using an existing set of coding guidelines.

If you are looking for […] someone who will be making large architectural decisions, building something from scratch is more applicable.

As Key talks about in their post, big companies with established codebases should focus on evaluating how candidates contribute to an existing codebase, with an emphasis on consistency and reliability. Rapidly growing startups should emphasize greenfield projects and simplicity of implementation. And there are other dimensions where companies can differentiate for the role:

All of these dimensions can be addressed with different types of project interviews: what is being built, how vague are the requirements, and what are the constraints put on the candidate? The important part is you be clear up-front about what you’re evaluating.

Different roles require different skills, so it makes sense the interview should be tailored to that role. The corollary here is that you, as the company, need to understand the role you’re hiring for!

In a future post, I’ll explore the topic again, this time focusing on the candidate, namely how to hire capable candidates from diverse backgrounds.