Why Hard Interviews are Good ?

I’ve never understood the shock people have of hiring a programmer and then finding out that he can’t actually write any code or that he completely lied on his resume.

This is a very simple problem that can easily be solved, yet not too many hiring managers or developers responsible for doing interviews are willing to do it.

All you have to do is increase the technical difficulty of the interview.

But I don’t want to ask hard questions, about a specific technology

Often I hear the point made that a good programmer can learn any framework or language, so asking difficult C# questions or asking details about EJBs will exclude those candidates prematurely.

While this statement is partially true, I don’t consider it a very good excuse for not asking hard questions.

There are many difficult subject matters in software engineering that exist beyond the domain of a specific language or technology.

You can always ask hard questions about object oriented design, design patterns, or general language constructs.

If you have the resources, you can always tailor the interview questions to the specific skill sets the candidate has indicated on their resume.

The truth is a really good programmer is going to know a lot about a lot of different areas.  A great programmer should also know a lot about some specific areas and languages.

What if all the candidates fail?

They all should fail.

Your technical interview should get increasingly harder, until it ultimately results in stumping the candidate.

Make your questions progressively more difficult until you reach an area beyond the knowledge of anyone on your team.  If you ever have a candidate that makes it that far, you know they are an instant hire.

You expect that no one will make it all the way through, and that is good.  It gives you a very real and easy comparison gauge on the different candidates.

Not that you should base your decision on how many interview questions the candidate gets right, but it can definitely provide you a comparison of two candidates that you wouldn’t be able to see without escalating difficulty questions.

For example, if candidate A can only get through the basic questions and candidate B makes it to the expert level questions, that should give you a pretty good idea of their relative talents.

Besides, failing is good.  We all fail every day.  I always want to see what a person is going to do when they don’t know the answer.  Do they have the humility to ask you the answer so that they will know it in the future?  Do they bring up that they will research that area?  Do they blow up and make excuses or try to justify a wrong answer?

I hate hard interviews, so I don’t want to give them out

Do you really hate difficult interviews?

Or do you hate pointlessly difficult interviews?  There is a huge difference.

Asking someone to use bit manipulation to reverse a string is stupid and pointless.

In most cases, asking someone to implement a quick sort algorithm is also stupid and pointless.  (Any programmer worth his salt would never trust himself to implement a well known sorting algorithm, and would instead look it up.)

My point is that there is a big difference between asking hard questions and good hard questions.  If you ask relevant hard questions, you are going to quickly turn away the “fakers” and “con artists” and you are actually going to make a good programmer pretty happy.

Nothing I hate worse than walking out of an interview, as the interviewee, feeling like the interviewer didn’t ask me hard enough questions.

I feel like if an interviewer asks me easy questions that anyone should know, I don’t get to demonstrate my real skills and talent.  When I leave an interview, I want the interviewer to think.  “Damn, that guy got almost every single hard question right, no one else was able to do that.”

So in reality, if you ask good hard questions, people won’t resent you for it, they will appreciate it.  It is nice to “slam dunk” a difficult interview, because you know that you likely have the job.  It is not nice to “slam dunk” an easy interview, because it doesn’t give you any confidence that your skillset was noticed at all.

Don’t forget to have them write code

Programmers should be able to write code.  In a high stress situation, it might not be pretty, and it might not be absolutely semantically correct, but it should be obvious that the candidate knows how to write code.

The best approach I found is to use a simple programming problem.  A problem that anyone should be able to solve, but can be solved many different ways.

The idea is that the code should be what you are looking for, not if they can solve a difficult logic problem.

I’m pretty happy to say that the company where I work now, TrackAbout, has a pretty difficult interview process which does involve writing code.  I am very happy about this, because I feel that it allows us to hire the best programmer, which allows me to work with the best programmers.

If your company is taking the easy way out of doing technical interviews, you are basically playing the programmer lottery.  It is definitely worth a little more time to ask harder questions and be a lot more confident
in your decisions.

Simpleprogarmmer.com