Beyond Coding Interviews Part I
You won’t assemble the best engineering team with technical interviews alone
We’ve been growing our engineering team at Celo rapidly, and that means we’ve been doing a lot of interviewing. It also means I’ve spent a lot of time thinking about making our process the best it can be.
A lot of interviews for software engineering roles focus almost exclusively on technical skills. However, in the teams that I have built, the individuals who end up contributing most and being most valued by their peers are often not those that can solve the most complicated algorithms questions in the least time.
At Apple and at startups including my own, Acunu, I screened or interviewed an engineer almost every day for 9 years. I hired a good number of them, and observed their growth, and have reflected hard on who and what worked and what didn’t. I sum up those learnings here.
Moving beyond ‘cultural fit’
Assessing technical skills in an interview in a way that reflects the demands of a real role is hard enough. It is also absolutely necessary — I assume you’re doing that already. But it is far from sufficient for predicting successful engineering hires.
This discrepancy is one reason why managers hire engineers they’ve worked with before. But not only does this highly limit your potential pipeline, it is not entirely desirable: working with talented new engineers with different employment histories and personal backgrounds provides “cultural value-add”: it helps spread new practices, approaches and perspectives.
At the same time, I have heard countless uses of “cultural fit” or “communication skills” in interview debriefs to refer to “everything else” about the candidate’s ability to do the job. These interviewers are often very specific (to a fault!) about technical aspects such as coding style, algorithmic complexity, and depth and clarity of explanations of architecture. But I feel many lack a framework and vocabulary for articulating “everything else”.
Further, the lack of that framework can lead to unconscious bias creeping into decisions — more so than on more quantitative technical aspects of the interview — leading to the risk of building homogenous rather than highest performing teams.
In this and the following posts, I try to start building a “soft skills” hiring framework by unpacking some of the traits that I’ve seen in high performing software engineers.
Focus on self-improvement, flexibility and productivity
It’s often noted that you should ‘hire people smarter than yourselves’. I think that this statement is usually interpreted in Silicon Valley with too much emphasis on technical ability, but I appreciate the sentiment of where to set the bar.
I believe that you should aim to hire people that are smarter, more self-improving, flexible, and productive than yourself:
- Self-improving means what you see at interview is only the start: they will adapt to and work to improve the organization, priorities, processes and culture and enhance their own skills and working practices.
- Flexible means they’re a person you want on your team: they accommodate, listen, compromise, and move through challenges.
- Productive means they deliver results, by deploying technical skills but also personal and organizational skills that result in focus.
It’s worth highlighting that just as for specific technical skills, I believe strongly in hiring for “potential” as much as “proven results”. Each of these sets of skills can be developed by someone with the right aptitude and the right mentoring and team culture. Precisely what the right balance is depends on the role, organization, and profile of others in the team.
In the next post, I dive into each of these characteristics and suggest how you might assess them in an interview setting.