How to react to wrong/not answered questions during interview? [closed]

Question

Today I have held my first interview with potential interns. While this has been mostly open questions, I have had some trivial programming tasks for them:

• Write a function that returns true if triangle sides (all integers) a, b and c can represent a right triangle.
• FizzBuzz.
• Calculate the Nth element of Fibonacci using recursion (if they didn't know what Fibonacci was, I would even write them the definition F(n) = F(n-1) + F(n-2); F(1) = 1; F(0) = 1).
• Implement structure List for integer and write function to reverse it.

These are obviously very easy tasks and I was not prepared for someone not to solve them.

How should I act when they struggle with these questions? Should I give up the answer? Give tip by tip (I did that and ended up solving the problem myself)? Or just move on (or maybe just stop) with the interview?

ps. By having problems with questions, I don't mean like having a bug, I mean if they can't even get started. This was a case with Fibonacci and List questions.

Answer 1

You said that you are interviewing for intern positions in the question so this is from that standpoint, for full time developers the bar is going to be a bit higher.

When you are interviewing interns you have to remember that they may not have completed their studies and that they may have also entered into college without any previous background in programming and computer science. As such, you need to scale expectations to what you can reasonably expect someone to know and to the degree of prestige of the position (i.e. Google can get away with expectations that a company people haven't heard of can).

Looking through the questions that you presented I would likely view them as follows in an interview:

1) Write a function that returns true if triangle sides (all integers) a, b and c can represent a right triangle.

Basic application of geometry with simple coding, most students should be able to do this without much difficulty. At most a reminder of the Pythagorean Theorem might be needed if they are showing a bit of stress because of being in an interview. This could almost be seen as a "ego boost" problem in that it can help settle some people if they are very nervous going into the interview.

2) FizzBuzz

Again, another application of some basic control statements. Students that haven't been exposed to the modulus operator, or haven't used it much, might need to be reminded of it, but shouldn't encounter any real problems solving the problem.

3) Calculate the Nth element of Fibonacci using recursion (if they didn't know what Fibonacci was, I would even write them the definition F(n) = F(n-1) + F(n-2); F(1) = 1; F(0) = 1).

This tends to be a fairly common problem so most (if not all) students will see it at some point prior to graduation. The catch is that it usually shows up when recursion is presented to the students as it lends itself well or a recursive or loop based solution which can then be compared so students from different schools might see it at different times depending upon the sequence of courses. In practice, if someone couldn't come up with the recursive I'd ask for an alternative using loops and if they couldn't come up with that I would be more concerned at their potential ability.

4) Implement structure List for integer and write function to reverse it.

This question might actually be a bit too open-ended as it is written so it could also be a good question to see how the candidate seeks additional information (e.g. should delete functions be included, conversion to arrays, etc), but given a well defined problem statement ("Implement a basic list structure for integers that allows for numbers to be added to the end or at an arbitrary index, deleted, and include a function to return a reversed copy of the list") students should be able to solve the problem as long as lists are a common structure presented either in an early data structures course, or in an early basic computer science course.

In terms of dealing with the candidates, if they are struggling, make sure they are relaxed and allow them a bit of leniency as they might just be having performance anxiety as this might be their first real interview. Tips on solving the problems might be required, most so in the case of the third and fourth problems as opposed to the first two.

Also, structure the overall interview process so that there are "graceful exit" points built in. For example you might have the following agenda:

• Meet and greet, interview procedures.
• Short interview with staff programmer(s), basic questions about background.
• Presentation of programming quiz.
• Break
• Return from break, dismissal of some candidates that aren't a good fit.
• Extended interview with staff programmer(s).
• Interview with human resources (if required).
• Wrap up.

This interview flow tends to work well if you want to be able to dismiss candidates early as they know from the beginning that they might be dismissed after the break. The short interview before the quiz also means that they aren't just showing up to take the test which gets them some interview practice and may also allow them to decide that they aren't a good fit. If there are other programmers observing the quiz or assisting the candidate during it then it also gives them a chance to pass/fail the candidate while they are taking a short break.

At all time when you are interviewing for an internship and the candidates are students you must remember that they are still students and may not have much practice with interviews (leading to possible performance anxiety) and may also have not reached the point in their studies to even be able to answer the questions which means it might be a good idea to send them on their way with a copy of the "ideal solution(s)" to the problems they are given as well.

Answer 2

My goal for any job interview, no matter which side I'm on, is to end up feeling like I'm talking to a colleague. Colleagues come into my office all the time when they're stuck on a problem. I ask my colleagues for help when I get stuck myself. So in an interview, I try to recreate that dynamic.

In other words, what would you say if a colleague needed to implement a fibonacci sequence and didn't know what it was? You would explain it to them until they grasp it enough to continue on their own. There's no shame in ignorance as long as it's not permanent.

If you go through that exercise and still can't picture yourself working with that person, then they're not a good fit for the job.

Answer 3

The point of giving questions like this in an interview is to determine whether someone can figure out how to solve problems. The job of being a programmer generally consists of two things: "Take these requirements and implement them in code" and "figure out why the implementation isn't matching the requirements and fix it." So what you're really looking for is not a solution to these specific questions, but the ability to figure things out.

Understanding this, I would give a hint or two to get someone started, and maybe some more if it's clear that they're making real progress but missing a detail somewhere. But if it becomes clear that they just can't figure out how to solve the problem, then you have your answer and there's no need to continue with the exercise.

To give an example, when I interviewed at my current job, I was given a question about finding the shortest path from one node to another on a graph. I replied that I'd likely use something like Dijkstra's Algorithm, which I vaguely remembered having learned about one day back in college and had never used since, and gave a quick (and incorrect) explanation of it that satisfied the specific conditions given by the question. The interviewer pointed out that my solution would end up in an infinite loop if the graph was modified slightly, and that jogged my memory, so I explained the right way to avoid this problem. And I ended up getting the job.

Answer 4

for intern positions you might be asking a bit much.

I have no idea what you even mean by the 4th question. as for asking a recursion question, its a bit impractical, go through your own code base and determine the number of areas recursion is used, I'm willing to bet that its few-none. Interview situations are stressful, and expecting candidates to implement rarely used strategies that are backwards compared to most things you will ever program is unfair to them, especially towards the beginning of an interview. Personally I would be asking questions where they have to explain what important concepts mean/ how they are used, providing canned examples. I would be much more interested in candidates that can tell you X book or Google Y search will provide everything needed to implement something to your code base.

Answer 5

IMHO your first two questions should be solvable to anyone calling him/herself a programmer, be it junior or senior, straight out of school or self-taught.

If I see that the interviewer is struggling with either of these, I would try to rephrase the problem, and check whether (s)he fully understood it. Then encourage her to use pen and paper, whiteboard, draw figures or whatever approach she prefers to tackle the problem. I also ask her to think aloud, to get a view into her thought process and if needed, give little hints if she is on the right track just doesn't dare to advance, or has some obstacle. But if even several hints don't help, or - as you mentioned above - I end up solving the problem for her, I would probably finish the interview to stop more wasting of our time. In an interview, I am always striving to see and focus on what the candidate knows, instead of what she doesn't, but if I can't seem to find any significant knowledge, I give up after a while.

The 3rd and 4th ones are somewhat more difficult, so I could accept if a junior couldn't get them, if (s)he otherwise demonstrated a good problem solving approach and enthusiasm. But for a senior, they are still a must.

Answer 6

I had to look up what you meant by "FizzBuzz"; turns out I'd heard of the game and its rules but not by that name and not in a while. So, don't think you don't have to give ANY information to interviewees.

That said, these are all basic coding problems that I would expect someone interviewing for even an entry-level coding position to be able to think their way through, if they couldn't code an answer by inspection. So we're on the same page there. The answer to your problem is dependent on how they're getting it wrong:

• Minor syntax issues: If you're expecting code in a certain language, don't count off too heavily if they miss a semicolon or misspell one use of some identifier. Most IDEs will catch that immediately, and everyone makes typos from time to time. In almost every interview in which I was expected to code something, "pseudo-C-ish" was acceptable as long as the algorithm was communicated properly to the interviewer and the logic was sound.

• Minor logic flaw: If the algorithm would behave as expected in most, but not all, of the expected scenarios (say when coding FizzBuzz, 15 would only result in "Fizz" or "Buzz" but not both as it's supposed to), then be the "unit tester" and point out that the algorithm would fail in that instance, and see if they can fix it. They may have overlooked that particular case, or they may have not understood the requirements completely enough. Both are again completely understandable, everyday occurrences in coding, which should be easily overcome by simply providing the additional information or feedback.

• Major logic flaws: If the algorithm would not pass most or any test scenarios it was given, point that out too, and see if they can fix it. This is more of an issue; either they misunderstood some very basic requirement of the system, or they overlooked some gaping logic hole. But, if they can fix it given more detail of the problem, without being told exactly where their code is failing, chalk it up to unclear requirements and move on.

• Don't know where to start/hard-coded answer to specific cases/can't understand their pseudocode: These are the red flags. If you ask someone to code an algorithm that follows the FizzBuzz rules, explaining those rules to them, and you get a blank stare, the interview is over. By the same token, if they can put SOMETHING on the board but it fails at large portions of the problem space, and you have to hold their hand when illustrating the failure and how to fix it, I would not be proceeding to a second interview.

Answer 7

If you really got a potential intern who acts like a deer in the headlight because he's never been interviewed, has anxiety issues, has never been in a real life situation like that (you usually notice from their body language), you can just start by asking them what they've worked on last.

Then it'll be his territory so he might not be crazily nervous. When you find an appropriate place ask, "Hey, how did you implement that?". If he can explain, it might give you some insight into his way of thinking.

Put your own tests on the agenda after that.

Answer 8

Fizzbuzz is an absolute requirement. If they can't code Fizzbuzz, you shouldn't hire them.

I typically ask the candidate for a pre-interview code session, where we use Google Docs to work through a programming problem (typically Fizzbuzz + a higher level problem if they can easily complete Fizzbuzz).

I'm typically on the phone or on skype with them during this, and since I'm watching them complete the problem (and talking to them about what they're thinking at certain points), I can be reasonably confident that they didn't just google the answer.

As long as your other problems are specified well (that is, you give them the formula for each), then your questions are just fine.

When I interview candidates, I try to stick to programming problems that they're likely to encounter. I love string manipulation problems because when you're on the web, just about everything user facing has to do with some sort of string manipulation. How they handle that is important.

Answer 9

It depends on the calibre of the position you are trying to fill.

If you are going for a senior developer, then I would expect them to know all of that. If they got it wrong and I was feeling evil, I would just stop the interview, thankyou and good bye. If I was in a more polite mood, I would just thank them and rush through the rest of the interview.

If I was going for a junior developer, then those questions could be considered quite tough. I would be more interested in exploring their ability and willingness to learn. So I would try giving them hints and guide them along and see how they respond.

Answer 10

Intern interviews are a different breed of interview. What I typically do is use my standard developer questions (like the ones you provided) to gauge where they are at in their education. The ability to solve these problems will vary greatly from sophomores to seniors.

After I have that information, I then focus the interview on other skills such as, will they be able to work on a team, are they teachable, will they benefit from interning at our company, are they passionate about development / learning, etc.

To me, it's the non technical things that really set an intern apart from the other candidates. I would much rather spend a few months coaching / mentoring somebody that is driven to learn and grow, than somebody that just wants a job for the semester.

Answer 11

Ask yourself what value the interviewee is likely to add to your company. Factor in the cost of having a mentor involved, especially if they can't solve problems at fizzbuzz level. If the answer isn't commensurate to the intended salary, then you have a good economic case not to hire them.

Don't be afraid to go back to your manager and say "there were no candidates who would add sufficient value to our company to make hiring them worthwhile". This has to be a better course of action than ending up with someone who is actually of negative value, because of the cost of having someone constantly helping them out.

Answer 12

My answer may seem a bit unkind or dismissive, but I think it works well. To begin with, I give the candidate a question that is very easy, which serves as a warm up question to help build their confidence. Whether or not they succeed, I move onto a question that is less trivial, and directly related to what the job entails.

At this point, it's all or nothing. If they sail through it, great, no problem. If they struggle a bit, no prob, I'll help prod them along and then move onto other questions to guage other abilities.

If, however, they utterly lack the ability to solve it, I go ahead and burn the rest of the interview time helping them along. The candidate still feels engaged in the interview, but I don't have to steer the interview in different, irrelevant directions. It's good for the candidate, too, since it may be educational.

Answer 13

1. Try to be nice on them. By your questions it is seen, that you are not trying to be nice even here. Do you think everybody should know this "fizzbuzz" term? Or we should search the net because you were lazy to write it yourself? On the contrary, I think, everybody here knows what the right triangle is.
2. What is "structure List"? I don't know. I know "the List structure". What does it mean: List for integer? List of integers you mean? I too, wouldn't know how to start. And please, don't talk you are not English. Me too. And even I hadn't ever been to an English-speaking country. You surely know that integer in plural will be integers. If you are not trying to be understandable with your equals here, I can imagine how you are doing there.
3. Any literate programmer knows that Fibonacci row is a book example of what should not be done by recursion. Are you testing them for ability to oppose you or for coding skills? Do your job and find a better example for testing skills in using recursion.
4. "Ability to work under stress" for a programmer means he could work for nights when it is necessary. But if you want to have good programmers, they would wait that their chief is a very nice, understanding and helpful fellow. If you are not, you'll never have good programmers. They are not alpha-rat-males. If they will feel any agression, they will simply close in their shells and will do nothing.

So, my answer is: be better prepared yourself.

P.S. You are a manager already, so, you really should hold stress.