Beyond Coding Interviews Part II
Interviewing for self-improving, flexible engineers
In my previous post, I argued that you won’t assemble the best software engineering team with technical interviews alone, and that there is a lot of value in assembling a framework for assessing candidates’ “soft skills”.
To this end, I believe that you should aim to hire people that are smarter, more self-improving, flexible, and productive than yourself — and in this post I explore the first two of these characteristics.
Self-awareness drives self-improvement
The most important non-technical trait I see in strong engineers is: continually assessing their own performance, measuring it realistically, and using that feedback to direct improvements — typically numerous micro-adjustments in every aspect of their work.
Examples might be realizing that they are not getting their point across clearly in meetings, so running drafts of presentations past teammates; others finding their documentation confusing, so pair-programming with the first user of the next docs they write; noting that they interrupt themselves by checking email too frequently, so exploring time management strategies and working to change team email practices.
The biggest concern to me is engineers who don’t show habits of awareness of their own skills and who also overvalue their own opinion. Do not hire these people. These engineers may be talented but will likely be stubborn and undervalue their peers. Worse, you will struggle to improve them because they often respond poorly to feedback.
You can sometimes identify such candidates by discussing their resume: they may overplay their own role in previous successes, and underestimate the role of strong teammates, good management, effective process, and good luck. They may also be tools zealots: they may have brought their own favorite tool into their previous three companies regardless of whether it solved a real problem.
On the other hand, I am rarely concerned about hiring engineers who are self-aware but underrate their own abilities. This is common, especially among new graduates, and can lead to a form of imposter syndrome where individuals hold back from contributing, from asking questions, and hence from improving. Good mentoring and gaining experience often ameliorate this.
There are numerous good summaries of teamwork skills, all of which are important for software engineers. In my experience, I would call out flexibility as a pattern to value — and, equally, watch out for signs of inflexibility.
Most software projects are conceived and developed under circumstances of extreme uncertainty. Product priorities often change with every new iteration. Markets move fast and projects can be dropped entirely. Even on a feature-by-feature basis, there are often choices of tool, dependency, API, data format, etc whose longer-term consequences are hard to map out. Production issues come up and work needs to be reassigned.
Your team will be best served by engineers who contribute to discussions yet also commit to the team decision, put the product first, and respond positively to external changes. Amazon’s disagree and commit principle relates to this.
As a precursor to the next section, I think that it follows that the most productive engineers can also sustain their own motivation over time despite the rollercoaster of project, team and company fortunes.
You can look at an individual’s career history to find interview talking points to give you a measure of this: examples of team reorganizations, projects that were shelved, or startups that failed. How did they respond?
In my next post I wrap up by looking at assessing engineers’ productivity in an interview setting.