A few years back I was interviewing someone for the position of a junior Java developer. As always I started the interview with some random small talk: traffic, weather, coffee - the usual stuff to break the ice and help him get comfortable. The real technical nitty gritty started soon after we had cursed the traffic and praised the weather.An interviewing technique I learned long back from a friend is to begin the technical part with a discussion of the candidate's recent projects. It helps the interviewee because he gets to start with something familiar and it helps me by providing a context for his real life work. He described the project and his role pretty well, but he seemed to talk a bit too quickly, as if he wasn't pausing to think. 'Perhaps he's got a fast mind', I thought to myself. I asked him a few questions related to the project and his answers were equally rapid.Next, I moved to the list of technical questions. The first set of questions were related to beginners level object oriented programming - stuff like the difference between a class and an object, polymorphism, method overloading, etc. He answered them quite well although I still noticed that he wasn't pausing to think. 'Perhaps he knows this stuff like the back of his hand', I thought.The next question was related to java.lang.Object and the role it plays in Java by being a parent of every other class, as beginners level questions gave way to the intermediate level. As had become the pattern, pat came the answer. But wait! The answer was wrong. I was a bit surprised because I was expecting him to do well with this question based on his previous answers. But what surprised me even more was the speed and confidence with which he had just answered. A wrong answer is bad (although not terrible because even experienced developers sometimes fumble), but a wrong answer delivered with such speed and confidence is a huge red flag. 'Perhaps he did not understand the question properly', I wondered. I repeated the question, wording it slightly differently and with more details to eliminate any misunderstanding. He looked a bit incredulous and shot back the same answer. 'This is not good', I thought. The initial questions were mostly bookish. Anyone who had read a book on object oriented programming or browsed through a few interview websites would have been able to answer them. This question, however, was a little different. Not that it was very difficult, but it was not to be found in books, and It needed at least a little bit of thought. He should have at least stopped to think when I asked the same question again. Even though we were early on in the interview it raised a very big concern in my mind. He was too quick, too glib, too confident.Overall his answers were a mixed bag. Some were correct and some were not, but characteristically everything was answered rapidly and with supreme confidence. He thought he was impressing us with quick answers, but the effect turned out to be quite the opposite. Every rapid but wrong answer worked grossly against him. Not because it was wrong but because it was delivered without any fore-thought.Very often candidates think they can impress interviewers with quick and glib answers. They are wrong. It's usually well thought out answers that impress. If the reasoning behind an answer is solid then even a wrong answer can work in your favor because it shows the interviewer how you think.Anyone who has ever build software knows how much damage a glib, over confident developer can wreak on the project. Building software is not a 100 m dash and we are not looking for the fastest gun. It's more like a marathon and we are looking for people who have a solid and careful thinking process and a reasonable amount of patience. The next time you are in an interview be sure to pause and think well before answering anything which is non trivial. You won't lose any points for being thoughtful, but you certainly will for not thinking properly.