Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We had a debate a few days ago at work about some question we ask during interviews.

We are in the on-going process of hiring "junior" C++ developers which is kind-of new to the company (we used to hire only experienced programmers, but those are hard to find in our geographical area).

For more experienced applicants, we usually ask C++ questions, some code reading exercises and inheritance, cast, const-correctness, static questions. The goal being to check if the applicant has enough experience with the language (if somebody claims he has 6 years of experience with C++ but can't write a const getter, then something is wrong for instance).

But for "junior" applicants, those kind of questions don't seem relevant: obviously junior people can't possibly know about all the features of a language, and it is expected of them that they will need some learning time.

I thought of asking a question like:

"Say you are a given a list of millions of integers. Write some function that computes the average of the numbers."

Obviously the main goal of this question isn't to get a perfect solution but to see how the applicant think. First he should ask about the list:

  • How are the numbers organized ?
  • Are they sorted ?
  • Where do the numbers come from ? A file ? Some network socket ?
  • Do we know the count of items beforehand ?

Then I expect him/her to raise several problems:

  • The sum of the integers will likely overflow.
  • Do we need an exact average or something close-enough will do ?
  • What if the list is empty ?
  • ...and so on.

Obviously, if the applicant doesn't know what classes, functions to use I tell him/her: he/she could get that information on the Internet in a real situation anyway.

Now, some of my coworkers think that is a terrible question because it is vague and open, claiming that "junior" applicants are stressed during interviews and can't think properly, making the test moot. I can see their point, but I still don't agree.

So my questions are: is this kind of question acceptable for testing "junior" applicants ? What makes a good "junior" interview question ?

share|improve this question

closed as primarily opinion-based by gnat, Bart van Ingen Schenau, amon, MichaelT, GlenH7 Apr 4 '14 at 13:33

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

How are the numbers organized ? Presumably you mean the collection type; and you already told us: it's a list. Are they sorted ? Would that matter if the job is to calculate an average? Where do the numbers come from ? A file ? Some network socket ? Surely a function to calculate an average shouldn't care where the numbers come from. What if the list is empty ? We already know it isn't - the question clearly states that we're given a list of millions of integers –  Kai Apr 4 '14 at 8:49
@Kai: Those are example questions. The sorting may or may not be relevant. It is not because you don't see why it matters that it does not. Again the source matters: you may or may not be able to re-read the list should you need too, and it won't likely fit in memory so this is a real concern. The question is vague on purpose: it is expected that you ask for clarifications. Also, if you are not concerned about the possibility for the list to be empty (and the likelihood of a divide by zero risk that comes with it), that's a terrible thing. –  ereOn Apr 4 '14 at 8:55
I get what you're asking and what you are after, but it does seem an overly simplified question on the face of it - you might find the candidates need a bit of leading (but as soon as you do they'll jump right on it). –  Mr Shoubs Apr 4 '14 at 9:04
@ereOn Then it could stand to be a bit more vague if you want candidates (inexperienced candidates at that) to not latch on to what appear to be concrete facts in the question and question the details - tell a junior dev that they have a list of things and they're going to assume it's literally a pre-populated List. For example, Write some function that computes the average of any number of integers –  Kai Apr 4 '14 at 9:08
@ereOn Consider your audience - a more battle-hardened dev is likely to question it. A junior dev, being asked the question by a more senior dev, is likely to assume that the word "list" refers to std::list. If I were the candidate, my thoughts would be much closer "oh hey, this experienced developer said 'list', I know what a std::list is and I can impress him here by using one of those correctly and efficiently" than "hey, this senior dev said list but maybe he means something else." I may even think it would look bad to appear to have not noticed the word "List" in the question. –  Kai Apr 4 '14 at 9:54

3 Answers 3

up vote 2 down vote accepted

I think one of the best interview questions is to ask the junior to speak about previous programming projects he has done, in any language he used. There is several things you will look for :

  • His/her ability to sum up, to make complex things look simple, meaning he/she has a good grasp about what the program do
  • His/her involvement in the process, his/her relationship with co-workers
  • Technical details, like how code was organized (class hierarchy etc), what algorithms were used

As you said, when filtering experienced programmers you will look for specific technical expertise and thus specific questions are appropriate. For juniors, if you ask them more generally what is their development experience and what they understand from it, you will have a better view about their general dev skills and where you can go from there.

As a bonus, it will be much easier for them to speak about something they know about (themselves) rather than an exercise which will naturally look like a trick question and block their creativity.

Naturally, this is a very general advice and may or may not apply specifically to the profile you are looking for, but digging deeper "what makes a junior applicant good" is the true question and calls for different specific answers.

share|improve this answer
+1 - I only gave an answer to add a little more to this fundamental idea. –  JeffO Apr 4 '14 at 12:43

You're on the right path in the case of junior devs. Look more for aptitude/talent than just skills, but that has to be combined with a work ethic and willingness to learn. The questions and tasks you'll give them should reflect this not only in the answers they give, but how they go about doing the work.

FOR ALL THAT IS HOLY, PLEASE SIT IN FRONT OF A COMPUTER AND WRITE SOME CODE!!!! Being able to answer trivia questions and explain things is a minor part of the job. Focus on the most important part, writing code at a computer. If you want to be a programmer, you have to be comfortable at the keyboard.

You can ask questions at the computer. Start with a block of code as an example; demonstrate some things about your IDE if they are not familiar with it. Explain a few simple things and see if the candidate can pick up on some others. Ask them to make some small modifications. The key here is to see if they start to get it or are they just completely over-whelmed and clueless. How interested are they in trying something on their own? Think of something they'll be building; ask them to try it.

Broader design and structure questions are probably better suited to do at the whiteboard. Part of this could be for the candidate to explain a previous project. Then ask them to design something that is typical on one of your projects.

Look for people willing to "try" and see who will persevere. Ask if they've ever stayed up all night working on something. This is going to show you who is going to take pride in getting things done and has some semblance of a work ethic. That will go a long way with a junior dev. Someone who just sits there and waits to be told what to do every 5 minutes is going to drag your team down just as much as a junior who thinks he knows everything and is not willing to take instruction. It's not that you want someone to waste too much time trying to figure-out something they could get an answer in one minute, but good developers just can't let go of a problem until they come up with a solution.

Arthur Havlicek's answer about asking about past coding experiences is a great question. Of course you want someone who knows C++ (the language you need), but don't risk missing out on a good coder in another language who will quickly surpass someone with a little more language specific in the very near future.

  • What's the best thing you've ever coded?
  • What code did you write that you would now do differently?
  • What was the hardest thing for you to understand about programming?
  • Have you ever worked on a project with other programmers? What were some problems?
  • What did you learn during this interview?

If too many candidates can't answer this last question, you're probably not exposing them enough to the things you expect them to learn.

share|improve this answer
I don't know why this answer didn't get more upvotes. Verbal technical questions block creativity, while putting a junior applicant in front of a computer gets his/her creative juices flowing. Every junior-level developer applicant should be asked to write some code on the keyboard, in the development environment that's commonly used at the company. –  InvalidBrainException Jul 19 '14 at 19:49

Your questions are dubious. See @Kai's remarks in the comments of your question.

I've run some interviews lately concerning a junior position as well. What I've been looking for was intellect. Important for the position is the ability to learn, see challenges instead of problems and know how to work together with people who might know the answer.

As to really seeing their abilities, one little assignment I provided was how to sum a multidimensional array of unknown depth containing integers. Knowing about recursive functions will obviously help in the answer, however seeing how someone picks up this question is more about logic than about skill. Maybe an applicant might not know the answer or get nervous. So it's important to make them at ease that not knowing an answer is not problematic. Also while they are using a whiteboard you might get a cup of coffee and provide one to the applicant, giving them time to think and reflect.

A few applicants did not need any whiteboard, others tried and failed badly. But in every situation it gave good insight into capabilities and intellect.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.