How do you deal with Knowledge based questions in interviews?

Question

In technical interviews which interviews experienced programmers , the interviewers ask a lot of knowledge based questions . [eg. Like how to configure this and that in the xml] . These questions have exactly one answer and it is very likely that a good programmer may not know the answer to it (and hence get rejected) . Is there a good way to respond to these questions ? [Like politely telling the interviewer that the answer is just a google search away].

Answer 1

I think it should be OK to tell the interviewer that you honestly don't know the answer, and then proceed to tell them how you would find out (such as ask coworkers, consult the manual, search the web, etc...). This should show the interviewer that you are resourceful and adaptable to new situations and willing to learn - and also honest about admitting when you don't know rather than try to bluff and fail. I haven't had this experience personally, so I'm not 100% sure how it would work, but I'd accept that sort of answer if I were the interviewer. Good luck!

Answer 2

My favorite type of interview question... My typical response if I don't know the answer off the top of my head is to say as much, but then proceed to describe how I would solve the problem.

For example, "What's the API call to Shazbut the Fuzzer?"

Answer, I would go to the "Fuzzer" API docs online, and find out. To be fair, I haven't used "Fuzzer" but I've used "Fubar" which does the same thing. We used Fubar in our last project because of X, Y, and Z.

This type of approach demonstrates a number of things:

1. You have more than a casual understanding of the problem
2. You know how to find answers (Howard Hughes didn't know all the answers about aviation, but he had a team of people who did)
3. You understand that there are alternatives and reasons for choosing one over the other.

If I were the interviewer, I would want someone with the more complete knowledge than someone who could spout off the answer.

If it's a question that doesn't sound correct, I'd mention that too. Sometimes you get people who want to trick you--maybe it's to see if you are paying attention or if you are going to spout off an obviously wrong answer like you are the authority on it. Using the same hypothetical question, you might have an answer something like this: "This is the first time I've ever heard of that. If you don't mind, where can I find out more information about it?"

This tells the interviewer that you aren't going to pretend like you know something you don't, but are willing to learn. Whether you take the time to look up the Fuzzer API on your own is up to you.

Answer 3

I think it's important in an interview to be able to demonstrate how you handle being confronted with the limits of your knowledge. Your employer is going to want to be able to dump a 200-page document on a technology you don't know, and expect you to become the resident expert on it.

When I interviewed for my current position, I hadn't written any C++ in the several years since college, and admitted as much. When someone wrote class A : public B as part of a whiteboard question, I couldn't remember which was the base class and which was derived, but after asking the interviewer about the syntax, I was able to successfully answer the question based on my knowledge of the underlying concepts, and was offered the job. On the other hand, someone who claims to have been programming in C++ every day for the past 5 years should know that syntax off the top of their head.

However, even someone who uses a particular language all the time, may be rusty in certain areas you might not expect, but should have a good reason for it. For example, I do embedded programming, and haven't written code to open or read from a file in a long time, or get input from a user, or query a database, or draw a GUI. That doesn't mean I couldn't reacquire those skills quickly, but I should be prepared to demonstrate the ability to do so, and not just expect them to take my word for it.

As another example, in a previous job, all our memory had to be statically allocated, to make it easy to prove maximum RAM requirements for ultra-reliability. In the rare exception it wasn't feasible, you had to get a peer to sign off on it, and the memory could never be freed. I got very good at avoiding dynamic allocation, but that's not the same thing as being good at doing it.

If asked a question about those areas, I would admit I was rusty, and give the reason, then proceed to answer as best I could recall, asking clarifying questions as necessary.

Answer 4

I am ambivalent about them. Part of me dislikes how trivial many of them are ("what is the 3rd parameter of the Print function") but I also recognize that if someone works with a technology, over time you've seen it so many times you know it by heart. I'm quite willing to say "I don't know, I'd google it before bothering my coworkers about it." On the other hand, if you answer every question with that same answer, it gives the impression that you don't know the technology and are going to google everything - including the code you allegedly wrote.

I work with .NET. Early versions of the framework had over 40,000 different objects. No one can possibly know them all.

Answer 5

I've had this happen to me during a phone interview where I was presented with a question involving a BASH utility I had not used before. I explained that while I had not used it before, I was confident I could after checking Google or its man page.

Being a phone interview, the interviewer quickly put me on the spot by asking if I was in front of a computer and asked that I do just that. A few moments later I was able to give a clear explanation of how it could be used to solve the problem presented.

A short while later, they offered me the job.

Answer 6

I've had an interview or two like this and I can understand that it can make you feel uncomfortable. It's usually when an employer is touching on some technology that I have on my CV/Resume that I've not used for a good year or two.

I answer it by giving them the understanding of the technology they ask and how it's applied, when it's applied, and when it's not applied. The technical side, I will try my best to answer, even half an answer is useful to them, and reassure them that yes if I was at my PC, Google would help and that the technical answer is nothing but a minute or two to delay in carrying on with work.

All in all, I think an interviewer can ask enough questions to know if you have the calibre for the job and how much of a risk you are to them.

However, if you did indeed answer every technical question incorrectly, or got a very obvious question like, how do you declare a variable on language X, wrong, then that would be very worrying to them, and they will feel they don't have the time to invest in you getting up to speed or training you on fundamentals.