Why you should avoid faking it, in technical interviews

Original art by Enrico Mazzanti

A long time back, having recently completed my M.S in Computer Science, I walked with some excitement and some trepidation towards the reception of a software company. A few days back they had conducted a phone interview and then called me to their office for a personal interview. Actually a series of personal interviews which lasted the entire day, and taught me an interesting lesson at the end. The day started with a programmer quizzing me about objects, classes, hashcodes and much more for about an hour and a half. The nest interview was with a senior developer who shot design patterns and object oriented design questions at me for another hour or so. I was able to have a little break before the following interview which was a lunch meeting with a manager. After lunch a very senior developer asked me several questions related to software architecture, math, and some logical puzzles.

Sitting in the cab back to the hotel room, I replayed all the interviews in my mind, trying to figure out how well I had done. Were they happy with my skills? Will they make me an offer? I had answered the technical questions fairly well, though I had floundered in a couple of math questions. Overall I think I did well, but I had a nagging, uncomfortable feeling. I had messed up in one place. I had rubbed off one person pretty badly. In the break after the second interview, while I was sitting in their pantry sipping coffee and calming my nerves, the first interviewer walked in with a colleague.

I said "Hi!".

He said rudely "Can you go out of the pantry. I want to discuss something with this guy."

I thought "What! is this guy nuts? Is this how they talk to someone they have called in for an interview?"

I left, but I was visibly angry and made no attempt to hide it.

I never got an offer letter from this company and I have often wondered if the little incident in the pantry had anything to do with it. Maybe it did and then again maybe not. I did not regret not getting an offer, but in retrospect I think I should have been modest, even when the interviewer was rude. I was wrong and I am glad I learned the importance of modesty early in my career.

Since then I have programmed for several software companies and have also interviewed scores of people. Over the years I created a list of red flags and green flags for the candidates I interviewed. Though I must digress for a moment and say that if someone had been angry with me for being rude to them, I would not have held it against them. Anyways coming back to the flags, if a person got more than two red flags then my feedback to the team would be negative even if they answered most of the technical questions well. On the other hand if a person got a couple of green flags then I would give the person ample benefit of doubt even if they were just above average in the technical round. some of the strongest green flags were humility, sincerity, and the desire to think things through and I would have an instant red flag moment when someone boldly gave incorrect answers.

Once I was interviewing a candidate who gave me three incorrect answers, in a row, with absolute confidence. There is nothing wrong in not knowing, but it's absolutely not alright to give wrong answers with such impudent confidence. At the very least a person has to be aware of what they don't know, and be humble and curious about it. I went on with the interview and he answered most questions incorrectly, so there really wasn't much confusion about our decision, but even if he had answered the remaining questions well, I may not have given a very favorable review of him.

Later, in another interview, the developer at the other end of the table was fumbling with some answers. I could sense his sincerity, because he was genuinely trying to reason the answers, and was doing so without any pretense. He was probably a bit nervous, so I offered to get him some coffee, had him relax for a while and helped him with a few initial questions by prompting him in the correct direction. Every time I did that, he took my prompt and reasoned the correct answer. Awesome! I had a very positive feel about him and gave our team a thumbs up for him. Eventually he was given an offer, which he accepted. He joined the team, did great work and proved to be an excellent team worker as well.

It's almost become a cliche and you have probably heard it a countless times - "Fake it till you make it". My suggestion to you is - please disregard this advice if it prompts you to confidently fake an answer you don't know. There is nothing which puts off an interviewer more than someone who fakes answers with confidence. Most interviewers will not hold a positive view of misplaced confidence, they will instead see such a person as arrogant, having an incorrect and inflated sense of their capabilities, and a bad team-player. So what should you do if you don't know an answer? Should you just say you don't know it. I think it depends. If you are absolutely clueless about what the interviewer is asking, it's best to say you don't know the answer, but if you know a little bit, tell the interviewer that you are not certain and would like to think aloud and derive the answer. Most people will appreciate your attempt, because after all they want to hire someone to solve problems. By sincerely trying to derive an answer you are demonstrating, to them, how well you can think. You just have to be careful to do it with sincerity, without pretense, and with some presence of mind.

For example, if you are asked the following question in an interview: "What exactly does ORM mean and why would we use an ORM tool in our project?"

If you have never even heard the acronym: ORM, before, then it's safest to say

"I'm afraid I don't know what it means."

But remember! don't say it flatly, say it with curiosity. Say it as if you would like to know what ORM means. If the interviewer takes the cue, make an effort to genuinely understand her explanation or hint, and try to build on top of it.

Instead, if you have a vague idea that ORM has got something to do with databases and mapping the database schema to objects, but are not sure why it is used, then say exactly that.

"I have heard of this term being used in the context of database programming. I believe it maps the database schema to an object hierarchy. I don't fully understand the concept in detail, but if you don't mind I would like to think aloud about what its advantages and disadvantages might be."

Most (good) interviewers will allow you to think aloud and some might even help you along the way. What they will judge you for now is your honesty, your desire to think things through and your ability to make connections between what you know and what you are trying to deduce. If you do a good job here, your lack of knowledge will not only not matter, but you will actually be seen in a more positive light. Don't think of this as a substitute for knowledge. Knowing is important, but given basic facts being able to think things through is even more important.

And off-course if you know the answer then just explain it as well as you can and impress them with it.

The next time you are in an interview, remember that honesty counts more than boldness, and the desire to think things through counts more than just honestly saying you don't know the answer!