I’ll take app dev for $1000. The art of asking technical interview questions.

I’ve been working professionally in application development since the fall of 1998.  I’m a consultant, and I’ve been in quite a few environments over the years.  However, I have also worked as a full-time employee in leadership positions in places.  I began interviewing candidates for technical positions in 2007.  Even after having been the interviewee many times before I quickly realized that asking the right questions isn’t nearly as easy as it looks.

The first technical interviews I conducted tended to be like quiz shows.  All of the advice I could find on technical interview questions centered asking very specific technology related questions, or more academic questions on fundamentals of things like object orient programming.  My problem at this point was that I relied strictly on these questions, and tailored them to my exact needs at the time.  There is nothing fundamentally flawed with asking these questions.  They are important in establishing somebody’s base line abilities, but they really don’t give the full technical picture by any means.  This level of interviewing is a beginning skill set that is important, and I don’t mean to criticize, but was not nearly important as I thought it was at the time.

So, what was I missing?  How could I be doing better?  I try to be introspective, and I try to acknowledge when I’m wrong on an approach.  I suspect that if you are reading this you may even be that way too.

The first piece of advice I got from a friend was to tailor my interview questions to the candidate’s resume.  Don’t just proceed down a laundry list of technical questions you want answered.  Typically in the interview process you are provided with tens if not hundreds of resumes.  What was it that made you pick this candidate out of the stack of 50 resumes you had just reviewed for an interview?  What interested you about them?  What skills or experiences did you highlight on the resume?  If they spurred you to interview the candidate then you definitely want to delve further into the skills.  You want to make certain that what the candidate says on his/her resume matches your expectations.  Many times I’ve reviewed resumes where a candidate states that they have worked on a project with Xyz framework.  I get excited because Xyz framework is one that we are using on the current project, or very similar to it, and its hard to find people who are skilled in this area.  So, I start to ask probing questions to find out how much the candidate really understands the framework, and/or has used the framework.  More often than not one of two things winds up happening from my probing questions:

  • It turns out the candidate has only used a very minute part of the framework, and its not one that’s even very meaningful to me.
  • The candidate indeed used the framework, but it was indirectly through a wrapper API that somebody else created.

People seeking jobs are trying to catch your eye so they can have a conversation with you to prove whether they are right for your job.  Its just human nature to exaggerate your skills at times on a resume to get that initial conversation started.  Resumes are really just sales materials, and as the interviewer you have to probe those sales pitches from the resume to see if you will really be buying what you expect.

Another key skill to interviewing is to tailor your interview questions to the type of position you are hiring for.  This may sound obvious, but its easy to get hung up in asking interview questions aimed at your ideal candidate, who you want to work with for years and years.  These questions really may not be appropriate if you are looking to hire somebody temporarily for a 3 month project.  In fact, questions for short term candidates should probably be much more technically specific.  You don’t have time to train them up on your current technology stack.  You need the candidate to be able to hit the ground running.  On the other hand, if you are hiring for long term positions you should probably de-emphasize specific technical skills and concentrate on general problem solving skills, learning skills, and team interaction skills.  Technical skills certainly still matter for long term positions, but you have plenty of time for the candidate to grow into some of the skills missing from your ideal profile.

Problem solving skills are extremely important for any candidate I interview.  I want to work with people who have certain degree of self-reliance.  Asking questions is always important, and something I value too, but the ability to solve a problem when there is no one there to help you can be extremely important too.  One of the questions I like to ask in this area involves handling vague requirements.  I want to know what a candidate will do if handed very vague requirements.  Will they probe for more information, or just try to make things up as they go along.  I like to ask the candidate how they would handle the following scenario:

A manager comes to you with the requirement to build a web page to collect a customers credit card information.  This is the only requirement you have been provided.  What would your next steps be?  How would you go about solving this problem?

I hope that the candidate will say that they would ask for more information.  Perhaps the candidate will suggest proposing more specific requirements to review with the manager/customer/end-user.

In addition, I like to ask candidates how they would solve a critical problem at 3 o’clock in the morning that has no easy solution.  Honestly, all I’m looking for on this question is what resources a candidate will turn to when there is not a readily available answer to the problem, and no one there to just provide a solution.  I want to know things like would the candidate go to Google, Stack Overflow, technical forums, etc. to help them in solving the problem.

Remember to ask fundamental questions of all candidates.  I like to ask questions about OOP like describe the difference between a class and an object, or between a class and a structure.  Another fair question is to ask about polymorphism.  Design patterns can be a good thing to throw out to the candidate to.  Design pattern knowledge helps establish whether a candidate is aware of common development techniques, and is willing to look at other ideas besides there own.  I also like to ask about the difference between a clustered and non-clustered index.  Asking questions involving string building can be useful too.  I like to ask a question about how you would build a string coming back from database records.  I’m trying to determine does the developer know that strings are immutable, and that they should be using a stringbuilder instead.  If I’m dealing ASP.Net developers I like to ask questions like how do you handle object state between web requests.  I try to keep the questions steered away from super nit-picky things that can be looked up on the internet anytime if you need it.  I’m more concerned with do you know these basic fundamentals that will help you in knowing what to look for online.

Finally in this area I like to know how candidates handle learning new technologies they have never worked with.  I have never worked on a project where I knew everything up front.  At my current client they have many technologies that no one locally has worked with so these learning skills become even more important.  Often times candidates say they will just look at the code and try to figure it out.  That can be a very dangerous answer with third party libraries that aren’t readily obvious in their use.  My hope is that the candidate would talk about finding tutorials on using the framework and online forums to help in learning the best practices.  The answers may be very similar to the question on handling the critical problem at 3 AM, but in a way that’s part of the point.  They should indicate similar skills.

The final area I like to emphasize in my interview questions involves the types of teams a candidate has worked on.  I want to know things like every project you’ve ever worked on has been 1 person projects.  This may be appropriate if I’ve got a small budget and can only afford one resource.  I might need somebody who can be completely self-reliant.  On the other hand, if I’m working on a large project that involves many people that same candidate may not as ideal.  They may just like to go solve every problem on their own, and be incapable of learning to work within the confines of a team.  I want to know is this candidate somebody who is used to having somebody direct them technically, and receiving quality assurance bugs that may or may not seem like criticism to them.

In the end, an effective technical interview should not have felt like a game show to either the interviewer or interviewee.  The best interviews should turn in to more of a conversation rather than a quiz.  Even in a technical interview you should strive to determine whether the candidate is somebody you have a rapport with.  In particular, if you are not the only person interviewing the candidate you may not know if other the other interviewers have covered any of these issues.  Candidates you hire are people you will have to work with for some time so you want to make sure they are more than just encyclopedias of knowledge.  You want to prove in the interview that they know what to do with that knowledge, and that they can work with you.

Welcome to the all new and improved TechTriumphs

Well, my blog has been down for awhile now.  I haven’t been really very good about keeping it up, and then my old blog engine got messed up.  I’ve now switched over to something a little more reliable.  I switched to WordPress.  I’m a software developer, but frankly I don’t feel like creating a blog-based website from scratch.  I would rather spend my time learning new technologies.  Anyway, to anybody who has tried to come to my site, I apologize for it being down for so long.

Code Reviews, do I really have to?

I have worked on many different teams, and code reviews have been mandatory on some, optional on others, and flat out not done on others.  In addition, code review as a term seems to have a very vague meaning that’s open to interpretation.  I would like to share some of my experiences with code reviews, and what some of the benefits are of them.

First off, let me share that I am a believer in code reviews done right.  I believe they are a fantastic tool for learning new techniques and sharing knowledge in a team when done right.  In addition, they tend to help produce higher quality code by being promoting proactive quality checks in performance, overall code quality, and potentially business logic.

So there are generally 2 styles of code reviews I’ve experienced.  Each has its own strengths and weakness.  The first style I will call “Delta Based Reviews”, which tends to be done more frequently on smaller chunks of code and tends to focus more on the quality aspects of review rather than the learning aspects.  The second style I will call “Presentation Based Reviews”, which tends to be more of a group exercise done less frequently.  This style tends focus more on the educational aspects of code review.   I will spend the rest of this blog discussing these 2 styles in more detail.

Delta based reviews can happen very frequently, and be performed by a single peer, or the entire team.  Delta based reviews utilize version control systems such as TFS, SVN, GIT, Mercurial, etc. to determine all of the code changes done in a branch, commit, or changeset.  The reviewer will select the appropriate unit from the version control system and review all of the changes to code made in this unit.  Reviewers typically disregard any unchanged code as irrelevant to the code review.  Typically the reviewer will look for any glaring bugs or performance issues in these reviews.  If the scope of the change is significant the reviewer may look into things like architecture and design to insure that the code is meeting minimal organizational standards, and provides appropriate levels of future maintainability.  These types of code reviews work as an excellent part of the quality assurance process.

If they are done on a frequent basis they can catch issues quickly while they are still on the developer’s mind before the code is ever deployed to other environments.  I have worked with these types of review at three levels of frequency: by release, once a week, and for every development feature an individual developer has worked on.  When these types of code reviews happen on a more frequent basis they become an invaluable tool in the quality assurance process.  However, they can also cause the reviewers to pay less attention in the review than they should if they are overburdened by too many code-reviews all the time.

The second style of code review, which I call the “Presentation Based Review” is based more on presenting new APIs, or new architectures to a team.  These reviews tend to be more aimed at educating a development team on new pieces of code that are available to the team.  However, they also provide the team with the ability to provide feedback to better optimize the APIs being presented to them.  These type of code reviews can also lead to review of the business functionality being provided, and can occasionally benefit from having a business analyst involved to provide feedback for questions that may arise during the review.

Presentation Based Reviews can also morph out of the “Delta Based Reviews” by providing a chance for code reviewers to discuss the results of their delta based reviews with the team.  One or two presenters may choose to discuss the results with the team to help them learn better performance and maintenance coding techniques.  Remember, the objective of this type of review is not to humiliate any single developer, it is to help the team as a whole learn and grow.  If possible try to hide the developer’s name whose code is being presented, unless they are ok with their name being used.

When code reviews are done right the provide a great mechanism to improve developer knowledge.  However, be careful not to turn code reviewing into a chore that must be done on a scheduled basis.  Also, do not force code reviews on to your team just for the sake of doing code reviews.  Teams that understand the benefits and objectives of code reviews have the opportunity for excellent growth.  There is more to gain from the collective wisdom of the group, and that is the ultimate objective of the review.