Maggie++

There are many styles of interviewing software developers.  The best processes are those that allow you to see if the candidate is a good fit for your organization and for the candidate to see if your company is a good fit for them.  Shortcomings on either side can lead to costly mistakes and wasted time on both sides.

When I worked on the GSM switch project at Motorola in the late 80s we spent considerable time recruiting software engineers.  Our process was typically:

• one engineer would escort candidate from HR to the office area giving a short tour on the way.
• manager would briefly talk with them and explain the project at a high level and the day’s schedule.
• depending on candidate’s level and on our availability 2-4 engineers would individually give technical interviews.
• one interview would include lunch out in a local restaurant.
• the manager would meet with them again for any follow-up questions and to inquire which part of the system they were interested in before they were escorted back to HR.

This was in addition to the countless hours looking through resumes, phone screen beforehand and HR’s interviews with them before and after ours.

My interview technique was to first have them explain their previous projects and I asked questions where I needed clarification.  Then I would draw a high level architecture diagram of my subsystem and explain how it fit into the product and its purpose.  I would let them lead at this point; I was looking for them to show an interest and curiosity about the system by asking questions and an aptitude for talking about a system from both a high level and a detailed level.  I was looking for inquisitive thinkers who seemed eager to learn and work on a team.

 The candidates did not usually have nor did we expect them to have any telephony experience or knowledge of cellular (analog or digital) phone networks.   Most did not know C or assembler nor had heard about the object oriented concepts we were designing with.  These were important, but at the time software engineering was all about design and process and not at all about the underlying technology.  In fact we did not know ourselves at the beginning if we would be using C++ or C.  Our previous phone switches were coded with assembler.  We ended up using C as the C++ cross-compilers were not proven for our processors at the time and would have been an unnecessary risk.

This process consumed much time but we ended up with an outstanding group of software engineers.

Two podcasts I’ve listened to this past week have had content on more recent interview practices.  First was Episode 16: Interviewing Software Developers from Herding Code.   From the show notes:

This week Kevin leads a discussion on interviewing software developers:

• What interview styles we find effective
• What sort of questions actually help us evaluate a candidate
• Why API trivia and puzzle questions don’t work
• Hiring mistakes we’ve made based on errors in our interview style
• Why we don’t do very well when the tables are turned and it’s our turn to be interviewed"

Second one was a podcast featuring Scott Kriens, of Juniper Networks, from Stanford’s Entrepreneurial Thought Leader Speaker Series brought to my attention by Dianne Marsh on twitter.   While the entire talk is not about interviewing there were a few points he made about attracting talent and employee growth that are of interest to the topic.  The first (watch here) encourages developers to embrace challenging interviews and not to let them intimidate you and the second one (watch here) talks about the value of training the employees you have rather than hunting for the one star player.  He states:  “It’s better to give somebody that’s never done something before the chance to do it, then to ask somebody who’s already done it to do it again with energy and enthusiasm. ... There is a real power and passion to prove yourself.  ... They will surprise everyone with their ability to succeed.”

The first one is hard for the candidate and the second is difficult for the employer.   I know times have changed much about the way software is built and funded and a full-day interview would indeed be a luxury and quite costly for all involved.  However getting good thinkers and problem solvers on your team instead of good test-takers is key.  Paying for training and the costs from missed work time can be great but by embracing education as a means to train and retain their developers , companies will see positive results with enhanced productivity and retention.   When growth brings the need for more developers I think an approach that enables both sides to really get a good understanding of each other is prudent.

What techniques do you find useful for finding good developers and what as a developer do you do to find a good employer?  Please leave comments with your ideas or blog about it and comment here so we can learn from each other.

maggie++