I'm asked to perform or sit in during many technical interviews. We ask logic questions and simple programming problems that the interviewee is expected to be able to solve on paper. (I would rather they have access to a keyboard, but that is a problem for another time.) Sometimes I sense that people do know how to approach a problem, but they are hung up by nervousness or some second-guessing of the question (they aren't intended to be trick questions).

I've never heard my boss give any help or hints. He just thanks the interviewee for the response (no matter how good or bad it is) and moves on to the next question or problem. But I know something about the rabbit hole that defeat and nerves can lead you down, and how it disables your mind, and I can't help wondering if providing a little help now and then would ultimately help us end up with more capable programmers instead of more failed interviews.

Should I provide hints and assistance for befuddled interviewees (and if so, how far should I go while still being fair to the more prepared candidates)?

  • 30
    You'd make a great professor. They say, a student learns more during an oral exam, than the whole semester.
    – superM
    Aug 3, 2012 at 7:34
  • 2
    I loath at the potential of the number of opportunities I missed out on because of nerves... Aug 3, 2012 at 20:21

15 Answers 15


When I was in a similar position, I would say to the interviewee: "Pretend I'm Google. If you need to search for something just say so."

In one question interviewees needed to be able to figure out the volume of a cylinder, so I didn't mind if someone said, "I'd have to Google for the formula for the volume of a cylinder." I was interested in knowing if they knew how to attack the problem, not if they'd memorized formulas. For the job, they had to have a decent grasp of how to translate the real world into software, so it was an important concept.

On the other hand I wasn't going to tell them they needed that formula.

You are correct that nerves can be a problem, but I still expect people to be able to express their thought process, even if they're nervous. Simply not giving an answer was unacceptable.

  • 35
    @Job, I learned the volume of a cylinder 40 years ago and I've been programming since then, solving real business problems but never had to use that formula so I've forgotten it but I can google it in 5 (maybe 6) seconds. Why would you not hire me? Aug 2, 2012 at 22:15
  • 16
    @MichaelDurrant because its such a trivial formula, its one that everyone is just expected to know, like the Pythagorean Theorem. And even if you did manage to forget, you should be derive it in your head in a few seconds anyway. Aug 2, 2012 at 22:22
  • 53
    @whatsisname, that is an incredibly arrogant approach to the situation. computer programmers are supposed to be solving problems, not memorizing every single mathematical formula (no matter how trivial) that comes there way. It's how they end up solving the problem that matters, not how much they didn't know at the start.
    – ardent
    Aug 2, 2012 at 22:36
  • 14
    @whatsisname, sure by virtue of me needing to juggle byte to KB to MB to etc conversions I could tell you quick and dirty ways to figure out 2^32, which is 4 GB or 4096 MB. But I wouldn't know the volume of a cylinder, granted I could quickly derive it based on what I know about circles and calculus, but I could also quickly google it for you and save us both time.
    – ardent
    Aug 2, 2012 at 22:59
  • 13
    @Job, you're correct in that. I was thinking in terms of general volume, and thus overcomplicated the issue. In the end though, it still becomes a non-issue. If that's the only thing hanging them up, and they have a great grasp of actually how to solve the problem, why not hire them? I wouldn't want to hire someone who could instantly pull 2^67 out in a split second, but can't tell me how they would go about implementing a quick and dirty insertion sort in the language of their choice.
    – ardent
    Aug 2, 2012 at 23:18

You have two approaches which work both for problem solving and short technical questions:

  1. The first one is used by your boss: don't provide any help in order to test how the person behave in a stressful context. It is a perfectly valid approach, and may give some hints about the person. After all, once you hire this person, she will not be able to receive constant help from all her colleagues.

  2. The second one is to provide hints and support. The level of support doesn't matter too much; the only thing which matters is that the more help you provide to the person, the less you have to value her success.

Personally, I believe that you should take enough time to both be sure that the person is unable to solve a problem by her own and make the person feel that she's unable to solve it without help. But then, you may provide progressive help until you tell to the person the answer itself.


‒ Can you tell me how do you create read only properties in C#, i.e. properties with a value which can be initialized only within a constructor and cannot be changed later?
‒ Of course. I just use the keyword readonly.
‒ Are you sure? Can you explain me the difference between a property and a field?
‒ Hm. A property is... you see... get and set...
‒ Ok. So a field is a variable declared inside a class or a struct and valid within the class/struct scope, while a property is like a field, but also provides a mechanism to read, write or compute a value. Now what about readonly? Is it used with properties?
‒ I believe that it's used only for fields...
‒ Right. So what about the properties?
‒ They cannot be read only.
‒ Are you sure? What about the properties which have only getters?
‒ They are read only.
‒ Does it mean that their value will always remain the same?
‒ Yes.
‒ No, not really. The fact that you have a property with a getter doesn't mean that its value doesn't change during the lifespan of the instance of the class. If the getter refers to a field which is incremented each time you access the property, the returned value will continuously increase.
‒ Right.
‒ So? Do you have an idea of a way you can implement a property with a value which never changes?
‒ No.
‒ Well, you can use a readonly backing field. Do you know what is a backing field?

Giving the answer is a good idea in all cases. There were several cases when the interviewee commented my answer in an interesting way, showing that even if he was unable to answer to the question in a first place, he still knows related things.

Also, by just asking a question with no further help, you are not having too much information about the person, aside the fact that she knows or doesn't know the answer. Providing progressive help may allow you to see how the person is thinking about a problem.

It may also show other things the person doesn't know. Take the example above: if I would stop at the first reply, I wouldn't have known that the person cannot explain the difference between a field and a property or that she doesn't know what a backing field is.

If the person answers immediately, it's fine. If she needs some assistance, there is nothing wrong with this. If you end up answering the question yourself, it's a bad sign and hopefully the interviewee will be able to answer the other ones.

  • 1
    Your second point leads to the conclusion that the person who does not seek help should get the job. Not always the case, especially if the question is ambiguous.
    – riwalk
    Aug 2, 2012 at 20:40
  • 1
    @Stargazer712 - not necessarily. Some folk need a little assistance to recall reference type items. I think the point MainMa is making is that it's okay to prime the solution a little bit since it will allow you to see how they work through the problem. How the candidate works it through is far more valuable information than the answer. Her point is that if you have to provide lots and lots of help then their problem solving skills probably aren't so good. The gradient goes from "some / no help" to "needed lots of help."
    – user53019
    Aug 2, 2012 at 20:50
  • 1
    A note on the first point--they are already in a stressful situation: a job interview! Aug 2, 2012 at 21:21
  • 2
    +1 for your example - with this approach as an interviewer, you get a much deeper insight into the candidates REAL understanding of the subject.
    – StuartLC
    Aug 3, 2012 at 5:50
  • 2
    @nonnb You're also likely to pick up a few other things along the way, too. Like MatthewFlynn says, they are already in a stressful situation. Making the interview more of a discussion than an examination may or may not tell you about a particular knowledge point of the candidate, but it will tell you a lot about their approach to solving a problem they face. Which, quite frankly, in something like 99% of combinations of programming employments and work assignments, is a lot more relevant to one's ability to perform programming work.
    – user
    Aug 3, 2012 at 8:05

I always like to help interviewees if they're stuck on some simple thing (like the name of a particular pattern if they obviously know what it is), and letting them gloss over things like the details of establishing a database connection. If they're trying to design something, though, I don't say much because I don't want to either guide them or throw them off if they're thinking about something other than where I'm guessing they're going.


I remember being asked a particular problem solving question from an interviewer who had a very specific result in mind, but he was not able to communicate the question clearly to me. This describes the situation that many interviewees run into. Sometimes the blank stare is not because the person is not a good problem solver, but because the person asking the question is not being clear in what they are asking. In that case, your colleague's approach of saying and doing nothing just proves that the candidate doesn't think like your colleague, or isn't inside your colleague's head. I think providing clarification of the question in different words might provide better results for all involved.


Given that programmers (most of us at least) don't work in a vacuum, and that interviews are stressful enough without artificial limits, I'd be inclined to offer as much help as an interviewee asks for or needs.

But take it all into account when making a final judgement about an applicant's actual competence level.

Someone who is looking for a senior position but needs lots of help would ring alarm bells.


For "senior people", I offer short, open ended questions and pay more attention to the questions they ask than the answer. I find senior people who listen, communicate, use active listening, clarify, then provide solutions are the type I like.

For "line engineers", I have used the technique for programming tests where you give an applicant a computer and a problem and a few hours, then you come back. In that situation, we asked the applicant in advance what OS and tools they preferred (also an interesting part of a programmer's expertise). When they were finished, as a group we asked them to present the solution and why it was better than other solutions - a code review. All skills I expect from an experienced engineer on day 1.

Importantly, the entire interviewing team had taken an afternoon to do the same test, so we knew the test was fair. We spent an hour examining each persons' approach like we would with an interviewee, which gave us a sense of different approaches.

This second technique found us some of the best "unsung" programmers (lousy resume, lousy interview skills) I've ever found.


I prefer to start interviews with an easy confidence-building question to get the candidate comfortable with the process. When this works it still lets you glean as much information as possible from later questions without giving advantage to candidates who understand body language better than the job related material.

  • Unless it doesn't work and then it's just sad, sad, sad for the rest of the interview. Personally, I think our first questions are terribly easy, but not all of our candidates seem to think so.
    – kojiro
    Aug 3, 2012 at 19:43
  • 1
    @kojiro, Yep. I've had that happen. I switched tacks and had them talk about something on their resume and that helped a candidate recover to the point where they seemed less off-balance during the rest of the interview, but in at least one other case it didn't. With the exception of a few undergraduates applying for internships, I haven't run into many candidates who don't relax when given a smile and a softball question. Aug 3, 2012 at 21:07
  • +1 good approach. I had a prof at university who, when taking a student for an oral exam, always told them to prepare something for the first 15 minutes. So only the student would talk for the first 15 minutes, only then would the professor start asking questions. That allowed the student to have a good start, and gave the professor points to ask about later (though he would also ask other questions about the subject). I very much like this approach.
    – sleske
    Nov 16, 2012 at 8:35

Sometimes providing minor hints during the oral interview helps to see how well candidate understands the topic(s). However, there should be no hints on standard tests that each candidate is requested to take.

Basically, there are two main things that you may want to know about potential candidate:

a) Personal characteristics - does he fit well into your company or team

b) Technical skills - does he have good technical background and interest in picking up new things

In order to learn about these mentioned points you have to engage the potential candidate into a conversation. It is also important to make sure that candidate is comfortable during the interview in order to get maximum understanding of his current skills (both soft and tech) as well as his potential to do the work.

In addition, communication skills of potential candidate are as important as his technical skills and competence to solve the problems.


Part of what should be looked at is communication skills. If the candidate is unclear about the question, he should ask questions to clarify. This is a good thing, in my opinion. Too often, bad decisions are made because certain assumptions are made when reading specifications or, in this case, processing an interview question. The candidate may answer based upon these assumptions and totally miss the intended point. The question might be flawed, or it might be the candidate. In either case, allowing for clarification via communication demonstrates a valuable skill, one that employers should look for.


I think that this ultimately comes down to your personality as an interviewer, and what you think is important and therefore are really grading the candidate on.

Personally, I value practical / pragmatic capability over academic / esoteric trivia. I'm much more interested in a candidate that can come in, get to work, and contribute effectively in some valuable way to whatever project(s) they are being hired to work on than I am on how good their memory for minutia is.

So, I'll coach a bit if the candidate is stuck on something esoteric, or a rarely used nuance, or an edge case that might be relevant in a made-up interview question but is rarely if ever relevant in real life. Especially anything they could get with a couple of minutes on Google or with a handy desk reference, or "set it and forget it" type things.

However, I won't coach them on real-world, common, mainstream, fundamental, work-a-day things. These are the things I want to be innate to them.


I think it depnds on the interview situation and the questions. I have used both techniques.

Why might I want to not ask follow-up questions? When I am trying to find out the person's response to stress. I have interviewed people for some jobs that were in highly stressful environments and how well they could handle stress was a critical factor in our evaluations, so we asked some extremely difficult questions that no one could answer without some stress.

When I am trying to find out their technical knowledge, I ask follow-up questions that may contains hints as to what I am looking for. Contrary to the thought of the manager who said you have to ask everyone the same questions to be fair, I believe this is fair as long as several conditions are met. First everyone gets asked the same base question. Second, you should not ask follow up questions to help only one person. If you have let others flounder with no help, you need to let all flounder with no help. Second, you should compare candidates' performance on the question, not only in terms of their final answer but in terms of how hard it was to drag it out of them. This process still treats everyone fairly.

  • 1
    -> agreed. "Fair" does not necessarily mean "sterile". Each candidate will have a slightly different experience. Nov 15, 2012 at 22:03

Depends what kind of programmer you want. An introvert who can write a great 20 lines of code on paper will look good to you boss. A software developer that can work on million line code bases within a team to produce good software efficiently will probably not do very well. I love these kinds of interviews as a candidate - they tell me a lot about how the boss treats his staff and what the work culture is. In a case just like this, as I left the interview, I said "Thank you - Lets save us both a bit of time, if don't call me, I won't call you." When asked why, I pointed out that I did not want to work for a company who set me up to fail.

You approach is likely to get better selections for software development. You bosses approach would work well for rubbish collectors and the guys who hold the Stop/Go lollipops at road works.

Software development is a team effort, not a solo / mind reading / non interactive game. How many projects fail because the software does what was asked for, not what was wanted.

  • 1
    You bosses approach would work well for rubbish collectors and the guys who hold the Stop/Go lollipops at road works. My boss's approach landed him me and several other excellent developers. The reason I asked the question is that his approach is slow and we end up not hiring developers who may have been great. (Besides, good programmers are garbage collectors.) ;)
    – kojiro
    Aug 5, 2012 at 23:53
  • 1
    For my own reference, is your work place a culture where the team performs well beyond the sum of the capability of the individuals, or is it a group of individuals working on the same product performing to their individual capability?
    – mattnz
    Aug 6, 2012 at 23:50
  • My team plays two roles: developing off-platform solutions and rescuing floundering projects. We don't all work on the same project at the same time, but it's rarely one-person to a project. From where I'm sitting it's the best team in the company because I enjoy my work and the companionship, but I can't honestly tell you if we outperform our individual capabilities.
    – kojiro
    Aug 7, 2012 at 0:18

I was recently in a similar situation. The direction I got from my manager and HR was that we needed to be completely fair to all 6 interviewees, so I had to ask the same set of technical questions with minimal help to see how each interviewee performs. Sometimes when they knew the answer but stuck with a technical term or something I helped them indirectly with some questions that guided them to that term. There was a second round of interview after the technical round on personality and behavioural traits if they managed to go through the first round.


Part of what you want in an employee is someone who can interact with the rest of the team. You need someone with required skill, true. But you also need someone who knows when they need to reach out for help and has he self-knowledge and social skill to do that. This latter sill set will set will build up the company better in the long run than any particular computer-language Du-jour.


The way I see it, an interview is a trial coworking session, not a test. I'm primarily trying to answer the question "what's it feel like to work with this person?" I sometimes even pretend I have forgotten the answer to the question, to make the exercise feel more collaborative.

Have you ever worked with someone who you just could not get on the same page with whenever you talked through a problem? Or someone who asked too many questions instead of jumping in and solving problems? In an interview I'm mostly making sure the person I'm talking with isn't one of those. There's a strong element of chemistry there.

In the process I'll of course also learn things like, "does she write clean code," "is she familiar with the requisite concepts," and "can she cleverly poke a problem to arrive at insights?" The candidate will still be the one "driving" and writing code. But along the way hopefully she'll be more relaxed and I'll see a version of her that's closer to what I would actually see day to day as a coworker.

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