Coolbits Tips

.NET and general software development tips and articles I've written.

Go Back

Technical Interviewing

Adding the right software developer to your team can improve productivity and help to make your project a success. Adding the wrong person is to certain to have the opposite effect – a drop in team efficiency and the possibility of making your project fail (or at a minimum, making it a miserable experience). So, finding the person who can best help your team work effectively and productively should be a top priority.

Here are some tips I have found helped me find talented software developers during the interviewing process.

#1: No Tricks
Do not ask trick questions in an attempt to confuse the candidate. This includes questions designed to identify “original thinkers” or people who “think outside the box”. Someone’s ability to answer a question like this doesn’t necessarily reflect his or her ability to write code. In fact, someone who can answer your “trick” question might fail miserably at the next one you ask. Also, keep in mind that the candidate is also interviewing you and your organization. Just as you are trying to determine if they will make a good fit for your company, they are also trying to figure out if they want to work for or with you. Asking irrelevant, tricky questions will not convince them your company is where they should be.

#2: Be considerate
Read the applicant’s résumé before meeting with them. Reviewing it beforehand provides you with two benefits. First, you will have a picture of the candidate’s experience that you will then be able to probe in detail about. For example, a description of the candidate’s experience discusses an eCommerce application that was built; you can ask specific details about the project (i.e. number of development team members, number of users supported, role on the project, challenges encountered during development, etc.) Second, you’ll let the candidate know you cared enough about meeting with them that you took the time. If a company doesn’t bother preparing for a meeting with me, why would I want to work for them?

#3: Self-evaluation isn’t enough
Do not accept a candidate’s self-evaluation of their skills on a particular technology. Everyone uses different criteria for determining if they are a beginner or expert, and it is better to find out now what the person can really do than after you have hired them. I have seen this work both ways. I have interviewed candidates for development positions when they rated themselves highly for almost everything, but couldn’t answer basic questions about specific technologies or operating systems. One told me “I’ve been told ‘Jack of all trades, master of none’ but I don’t believe it. I am a master of all trades.” Yet when I asked him about what he could do that justified his “expert” rating on Windows 2000, he told me he could create user accounts (and declined to offer any further information). That’s it?! I’ve also interviewed candidates who felt that they were only beginners with SQL Server 2000. Yet, they could create a normalized database, create views and stored procedures, and create complex queries effortlessly. So ask probing questions to get more details.

#4: Communication is key
Communication is an important component of any software development position. I’ve known several people who were hired because their technical skills were excellent, but they needed help with their communication skills.  I disagree with hiring people on the basis on their technical skills, without looking at other important professional components. Software development teams work most effectively with developers who can (and do) communicate with each other. Even if you are hiring for a team of one developer, that individual will still need to communicate with users, project sponsors, or someone. In fact, I would argue that in many cases, technical skills can be learned and improved. While this is also true of communication skills, these are more intransient and difficult to change as time goes on.

How do you evaluate the communication skills of the candidate? First, I always give candidates an opportunity to ask me questions about the position. Candidates with good communication skills use this time to find out more specifics about the company, the team, the types of upcoming projects, and the kind of development work they might get to do if hired. Excellent candidates will demonstrate clearly that they have been paying attention to the rest of the interviewing process by asking questions about things they learned during the interview. (For example: “You mentioned that some of the projects here are not using .NET. Can you tell me more about which projects fall into that category, and why?”) Candidates without good communication skills will not ask any questions at all, or will ask simple, boilerplate questions.

#5: It’s about problem solving
Problem solving are important skills in all software development jobs. Every developer needs to have an approach for solving problems they have never encountered before. There are two ways you can evaluate the problem-solving skills of any candidate you interview. First, you should be prepared to ask questions about specific problems the candidate might reasonably encounter in the job.

For example, you might ask something like this: “A client-server application written last year has recently started behaving sluggishly. It uses a SQL Server database, and was written in Visual Basic 6. How would you resolve this problem?” Hopefully, they will be able to tell you several areas they might investigate (checking the indexes to make sure they are optimized, determining when the performance problems are occurring to see if there are blocking issues or problems due to other jobs executing at the same time, verifying if the joins are created in the most efficient manner, just to name a few things to check). I use questions like this to see how many different possibilities a candidate comes up with. I am usually wary of a candidate who can only provide one or two suggestions for a broad trouble-shooting question like this.

Another way you can evaluate the candidate’s problem solving skills is to ask them directly: “How do you solve problems?” or “What do you do when you get stuck on a technical problem?” Experienced developers have a variety of sources they can go to for answers. I have interviewed candidates who have answered this question by saying “I check MSDN for the answer.” Of course, checking MSDN is a perfectly reasonable approach, but it is hardly the only place where you can find answers to problems, and it certainly isn’t the most complete. Candidates who are the most experienced know that the public newsgroups and list servers also can provide answers to technical challenges. Seasoned developers also generally have their own network of colleagues they bounce ideas off of, or a few other favorite websites or books they use for resources on certain problems.

Remember – software development today is very broad and everyone gets stuck occasionally. The developers who are most successful are those who know where to find the answers to technical problems. 

#6: Set standards
If you have certain coding standards or approaches that you want the team to adhere to, make sure to ask questions about that philosophy to make sure that the candidate can work within your boundaries. For example, if the development standards for your team are to never use bound controls, then you should definitely ask the candidate if they typically use bound controls, and how they feel about the standard. First, this gives you an opportunity to express your standards and expectations up front. Also, it might give you an opportunity to learn something new, perhaps a different approach or something you hadn’t yet  considered. Finally, it again gives you the opportunity to learn more about the candidate, and how they might fit in with your team.

Finding the right new developer for your team can make your group more successful and productive. Pay attention during the interviewing process, and you will end up with great new employee.