Forums

:shock: Just went through a phone interview today, and I came across an issue that I'm probably going to have again and again. I had an interviewer (Partner in a consulting firm) ask a fairly technical question, I now I realize that he was looking for a very specific answer.

I walked through my answer the first time in a generic way, describing processes and tools that I would use to perform a specific function. He then rephrased the question and I tried again. I was trying desperately to get what he was after, but didn't have any luck. I even asked him to clarify a couple of his points. Tried a 3rd time, and I still don't think that I was using the words that he wanted to hear.

I've conducted interviews before with a co-interviewer who tried to be this specific. He told me afterwards that he was just looking for the guy being interviewed to say 'X'. My issue was that there could have been many ways of saying a particular thing and still end up in the same place.

I really don't need to discuss the positives and negatives about asking very specific questions. My question is: how do I answer them when I don't have the answer? The first time asked I am assuming that I have the answer. The second time, I now have the feeling that the interviewer is looking for something specific and I don't know if I have the right words that will satisfy them. If we go round and round, I'm worried that it's all that will be taken out of the interview, so I don't want to get stuck.

Ideas?

asteriskrntt1's picture

Hi Tim

You are going on the premise that the partner actually knew what he was doing. While it is possible you did not know an answer, it is also possible he did not know what he was really looking to hear.

I don't think there is anything wrong with being bold and asking "What specifically are you looking for that I don't seem to be providing?" or saying "that is not something I have encountered in my career. Is that something that I would see in this environment?"

I am sure others in the forum also have some interesting takes on how one might respond in this environment.

*RNTT

HMac's picture

tim - without the specifics, I'm not sure I'd know how to help you. But I probably wouldn't understand the specifics!

Reflect on this: try to consider how central any particular answer is to being successful in the job. If you're applying to be a heart surgeon, then knowing precisely where the heart is located is probably a fair bit of knowledge to ask about :wink: But knowing the precise mix of anesthesia gases is probably a little bit less central - because that's not gonna be your job as the surgeon...

I think your instinct is right - take a whack at every question. If you sense the interviewer is still looking for something, give it another go. But after that, you're probably risking looking like you're fumbling around.

Then ask yourself candidly - was I weak on a central point to being successful in the job, or was I weak on something less consequential?

And know enough about every job you're interviewing for to be strong where it counts.

-Hugh

AManagerTool's picture

Tim,

I agree with everyone else but would like to add the following.

[u][i][b]"I don't know"[/b][/i][/u]

I am a technical manager. I run an angineering group that has to be innovative and think on their feet. We routinely encounter problems that nobody has ever seen before. I have asked candidates specific technical questions before. Not to trip them up but to see how they answer. If they don't know, I expect to hear the first thing out of their mouths being the answer, "I don't know". If they try to make up an answer, I think that they are full of shinnanigans. The next thing I expect to hear is how they would go about finding out the right answer. A good learning technique is MUCH more important to having all the answers.

Don't be afraid to tell the truth. "I don't know" is sometimes the right answer.

tcomeau's picture
Training Badge

I've been on the other side of this. I have a standard question that I ask candidates about the differences between Java and C++. There are two answers you can get (and maybe a third) that tell you a lot about the candidate's understanding of programming languages in general, and of the philosophical differences between these two in particular.

The answers are (in case you ever get this question)
[list]1. Java does garbage collection, C++ lets the user manage memory. The former takes the view that memory management is too important to leave to the user; the latter takes the view that memory management is so important the user must do it.

2. Java has an AWT, C++ you have to find a library. The former abstracts the notion of a GUI because users don't know how to build one; the latter ignores the notion of a GUI because users know better what they want.
[/list:u]
Recently I'm getting one more

[list]3. Java has generics, C++ has the STL. Both allow type-safe operations without requiring type-specific method signatures, but they have different approaches. (And different risks!)[/list:u]

So I might ask that question nearly the same way three times, because I'm looking for three answers. I'm trying to see where you fit in my model of language sophistication. (And, unfortunately, saying "I don't know" would be fatal!)

If you give me any one of those three, and tell me why you'd choose C++ over Java in a couple of specific instances, I'd be happy. If you give me all three, but when I ask "Why would you pick Java over C++" and you couldn't say something about standard GUI look and feel, I'd be unhappy. So even though the interviewer was looking for something specific, you may in fact have "passed."

I can't tell if this is what you were hearing, but that's an example. Do you want to share the specific question? (Not so much to let us guess the answer as to let us pick the question apart. Maybe it was a bad question?)

Oh, and if I were being thoughtful, I'd ask the followup question as "Tell me about a project where you were able to pick the implementation language, and why did you pick the language you did." That way it's behavioral. :)

tc>

timbarrow's picture

Thanks Tom and the rest for replying,

BTW - as an interviewer, I am much happier with I don't know than something made up. Nothing worse to me than spending 5 minutes listening to someone try to act like they know something than when they don't. It also makes me wonder what happens if I were to bring them on - will they be trying to do the same to 'fool' me when I need to understand they don't have the answer.

It's a different situation when it's a question that is critical to the job function and not a technical detail. I work with SAP and if the person didn't know how to log on (not that I would ask the question) they would be out in a heartbeat.

Ok...now to my specific issue and the question asked. Apologies to those who aren't familiar with SAP implementations....

It was around SAP's proprietary project methodology ASAP. He asked about how I would use ASAP to kick off a brand new SAP implementation. I answered in a more process fashion, talked about the various stages of the project, resulting documentation, resources involved. After it was all said and done and after I spent some additional time out on the internet – I think the guy was wanting me to list the tools that are available through ASAP (Q&Adb, Business Blueprint and accelerators). I probably described what the tools did many times in discussing ASAP altogether – but he was looking to see if I knew all of the tools names.

I think if I could have realized what he wanted, he would have gotten the answer or 'I don't know'. I don't think it was that relevant of a question that it would have made a big deal. Just wish I figured that out earlier and could have gotten to the next question. Fumbling for the answer cost more than just acknowledging not knowing.

tcomeau's picture
Training Badge

[quote="timbarrow"]...

Ok...now to my specific issue and the question asked...

It was around SAP's proprietary project methodology ASAP. He asked about how I would use ASAP to kick off a brand new SAP implementation. I answered in a more process fashion, talked about the various stages of the project, resulting documentation, resources involved. [/quote]

You could be right, but I suspect you're just second-guessing yourself. I actually know very little about SAP, so I could be missing something important. Talking about process, about the approach you've used in the past and the artifacts that result, seems like the good answer to me. It could be that he was trying to check tools off a list, or that he was trying to see what you knew about his favorite tool.

There's a variation of this I see in mediocre instructors, where they play a game of "Guess what the teacher is thinking. If you're going to play that game, I think you need to give good hints, and a better approach is to ask directly, "Do you think xyzzy widget maker has been helpful in kicking off project?" At that point if you get "Uh, I don't know, I haven't used it" and xyzzy widget maker is critical to the job, you have the answer you need.

Conversely, if the candidate says "Oh, no, we tried that on the framilstan project and it was more trouble than it was worth" then you get to have a great conversation about the tool and how it gets used. I love interviews like that, and you get extra points for it.

[quote="timbarrow"]
I am much happier with I don't know than something made up. Nothing worse to me than spending 5 minutes listening to someone try to act like they know something than when they don't.
[/quote]
I agree I'd rather hear "I don't know." On the other hand, when I detect an attempted snow job, I'm fine with it, because I've just ruled out that candidate.

tc>

bflynn's picture

[quote="timbarrow"]It was around SAP's proprietary project methodology ASAP. He asked about how I would use ASAP to kick off a brand new SAP implementation. I answered in a more process fashion, talked about the various stages of the project, resulting documentation, resources involved. After it was all said and done and after I spent some additional time out on the internet – I think the guy was wanting me to list the tools that are available through ASAP (Q&Adb, Business Blueprint and accelerators). I probably described what the tools did many times in discussing ASAP altogether – but he was looking to see if I knew all of the tools names.

I think if I could have realized what he wanted, he would have gotten the answer or 'I don't know'. I don't think it was that relevant of a question that it would have made a big deal. Just wish I figured that out earlier and could have gotten to the next question. Fumbling for the answer cost more than just acknowledging not knowing.[/quote]

I think you're right on. These days anyone who can spell SAP or ABAP is putting it on their resume. Interviewers have to ask specific technical questions as a qualifier to see who really has worked with the technology and who has not.

In this case, it sounds like maybe the only "right" answer to say something about the details of the methodology. Then again, if you didn't claim it on your resume and you never said you knew it, then there's no reason to try to bluff your way through. Their expectation should be that you don't know it.

Brian

derosier's picture
Licensee Badge

timbarrow,

I sometimes ask such specific technical questions when I interview. Mainly because I'm the "technical" person in the session, so it's my responsibly. One of my favorites to ask a C++ programmer, who's interviewing for a C++ programming position:

I hand them a paper with this written on it:
[code:1]void (CBar::*Foo)( void );[/code:1]

And then I ask them to identify what it is, and then I ask what syntax they would need to use in order to use it.

(BTW, it's a function that returns a pointer to a member function of class CBar).

Yes, it's partially done to trip them up and see how they deal with with it. It can be very revealing if they don't know what it is, and I'm lucky enough that they try to parse it out.

I've only had one person able to answer it. And interestingly enough, we didn't hire him because of his interpersonal skills. The two that we did hire from that set of interviews both were unable to answer the question but both did try to figure it out.

Anyway, the point is, sometimes, even if the question is germane, the interviewer isn't expecting you to answer the question properly, and not being able to do so won't necessarily rule you out.