How NOT to Run an Interview

Ego is a Good Thing. But the interviewers need to remember that interviewing a candidate is not about how great the interviewer is; it’s about understanding what the candidate will be able to do for you at work. Thanks to Rohan Kini’s “Scary interviews”, read Tips to technical interviewing.

I don’t buy tip 4/5, where Vikram says to explain the process and questions, and not to start with the hardest question. “It depends.” If the hardest question is an elimination question, ask away. You don’t have to explain your questions, but you should explain if you’re asking a behavior-description question, so people can understand you’re looking for specific examples.

5 Replies to “How NOT to Run an Interview”

  1. This is why a lot in the software hiring is silly. I wish only trained hiring professionals like yourself should do it. As a java developer, knowing static inner classes is pretty common knowledge but you may be flustered in the interview and not know exactly what the interviewer is asking. Plus, something as nitpicky as static inner classes, which in Java practice is usely avoided for design considerations, this shouldn’t popup randomly in an interview session.
    I guess you have to weed out candidates who don’t know how to do the job, but want $75,000 a year. Hmm, for a software developer, a programming language is like a tool, if he can describe his tool with almost uncanny detail, I think you have a pretty good developer. If 95% of his description of how he uses his tool and what are best practices and trade-offs in using other tools. You have a win. It would be kind of like a race-driver who knows his car and is passionate about the car? If he is like “Bah, my car, it is a thing with a steering wheel and 4 tires?”, this person doesn’t know his tool, probably ineffective.
    This may fit into “Too generic a question”, but if you focus on the particular tool that the person works with on a daily basis and how their eyes light up or don’t…
    If you are web applications company and you ask, “What
    http://software.ericsink.com/entries/No_Great_Hackers.html

  2. I think that any self-confident good developer knows that being eliminated because you can’t give the answer the interviewer expects to such open questions just means that it’s not a company worth working for.
    Would you really want to work WITH those guys ? Unless I really was in the pits, I would probably have walked out of the interview and put them back in place

  3. Berlin, while I don’t recommend candidates be obsequious, I do recommend that both the candidate and hiring manager treat each other with respect. Your essay, while a bit tongue-in-cheek doesn’t help you develop a partnership with a hiring manager. And I believe candidates find a great fit with hiring managers because they create a partnership.

  4. So, asking, “what do you think is the effect of making an inner class static?”
    There are many good answers. 1) You don’t have to do that wierd looking outer class new stuff. 2) It is more like C#’s nested class. 3) We don’t use inner classes as a policy, just like we didn’t allow friend classes in C++. 4) I don’t know, I have never designed any code that required an inner class.
    If the “interview” is real, then I would say that they had already decided not to hire the interviewee before they got there and they were creating a situation where they could say, “See, I knew he wasn’t any good, but my friend Sally that is coming in tomorrow is sharp!”
    You can’t burn bridges as the interviewee, but the truth is the bridge was burned no matter what was done. There may have been some satisfaction in getting up in the middle of the interview and tell them “Clearly from your tactics and behavior I wouldn’t want to work with you.” But, alas, we are not to be interviewing for our own satisfaction.

Leave a Reply