28

I realize there have been lots of discussions about this type of thing and they often devolve into dogma around whether you ask the "100 logical pirates" type of questions or whether you get them to write "fizz buzz".

I'm interested in what techniques and questions have been effective for you when interviewing potential developers for jobs.

One technique per answer so we can vote on them, please.

yannis
  • 39,547
  • 40
  • 183
  • 216
Paddyslacker
  • 11,070
  • 5
  • 55
  • 65

7 Answers7

21

Besides real technical questions, and typically at the end of the interview I try to get a grasp of their level of interest in the industry and it's culture with questions like:

  • Have you seen anything recently programming-related that you found interesting and would like to recommend to other fellow programmers? A new language, tool, platform, technique, website?

  • Can you name any well known person in our industry whose work you like or find inspiring and why? (developer, web site founder, author, speaker, etc)

  • What are you reading now or what was the last software related book you read?

  • What programming related sites do you frequent?

Although failing to answer these questions at all (sadly it happens very frequently) does not mean a 'no-hire' to me, they say a lot about the way a person approaches the software development profession.

Sergio Acosta
  • 9,568
  • 3
  • 25
  • 36
  • 4
    I'd probably go as far as to say that this is the most important thing to gauge in any software interview. You could argue that writing code is more important, but people who covered something similar recently or at university can guess their way through it, whereas it's very hard to fake real, genuine interest. – Mike B Sep 21 '10 at 11:47
  • 5
    I'm not surprised that this is a popular answer on this website. The audience here is by definition one that values the "programmer culture". (I agree with the answer, but have met several excellent programmers who would fail this test, especially ones in the over 40 crowd) – AShelly Sep 21 '10 at 14:26
  • 2
    @AShelly: Yes, I agree. That's why I don't consider this question essential to reject or accept a programmer. It is just another technique you can use while interviewing. – Sergio Acosta Sep 21 '10 at 20:37
16

Make them write code, real code.

The interviewer may let you pick the programming language you are most comfortable with, be it C++, Java, C# or whatever and ask you to solve a simple problem, e.g. doing some work with a string or a doubly linked list or whatever. If you have trouble using your best language solving a simple problem then there is a problem. Please see Steve Yegge's blog post and especially the section "Mental Prep".

grokus
  • 7,536
  • 4
  • 31
  • 46
  • 6
    Yes, but not too much of it. – Damovisa Sep 02 '10 at 22:55
  • Writing real code will help you get in the doors of elite software companies (Google, Amazon, Microsoft, ... ) and feel free to pick the rest. – grokus Sep 03 '10 at 15:14
  • 3
    Please elaborate on your answer. What do you mean by "real" code? What code isn't "real"? – MAK Sep 20 '10 at 20:48
  • +1 @MAK: Agreed, what's real code? If it's code that you would intend to use in your production software... – Steven Evers Sep 20 '10 at 21:59
  • 1
    I would consider 'real code' something like asking the interviewee to write a 'strdup()' function. It has real use and exposes their experience and attitudes to things like memory management and error handling. – JBRWilkinson Sep 20 '10 at 23:14
  • @MAK, typically in such interviews, the interviewer let you pick the programming language you are most comfortable with, be it C++, Java, C# or whatever and ask you to solve a simple problem, e.g. doing some work with a string or a doubly linked list or whatever. If you have trouble using your best language solving a simple problem then there is a problem. Please see Steve Yegge's blog post and especially the section "Mental Prep". http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html – grokus Sep 20 '10 at 23:38
  • @grokus: I agree. Please edit your answer to include this. I originally commented on this because different people might interpret "real code" to mean different things (e.g. code not pseudocode/algorithm, or code out of a real-life application as opposed to fizzbuzz or similar puzzles). – MAK Sep 21 '10 at 06:16
11

Have several people from your team interview them independently. Share your thoughts after, don't talk in between before interviewing them. Talking in between will sway your judgement and you won't have independent assesements.

For the technical people interviewing them make them write code. For non technical, don't try to ask things you aren't experienced with. Make sure you have at least some technical people interviewing though.

Interviews should not be conducted only by managers, it should be extremely important to every worker who they will work with in the future.

Brian R. Bondy
  • 7,067
  • 32
  • 53
  • 2
    +1 for "interviews should not be conducted only by managers". If the new hire can't cut code as well as their colleagues, there'll be unrest among the team. – JBRWilkinson Sep 20 '10 at 23:15
7

I like to have an interviewee explain their previous projects and what they did. From this answer I can have followup questions: why they did things a certain way, how did they solve a particular problem if they mentioned one, but most importantly what was the purpose of the project and what business problem this solved.

I do this to see if they can articulate in a way that makes me understand what they were doing, and see if they understood what they were doing as well.

It's surprising that the last question about the purpose of the project and the business problem solved that trips a lot of people up. They have no idea WHY the project they were working on was being done at all. If you don't know why your project exists in the first place, it makes me wonder if you are contributing solutions, or just doing as you are told.

(Figured I throw this one in there, since all the other answers tend to be technical. I want people that know why they are solving the problems they are solving too, otherwise, they tend to solve the wrong problems that the end user doesn't care about :)

Jay
  • 1,901
  • 13
  • 15
6

Ask their take on an important architectural decision

For example. Here is program x that runs y number of subtasks concurrently. Which would you choose, a multi-process or threading structure.

What are the benefits/disadvantages of both. How well would they work and how could they be used to leverage a multi-core, multi-processor platform, what is your personal preference? Personal biases can aid in identifying whether they've ever had to actually apply the knowledge and give them a jump point to share their experiences?

There are tons of questions an interviewer could come up with like these:

  • TCP or UDP?
  • Dynamic or Statically typed language?
  • Monolithic application or multiple smaller applications?
  • What would you use for Interprocess Communication?
  • Stored Procedures or ORM?

Most of these topics are the types that involve an intimate knowledge of how/why a computer system works the way it does. They all are issues/solutions to problems that have no definite answer so they give a sense of how well that person is able to adapt or overcome the challenges at hand. Not the type of concepts that can be easily picked up without some actual hands on experience.

Note: Having the applicant write some pesudo code is a must too but that answer is already taken.

Evan Plaice
  • 5,725
  • 2
  • 24
  • 34
  • The one caveat I'd add to this is to make sure the question isn't domain-specific to the company doing the interviewing. – JBRWilkinson Sep 20 '10 at 23:18
1

Just give them some basic code to do on whiteboard - e.g. linked list implementation, sorting or something similar.

You can judge how comfortable are they with their language without help of compiler and you can judge their thought process (especially if they never implemented such thing - most of "new" programmers never did).

Josip Medved
  • 1,118
  • 7
  • 8
  • 8
    I disagree. Linked lists and sorting are both pretty well known canned issues to a common problem. Anybody who has written one knows how they work but most people don't bother with writing their own because most languages do a good job of it already. – Evan Plaice Sep 11 '10 at 22:30
  • I agree with Evan. In practice it's often sufficient to be aware of the performance of different sorting/search algorithms and basic data structures. Knowing how to implement them is neat, but ultimately useless. Also, in most programming jobs it's more important to know how to pick the right framework/library for the task than how to implement QuickSort in under three lines. – Alan Plum Sep 21 '10 at 16:38
0

Have a conversation, let it drift and meander along the technical and professional route and look for insightful or stupid comments along the way. This gets you 3/4 of what you need from an interview, an assessment of: people skills and personality, general intelligence, and a rough assessment of technical skills.

Use your interview "questions" as topic starters and for keeping the conversation corralled to technical topics - you may need to reset the conversation from time to time (such as doing a coding exercise) to adequately probe areas of concern/interest.

The real trick to this technique is to make sure they do all the talking, otherwise you run the risk of a favorable evaluation because they made you feel smart by listening to/agreeing with everything you said.

Mark Brackett
  • 627
  • 6
  • 6