Take the 2-minute tour ×

What questions will validly judge an individuals skills as a programmer? These should be applicable to a programmer using any language, and they should be aimed at entry level positions possibly questioning a recent graduate.

We're all aware of the various types of questions that interviewers ask, but specifically, which ones most effectively assess the real performance of an employee on the job?

share|improve this question



12 Answers 12

up vote 28 down vote accepted

Explain a linked list to a 10 year old.
Explain OOP to someone who doesn't know anything about programming.

Being able to communicate is important in most jobs. Programmers have the difficult task of explaining complex technical concepts to non-technical people. Questions like this test (to some degree) an applicant's ability to do that.

share|improve this answer
+1. That's a really good one! If you understand the concept, you can explain it even to your granny who has never touched the keyboard :) –  Yan Sklyarenko Oct 26 '10 at 6:45
My first thought about the linked list: it's like your Thomas the Tank Engine train set, you can add and remove the trucks from the train and each truck holds some stuff and it has a front and a back. I don't think I'd have thought of that without actually having kids. –  Skizz Oct 26 '10 at 8:58
@Skizz: How do you explain O(n) lookup time? –  intuited Oct 26 '10 at 9:26
I would go with the "iterative scavenger hunt" metaphor on this one.. you know, where you have to read page 496 of the directory in the phone booth on 4th and Park, which leads you to the menu in the restaurant by the stadium, ... –  intuited Oct 26 '10 at 9:28
These are interesting, but hardly seem like they would tell you who is a good programmer or not. Linked lists? OOP? A first-year student should be able to answer both of those. Even though this is "for entry-level position", do you really want to hire someone who only knows these two things, one of which is only a concept? I see your answer was accepted, but the OP is asking, "which ones most effectively assess the real performance of an employee on the job?" –  Mark C Nov 1 '10 at 4:55

Give them a computer, a text editor and ask them to write some code in a suitable language that performs a common function like strstr()/string.IndexOf(str), itoa()/int.toString(). You choose - best to have a number of options if a newbie isn't familiar with the function.

Leave them alone for a few minutes to do this. The language doesn't really matter - something appropriate will do, as long as no library calls (at all). It doesn't have to compile and run - but you could do this together when they're done, just for kicks. Obviously, no access to the web for this exercise.

This should demonstrate:

  1. Can the candidate write code at all.
  2. Can solve programming/algorithmic problems. If they're nowhere near a reasonable solution, no point in continuing the interview.
  3. Do they write maintainable code? Do they demonstrate an understanding that other team members might adapt their code?
  4. Is there any consistent style to the coding? It doesn't have to match your in-house style, but do they write consistently-styled code that is easy to read.
  5. Can they talk through their code? Do they get too defensive when you critique it? How do they respond to feedback?

Using this technique I have identified:

  • Candidates that can talk their way through the interview and then crumble when asked to write code.
  • Candidates that bought in print outs of someone else's code as an example of their own work.
  • High-scoring graduates that couldn't get their head around an 'isUpperCase(char)' function.
  • A guy who got aggressive and then then threatened the HR person and I who were interviewing him once we started to work through his code, giving him feedback on different approaches.
share|improve this answer
Bingo. Ask them to write code. This is the real litmus test. Plus, you get to really see how they think and solve problems. –  Chris Holmes Oct 26 '10 at 13:20
#5 - Excellent interviewing point! –  Adamizer Oct 26 '10 at 16:42
IMO making write code on the spot is about the worst thing you could do on the interview. Even if you really look for a coding monkey instead of a software engineer, I suggest to give fragments of your code for code review. Provides way more information with less time and frustration. –  Balog Pal Jun 1 '13 at 17:57

There's a really simple one that is sure to do the trick...

Ask the candidate about their previous projects.

Make the interview more of a conversation, and less like the SAT's.

Ask them what they did. Describe the parts of the project they worked on. Their responsibilities. Use follow ups to ask about what technologies were used and why they were selected. How code was arranged. How they tested. Design mistakes and what they'd do differently. Basically, learn why they made the decisions they made.

If a competent programmer is doing the interview it is very easy to separate the candidates who know what they are doing from the buzzword shoveling posers.

share|improve this answer
What if he s a fresher ??? –  GoodSp33d Oct 26 '10 at 5:47
Even a new programmer should've had a couple of private projects going on, so that won't be a problem. And if the candidate has no projects to speak about, then the candidate has a problem :) –  Martin Söderlund Oct 26 '10 at 6:25
+1 i will add to this: check references, always –  user2567 Oct 26 '10 at 7:09
I recently interviewed a guy who spoke with great authority about an iPhone app he'd written for his university campus. Sounded great - we talked through XCode, Interface Builder, Objective-C, etc. Only when we followed up his references did it become clear that this was a module on the course. –  JBRWilkinson Oct 26 '10 at 9:31
I find this to be quite an inefficent approach. You end up having to constantly dig into which bits of the project the candidate actually worked on and which bits they just had to tell you about so you could understand the design decisions they actually made. It also means that with some unlucky candidates you have to constantly ask, "well, if you weren't forced by your employer to do it that way, how would you have done it?". –  flamingpenguin Oct 26 '10 at 11:22


From CodingHorror, originally from Imran on Tech:


When I first read the claim that over 99% of applicants to the average programming job can't complete this, I honestly didn't believe it. I ended up working at a small company that asked me this question, though, and talked with the CEO later; he told me that those statistics hold true.

As such, this is a great question to weed out a large chunk of applicants. It's short enough to make them do it on paper if that's all you have, and simple enough that a college kid should be able to code it after their first intro to programming course.

share|improve this answer
If an agency-referred candidate fails this, find another agency. –  JBRWilkinson Nov 1 '10 at 12:40
@JBRWilkinson - Then you'll very quickly run out of agencies! I'd love to know which agencies genuinely check and assess their candidates real skills (rather than just keyword searching through the CV). –  CraigTP Nov 3 '10 at 9:32
A decent agency will interview the candidate to identify their strengths. If they put forward too many inappropriate candidates, the agent would lose the clients as they're not doing an effective job. I've whittled the selection of agents down to just two as they've provided the best candidates (many of which we've hired) - they filtered out all the ones that would not fit the role. Keyword matching can be done by automated job sites - no need for an agent to do that simple task. –  JBRWilkinson Nov 4 '10 at 10:28
All this really says is that they've used the Modulus operator to find the remainder (which needs to be 0 for each check in question). I've used it probably 5 times in 4 years. –  The Muffin Man Dec 7 '12 at 3:56

Design a hotel registration system.

The question is intentionally vague, since the point is to test the candidate's requirements elicitation abilities. Figuring out what a customer wants is non-trivial. So, the candidate that does well starts out by asking a pile of questions: "Ok, what functions does it need?" "What is your process like before this system?" "What types of users will be using it?" etc, to which the interviewer can make up and/or have prepared answers.

A good candidate:

  • Avoids making assumptions about functionality, technical resources, users, etc
  • Doesn't talk about specifics of implementation, but just what it needs to do.
  • Asks good questions to draw out information.
share|improve this answer

A very interesting question and I am eager to see the answers to this. I think most of the times Puzzles/Algorithms and language knowledge are overrated.

  1. Also the concept, I want to see how a candidate ATTACK's a problem is also overrated. Most Interviewers also say that if you have already solved this problem let us know so that we can give you another problem because all we are interested in is your approach. This is Bullshit. For eg. Ask yourself the first time you wrote a Program to write all possible permutations of a word recursively, how much time did it take ? 20 min, 30 mins ?? I bet a correct program took more than that,So if you are doing it for the first time in an interview and taking 30 mins to do it, I bet MOST Interviewers will run out of patience. What can be tested out of these puzzle questions is that whether someone knows these type of questions or not, someone who knows/practised these questions will be able to solve similar problems in Projects if needed. So in some cases if someone is not able to solve such problems doesn't mean he is NOT SMART he might not have practised enough.

  2. Language concepts ? In my opinion these can be applied to most general concepts. If someone doesn't know an obscure concept in a language doesn't mean he is not good enough. If he knows the most popular concepts, let him in.

  3. Approach ? how do you judge it ? What if someone is faking it ? For eg. it is not uncommon to see many guys in an Interview not being able to solve problems but when you want to move to something else, they have that AHA moment and seem to solve it instantly :) Also the smart programmers will always first give O(n^2) solution and then will keep on thinking and then give the O(n) solution, Most of the times they know both on the first hand they are clever enough to show that they are thinking through it :-)

I generally ask people to solve known or similar problems and ask them to write the code. I am mostly interested in how the Code looks at the end of the problem. Correctness of the solution/code quality/corner cases/ exception handling/ null references etc are what I look at. Sometimes I dont even mind telling the O(n) solution :-) the code is what matters to me. Also I like people who have a breadth of knowledge, these are guys who have been READING they will be able to research various technologies for you and come up with the best thing for the Project. Just my opinions though may be you hire a Mainframe guy differently.

share|improve this answer
I'll admit that I'm guilty of faking it. One good interviewer tripped me up by having several extensions to the problem on hand. :) –  Fishtoaster Oct 26 '10 at 4:37
@Fish Faking "not" being able to do it? Why on earth would someone do that, are they trying to impress poor interviewers? –  Mark C Nov 1 '10 at 5:10
Eh, it was more a case where I knew the answer off the top of my head from having read it online, but I wanted to look like I was able to think it up off the top of my head. Kinda silly. –  Fishtoaster Nov 1 '10 at 6:02
@Fish : Atleast you are being honest on the forum :-) but seriously this is a much more common trick than people expect it to be. More so common in the MS kinda interviews where on the spot innovation is rewarded :P –  Geek Nov 2 '10 at 15:49

One test I had which worked quite well was to given, on hard copy, a small program and the task was to determine the output of the program. The program implemented a linked list, added a set of values to the list then traversed the list outputing the values of each node. The catch was that the linked list implementation didn't behave in the standard way, it added new items to the front of the list so that traversing the list would output the values in a different order to the order they were added.

This would sort out people who can really read and understand code from those who jump to conclusions.

Needless to say, it didn't catch me out as I used the boxes-and-arrows method to track the behaviour of the linked list.

share|improve this answer
Do you get bonus points for the answer "impossible to tell, due to the errors here, here and there"? –  Bart van Ingen Schenau Oct 26 '10 at 11:10

Given a linked list with a loop in it, how would you measure the length of the 'stem'- the part before the loop starts?

This could really be replaced with any algorithmic question. What it needs is:

  • It can't be one with a well known solution (eg, how do you detect a cycle in a linked list)
  • It can't be too complex to do in an interview (eg, Facebook's Puzzles)
  • It should have a few different solutions of varying complexity (this one can get down to constant space, linear time).

The point is to see how the candidate attacks the problem and thinks through it. Realistically, very few programming jobs (in my experience) really require much algorithmic analysis; rather, it's there to see if the person doesn't give up, and can keep finding new avenues to explore. Even if they don't get the question, do you think they'd get it eventually, or would they say "That's the best I can do- I'm stumped?"

share|improve this answer
Thank you for your response. –  JoshD Oct 26 '10 at 2:14
I'd be curious to know the second half of the answer to this question. I know how to find if there is a loop (tortise/hare) but how do you identify the "stem"? You can't assume the point at which they meet is the first node in the loop, so how would you go about finding it? –  jkinz Aug 5 '13 at 17:46

One question I have found very revealing for entry level is to ask the candidate to implement a blocking queue of objects.

I always try to get them to do it on paper. It can be in the language of their choice (or one of the languages they claim to know, or pseudo code, depending what want). This way less time is wasted on the syntax or exact names of the language/api features and more is focused on the choice of algorithm. They can even invent their own language features to allow them to do it if they can't remember.

I realise it is a textbook question, but we are usually recruiting people who will have to work on code with large amounts of concurrency. I have generally found that most people that cannot answer effectively also cannot answer the other more advanced and in-depth questions about how to deal with concurrency.

share|improve this answer

How would you solve a problem you've hit a brick wall with.

Every programmer every now and again doing interesting work will hit a wall with something that goes beyond their experience and ability to independently think around, a decent programmer will have come across this and know how to deal with it.

Asking a coworker is the first and best answer but must be backed up by follow-ups like, MSDN/PHP Docs or whatever the authoritative documentation for your language/framework is, stackoverflow, MSN to old colleagues, twitter - the more the better.

I always ask this one and it gives good insight.

share|improve this answer

My favorite question to ask is "What are you passionate about?" or "What do you do in your spare time?". It doesn't have to be technology, programming, or software development. To know they have or are capable of being passionate is something that I have seen time and again that separates the great developers from the rest. The people who go to work to earn a pay check do not generally have much to fall back on here and can't fake it. The people who generally have something they are passionate about are very excited to tell you all about it.

share|improve this answer

I take real problems we had in the code and ask them in the interview. This way I have before and after code, it's already worked out and it's typical.

If you can solve the sort of problems we run into in an interview, it's a dead certainty you can do it every day.

This presupposes you have a bug tracking system tied to your VCS and make sensible commit comments; which we might term "wearing pants" in a work context.

share|improve this answer
