interview

Many people doesn’t think that way but interviewing is a skill just like communication or problem solving. In the field of IT it’s specifically highlighted where individuals can be extremely successful even with lacking social skills. I saw many companies making the mistake of putting the best developer or system engineer into the interviewing role which sometimes leads to disastrous results. Why that happens? Top 5 mistakes technically excellent interviewers do 1) Taking it as an exam We all went to school and we have vivid memories about our teacher who had a perfect sixth sense to find the only questions we didn’t know the perfect answer for. Although we shouldn’t repeat that I see it’s happening many times. Interviews should be about what the candidate knows not what he doesn’t. 2) Being hypothetical There are certain situations when it’s benefical but in general hypothetical questions will be answered by hypothetical answers. You need to ask yourself what did I learn from this answer about candidate’s ability to contribute to our team/company. If you don’t find a satisfying answer you shouldn’t ask those questions. 3) Looking for specific answer Another common mistake which can be a subset or result of the previous is that the interviewers ask a very open question which they expect a very specific answer. An answer which may be specific to their position, to the company etc. Do you want to hire somebody who thinks the same way you do or do you want to bring somebody with new perspectives, new ideas to the team/company? You probably don’t look for your clones to work with, right? 4) Trivia questions Once I had an interview where I had to answer questions like what DRY or IDE stands for. In the same situation now I would just ask back: “is this really the knowledge I need to have to be successful in your environment?”. Questions which can be found the asnwers for with a couple of seconds of googling won’t help you get to know the candidate better. In the field of IT experience and mindset is much more important than lexical knowledge. 5) Not having ownership about the process In spite of the common belief...