Interviewing: A Development Manager’s Perspective

March 19, 2009

This blog is about Software Results, and I’m currently exploring my role as a development manager in delivering results. As a manager, I’m NOT directly part of the teams that are delivering software (well, I am also a Product Manager, but I’ll cover that in a future post), so what is my role?

For a start, what I need are people who do code – and code well. In the spirit of the book Good to Great by Jim Collins, one of my keys to high productivity is having “the right people on the bus,” and this means hiring right. I covered the resume process in my last post: What a Manager Looks for in a Resume, this post is about the interview process.

Once I’ve screened the resumes and narrowed the list of candidates down, I will typically conduct phone screens as my first interview. These are always short, as my objective is to ask pointed questions geared at confirming that your experience on the resume is accurate.

One of the first things that go wrong for people is when I determine that the technology “experience” on a resume is there because an individual worked on a project that involved that technology, but they didn’t have any actual experience with this technology themselves. Believe me, there are times when resumes have been chock-full of implied experience, and it didn’t take me long to determine that the resume was severely over-stated. 

One suggestion that I have is to choose your words carefully. The purpose of the resume is to talk about you and what you can do, not to describe the projects that you were a part of. Instead of mentioning technology – and creating an impression that you may have worked on something that you haven’t – cite the experience that you have, and take pains to accurately represent any other involvement.

For example, don’t state that you worked on the “universal translator project written in C# and storing data in a SQLServer 2005 database designed from scratch.” This describes the project, but what did you do?

I’d prefer to see something like: “Collaborated on the design of the universal translator, personally developing 80% of the C# code that was used in the final product and was recognized having virtually defect-free by our QA department. I also worked closely with the database architect who designed the database schema for the SQLServer 2005 database. “

Now we have some things to talk about! During the phone screen we can have a quick conversation about the challenges and work that you did perform, and how you collaborated with the database architect. These would be areas that I would be sure to explore in greater detail in a personal interview; but you’ve satisfied me that your resume reflects your actual experience.

Once I’ve decided to bring someone in for an in-person interview, the field has been narrowed significantly because we want to spend much greater time with those that we’ve determined to be solid prospects. In addition to interviewing with me, I’ll arrange for interviews with other developers, particularly those who you will be potentially working with.

We don’t deliberately orchestrate high-pressure interviews, but we do conduct team interviews – and some people find this to be intimidating. I will admit that teams of people can add to the stress, partly because a group will toss out questions that take you all over the board, forcing you to mentally switch gears. Seeing how you respond does help us to understand how you will operate under those times of pressure.

At some point in the team interview, the interviewee will end up on a white board talking through some problem. It’s all about understanding your thought process and how you go about problem-solving, along with interacting with those that are your potential peers.

When deciding on a candidate, I’ll defer to the team’s assessment of your specific technical skills, but as a development manager – and someone who did a fair amount of coding in the past – I will probe into how you approach your job. I’ll ask you how you go about writing high-quality code, from design to actual coding and unit testing. I’ll also explore the types of interactions that you have with the QA department, what you do when a requirement is not clear, or how you deal with someone who is not holding up their end.

I’ll ask questions to gain an understanding of both your knowledge and preferences; I’ll ask about what is causing you to leave your current position (assuming that you haven’t been laid off due to a poor economy – something that is very prevalent these days, unfortunately), and how you like to take direction.

I’ll ask for your opinion about who the best manager that you have ever worked for was, and why. Part of this is to understand what management style will make you feel truly comfortable and productive, and part of this is to uncover anything that I can do to improve myself. Interviewing is a time-consuming process, and I try to get a little pay-back out of the process while I’m at it.

As part of the interview process I will want to determine if you are the type of person who will continue to learn and grow. Do you read any particular blogs, or even blog yourself? Do you read trade journals? Do you participate in any open source projects? Anything that indicates that you take initiative to keep yourself current in the technology arena certainly reflects well on you.

Ultimately, I want to understand what makes you most productive, what management style works best for you, any work preferences that you have, and whether you will an asset today and tomorrow. It’s hard to find perfect matches, but I do try to cover the bases.

If you want to stand out from your competition, do a little homework first. Visit our web site, find out about our company. I’ve been impressed by what some candidates have been able to learn prior to an interview. Others come in without knowing a thing about us, despite this information being readily available.

Ultimately, we make hiring decisions that examine a candidate from a variety of perspectives, and involving multiple people. After an interview, we discuss the candidate and weigh what we have learned against our needs. And if there is any uncertainty, we’ll bring you back for another round. And our standard HR process is to check references and conduct background checks.

Overall, I consider due-diligence in the hiring process as very important to the business. Hiring wrong at the least will not be of true benefit to us or the new hire, and at worst will make things miserable for all concerned. If we don’t find a match, we pass.