Advertisements
Posted by: jsonmez | October 6, 2010

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.

stumped

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.

Advertisements

Responses

  1. I have been prepping for an interview later this week and I have been using this blog post as a guide: http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html

    He hits on several of the points you make and stresses that there are two main things to look for in a canidate. They need to be smart and gets things done.

  2. There’s something worse about slam-dunking an easy interview. If you get offered a job, how do you know if you should take it or not? If anyone that can pass that interview can work there, it’s probably not the place for you.

    A good interview question I once had (ages ago, so I don’t remember the details):
    – Have you ever heard of language X?
    – Yes, but I haven’t used it.
    – Good, we’re looking for languages nobody uses. Here’s a quick guide to it. Write this simple program. I’ll be back in 15 minutes.

    I then asked some technical questions about string handling in that language – the interviewer didn’t really know it either. But he knew enough to see if my code is good, and he knew enough to see that my program worked properly with edge cases. And he could see that I have the most important skill – learning ability.

    • I like that. That is an interesting approach. You are right about not knowing about taking it. I definitely have turned down a job or two in the past simply because I didn’t trust the work environment based on the simplicity of the interview questions.

  3. Do you also make the candidate write code if you’re short on time? If so, how do you set that up without it taking up a too big part of the interview?

    I find that in one hour interviews I can touch on more subjects if I leave out the bit about actual coding, and then make a good enough judgement about the candidate’s programming skills based on questions like you mention: “.. hard questions about object oriented design, design patterns, or general language constructs.”

    • I agree with you. I can usually make a pretty good judgement by asking hard questions.
      It definitely is nice, if you can at least get some coding during the interview.

      If you have to power the make it so, it is good to ask for an extra hour to get that time. Hiring a programmer should be worth expending one additional hour. It is a pretty large investment which have a huge variable rate of return.

  4. […] talked about how I think having code in an interview is a good thing before, but now the numbers are here to back me […]

  5. Maybe all companies should simply use Google’s programmer interviewing technique. Present problems that only someone with a post-doctoral in math can answer. It’s hilarious that your entire blog has no articles that really require math skills beyond 2+2, yet many interviews for serious programmers require huge math skills. I’d like to see you write an efficient multi-branch-predicting algorithm for a processor, or a caching algorithm for a hard drive. Your blog contains nothing harder than the average janitor who read a few programming books can do, yet you suggest companies should be rigorous in their testing and look for the best of the best, which I have no doubt you yourself would fail such a test and not be hired. Bah ha haa haa.

  6. […] and Pluralsight videos are relatively easy topics, but that I had hypocritically suggested that interviews should be hard and should be designed for “real programmers” or super […]

  7. […] 邮件的作者基本上认为我在博客里和Pluralsight视频节目里谈论的都是非常浅显的话题,但发现我却虚伪的倡议面试内容应该设计的复杂些,应该为“真正的程序员”或超级程序员而设计。 […]

  8. […] 邮件的作者基本上认为我在博客里和Pluralsight视频节目里谈论的都是非常浅显的话题,但发现我却虚伪的倡议面试内容应该设计的复杂些,应该为“真正的程序员”或超级程序员而设计。 […]

  9. […] 邮件的作者基本上认为我在博客里和Pluralsight视频节目里谈论的都是非常浅显的话题,但发现我却虚伪的倡议面试内容应该设计的复杂些,应该为“真正的程序员”或超级程序员而设计。 […]

  10. […] 邮件的作者基本上认为我在博客里和Pluralsight视频节目里谈论的都是非常浅显的话题,但发现我却虚伪的倡议面试内容应该设计的复杂些,应该为“真正的程序员”或超级程序员而设计。 […]

  11. […] 邮件的作者基本上认为我在博客里和Pluralsight视频节目里谈论的都是非常浅显的话题,但发现我却虚伪的倡议面试内容应该设计的复杂些,应该为“真正的程序员”或超级程序员而设计。 […]

  12. […] 邮件的作者基本上认为我在博客里和Pluralsight视频节目里谈论的都是非常浅显的话题,但发现我却虚伪的倡议面试内容应该设计的复杂些,应该为“真正的程序员”或超级程序员而设计。 […]

  13. […] 邮件的作者基本上认为我在博客里和Pluralsight视频节目里谈论的都是非常浅显的话题,但发现我却虚伪的倡议面试内容应该设计的复杂些,应该为“真正的程序员”或超级程序员而设计。 […]

  14. […] 邮件的作者基本上认为我在博客里和Pluralsight视频节目里谈论的都是非常浅显的话题,但发现我却虚伪的倡议面试内容应该设计的复杂些,应该为“真正的程序员”或超级程序员而设计。 […]

  15. […] 邮件的作者基本上认为我在博客里和Pluralsight视频节目里谈论的都是非常浅显的话题,但发现我却虚伪的倡议面试内容应该设计的复杂些,应该为“真正的程序员”或超级程序员而设计。 […]

  16. […] 邮件的作者基本上认为我在博客里和Pluralsight视频节目里谈论的都是非常浅显的话题,但发现我却虚伪的倡议面试内容应该设计的复杂些,应该为“真正的程序员”或超级程序员而设计。 […]

  17. […] and Pluralsight videos are relatively easy topics, but that I had hypocritically suggested that interviews should be hard and should be designed for “real programmers” or super […]

  18. […] talked about why hard interviews are good and part of the reason is because they test a developer’s ability to solve […]

  19. […] 我谈过为何有难度的面试挺好,而其中的部分原因在于,面试官就是要测试开发者解决问题的能力。 […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: