Interviewing Developers: triggers, part I
Interviewing Developers: triggers, part II
Interviewing Developers: triggers, part III
This post also appears in my other blog.
In the two previous posts I focused on certain behaviors of an interviewee, which may indicate problems with their ability to become a good developer in my team. I covered quite a lot of such aspects that push me towards saying "no" and now it's time to show that I can be positive as well. Positive triggers also help conduct an interview, although rarely shorten it, because they make you eager to speak more to the person. In this post I will list some things that make a good impression on an interviewer, explaining why they are good and thus showing what I look for in potential hires.
Candidate: "If you're interested, I'd like to explain the broader context of my previous job / project / task"
Just basic politeness and showing awareness of the fact that the interviewer may have their own plan and time limits change a lot. However, combined with a person' willingness to share his or her specific past experience it is even more powerful. In many cases an interviewer has to spend a lot of energy to get a reasonable picture of the candidate's background and has few options other than squeezing the bits of information out of the person, so one who offers a clear explanation themselves makes a head start. This positive impression may be further amplified with occasional dives into technical details - for example, down to a brief explanation of a class hierarchy - because this likely indicates both an ability to communicate efficiently and a desire to dig into things and understand them. Finally, note the initiative - sometimes it might be the most important aspect of a future employee - it means they have ideas and fuel to make them happen and your organization will only have to stir them in the right direction.
Candidate: "So we stick that thing into that stuff and …"
This one may sound unprofessional and stupid, but trust me, an ability to explain complex technical constructs using the simplest common language terms (yes, I qualify "stuff" for a term) usually indicates that the person does understand the solution being explained very deeply. Of course, whether you understand what they are telling or not makes a lot of difference and I speak only of the case when that explanation is comprehensible. If it is, you will likely find that it is easy to discuss both the edge cases of the same problem and similar but less familiar issues with the developer. That happens because a person using less formal terms in their speech has already internalized the knowledge being communicated - not just remembered some bits about it - and can play with his or her mental model to adjust and adapt it for other scenarios. This trait of a powerful mind is something that you would terribly like your teammates - especially, developers - to have.
Candidate: "Polymorphism is <reasonable explanation>. Imagine we have a base class called Person…"
Bless the people who provide examples for abstract ideas without being asked directly! Examples help every party involved in communication understand the topic better and spot new questions and ideas. While this merely makes the task of answering an interview question easier to do right, the real value is that the person shows that they are able to see the implications of an idea and view it from different angles. A developer who quickly comes up with examples and tries to view a problem or idea in concrete figures usually thinks realistically and understands the context better. Such a person quickly grasps the real world problems that a piece of software tries to fix and can transfer this understanding to their colleagues. As for an interview, they try to make it easier for you through their usage of examples and this alone deserves some respect.
Candidate: "We were using ASP MVC 2, which is kind of old, so I decided to learn Node.js and built a personal web-site / game / whatever with it"
Here I barely need to explain anything: desire to learn and develop on one's own is what makes great professionals. They also don't blame their boss or organization for not giving them an opportunity to learn new things or work with the hottest new technologies - they simply learn whatever they find appropriate when they feel a desire to do so. On the other side, any developer may occasionally get a bit tired with their day job and issues associated with it. A person with a positive attitude feeling their own responsibility for their growth will be able to help themselves through such uneasiness by means of a personal project. It is true that such a side activity may distract someone from their job, but the stakes are high it would rather improve the way the developer attends to their duty giving them extra energy and ability to bring new ideas from the outside world.
This is far from an extensive list of positive interview triggers and there are dozens of things that will make an interviewer like a candidate. Still, I will stop right here, because the things said are enough to give a good indication of what I value when sitting on the hiring side. I must have highlighted this a thousand times, but any hiring decision is based on a lot of factors and no single one of the triggers that I mention should be treated as a basis for yes or no. Still if you have a collection of such triggers in mind they may help a lot navigating you through the process of acquiring a new team member.
An interview is about finding a great person to close a gap in your team, so it is important to note both positive and negative edges of the candidate's personality. The goal is to check whether the candidate is a good fit for the open position, the team and your company's culture - that's why I pay that much attention to the communication abilities and personal traits. Of course, the most important purpose of the interviewing process is to avoid hiring the wrong person - hence the relatively large number of negative triggers in the previous posts versus few positive ones in this one. At the same time, noticing the good aspects is also important - especially when these show that after being hired the candidate will keep growing professionally, help others and improve the way they and their new team do the job.
In conclusion of this short series I wish you good interviews - on both sides of the process - and welcome you to share the bits that help you learn more from them!