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.

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.

Example:

‒ 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.

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.

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.

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.

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.