Why Hard Developer 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 developer 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 developer 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 a developer 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 a developer 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 developer 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.

About the author

John Sonmez

John Sonmez is the founder of Simple Programmer and a life coach for software developers. He is the best selling author of the book "Soft Skills: The Software Developer's Life Manual."

  • http://www.bryan-weaver.com Bryan

    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.

  • configurator

    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.

    • http://simpleprogrammer.com jsonmez

      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.

  • Christian H. Mosveen

    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.”

    • http://simpleprogrammer.com jsonmez

      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.

  • Pingback: Solving Problems, You Better Learn How « Making the Complex Simple()

  • Joe Programmer

    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.

  • Pingback: The Myth of the Super Programmer « Making the Complex Simple()

  • Pingback: 超级程序员神话 – WHO1753()

  • Pingback: 【外刊IT评论网】超级程序员神话 | 吃杂烩()

  • Pingback: 【外刊IT评论网】超级程序员神话 | 乐无忧()

  • Pingback: 超级程序员神话 - 博客 - 伯乐在线()

  • Pingback: 超级程序员神话 | 吃杂烩()

  • Pingback: 超级程序员神话 « T客网 ︱ Techpot()

  • Pingback: 超级程序员神话 | EvilCode 邪恶代码()

  • Pingback: 乐无忧 / 【外刊IT评论网】超级程序员神话()

  • Pingback: Scott » 转:超级程序员神话()

  • Pingback: 超级程序员神话 | zlmind个人博客()

  • Pingback: The Myth of the Super Programmer « Jelastic — Rock-Solid Java in the Cloud, Java Server Hosting, Java Cloud Computing()

  • Pingback: The 4 Most Important Skills for a Software Developer « Making the Complex Simple()

  • Pingback: 软件开发者的四大“看家本事” | 博客 - 伯乐在线()

  • Pingback: 超级程序员神话 | 许大虾()

  • Pingback: Why Hard Developer Interviews are Good | Let's update latest IT news and technology()

  • Buck Swayne

    If you want to test a coder’s ability, give them a project and a deadline. See what they produce. Let them do this off-line, interview for everything else that matters in-person: collaboration, style, opinions, history, challenges, weaknesses, strengths.

    It makes no sense to ‘interview’ with a coding question. It is unnatural to solve problems this way. Instead of working at a whiteboard. Developers should probably be sitting, using their preferred text editor with a big monitor, with the internet available to search, with a computer where they can test their code, using open-source or third party libraries if that’s allowed, given a reasonable amount of time, allowed to implement it in the way they know is the right way. And, if there are people in the room, it should be collaborative, not critical and/or silent. It’s pretty bizarre to interview this way. It’s exactly opposed to an introvert’s preferred environment, perfectly disrupting the person you are trying to hire.

  • Edis

    At my very first job interview I had a very easy questions for a very senior position. I passed, but later I was in difficult situation, expected to solve much harder problems then the one on the interview.

  • Pingback: How to be a good software developer ? | hariomvibhute()

  • Pingback: Most Important skills for a software Developer | All IT books()