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

  • 10
    One or two questions like that are okay, but if the majority of the questions is like this, you should seriously consider if it is the right company for you.
    – biziclop
    Commented Feb 28, 2011 at 16:44
  • possible duplicate of What to say when you don’t know the answer to an interview question? Commented Feb 28, 2011 at 18:53
  • @biziclop That is how more than 90% of interviews are conducted in India. I believe it has more to do with how good a programmer the interviewer himself is than about how good the company is.
    – Mugen
    Commented Aug 18, 2011 at 10:24

6 Answers 6


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!

  • 3
    I wouldn't be asking those questions in the first place if I were the interviewer :)
    – Carra
    Commented Feb 28, 2011 at 16:35
  • @Carra: Also a good point, but it might help to see just how a candidate thinks in terms of how to handle a task that they are unfamiliar with. If you wanted to be really sneaky, you could ask them how to use a tool/system that doesn't even exist, and see if they pretend to know... mwahahaha... but yeah that might be kinda mean. Commented Feb 28, 2011 at 16:47
  • 1
    How about them trick interview questions almost no-one seems to know the answer to like: "In SQL, when you compare TRUE with NULL, what is the result?" Answer: "NULL". I have yet to find anyone who knows this one at interview time, but I was asked it once. Commented Feb 28, 2011 at 16:56
  • @Berin Loritsch I knew that, but only because I spent a happy afternoon tracking down a bug that was caused by NULL not being comparable with anything.
    – biziclop
    Commented Feb 28, 2011 at 19:14

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.

  • IF I were to do an interview I would always throw in one question for which the response is "I would look it up and do so by going to <X>"
    – Zachary K
    Commented Feb 28, 2011 at 16:56
  • I really don't have a problem with that. The point of my answer is that there really is more than one way to acceptably answer the question. Commented Feb 28, 2011 at 16:59
  • Upon reading your example, my first reaction was "who the heck is Shazbut the Fuzzer?" :-) Commented Feb 28, 2011 at 17:39
  • 1
    Some of these interview questions sound just as crazy. Commented Feb 28, 2011 at 21:08

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.

  • "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" - I believe that is not the state of things in India. There are too many people applying for the same post and the second you utter something like this you are out. One has to be really competitive to survive here.
    – Mugen
    Commented Aug 18, 2011 at 10:49

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.


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.


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.

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