Hiring for the role

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:

• Area of the tech stack. Web, mobile and backend developers may have some common evaluation criteria, but there are plenty of differences between these roles. Frontend developers should understand how to build UIs, while backend developers should understand databases and scalability.
• Product vs. technology. This is the area I see traditional interviews failing all the time: companies emphasize technical ability to the detriment of finding candidates who can deliver solutions for the target audience. There are roles where technology is key, but most need some product focus. Would it help to hire a domain expert whose technical skills can be improved?
• Early vs. late-stage product. Is the goal to build out a quick-and-dirty feature, or to create a scalable, robust architecture? How many users and how much traffic does the solution need to support?
• Seniority. If you’re looking for someone to be a tech lead, focus on architecture and trade-offs. If you’re hiring someone to pump out code, ask them to code!

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.

This article was originally published on the Hiring For Tech website. If you want to read more content from me, please subscribe either by email or on LinkedIn. And please reshare with your networks so others can find out about Hiring For Tech!