What not to do in a job interview

I've interviewed several candidates over the years and there have been things I've noticed first hand that has turned me off from a candidate.  Along with these first hand experiences, I'll add in things I've heard from other job interviewers, HR personnel, recruiters, hiring managers, etc. to hopefully provide a list of several things you may want to avoid when attending job interviews.

Not only have I sat through countless interviews on my own as an interviewee, I've also been on the other side of the table as an interviewer.  Out of those experiences, some have been of the panel variety with 3 or more people, some were just me and the hiring manager and some were just me and the candidate.  Along with my own experiences, I've talked to quite a few HR personnel, recruiters, hiring managers, as well as friends in the role of interviewer.  Here is a collection of what I've heard or experienced over the years that has hurt a candidate's chances.  Granted, what one interviewer considers to be annoying or a strike against the candidate may not be the same to another, but I think you will find most of these would be agreed upon.

First and foremost, please, turn off your cell phone!  I sat in an interview where a candidate placed his cell phone on the table, which I would suggest is a mistake itself, and it rang on 3 separate occasions in the middle of the interview.  It was extremely distracting and annoying.  At least 2 of us in the interview room felt it was disrespectful and at least 1 person wanted to disqualify him over that alone stating, "If he couldn't put his cell phone away during an interview or he didn't think the interview was more important than his cell phone, what happens after he gets hired?"  I've heard other interviewers over the years tell similar stories, so my recommendation is to ensure you mute your cell phone and leave it in your pocket, purse, or car.  Placing your cell phone on the table would translate to some as your cell phone is more important than the event and that's definitely not an impression/perception you want to leave interviewers with.

I've been guilty of this one myself.  Try not to use the same real life example for everything.  Be ready for the typical questions of explain one of your most successful projects, what project had the most challenges and how did you overcome them, and describe a time when you were a "self-starter."  Have at least 2-4 good projects in your head you can pull out at a moment's notice to answer these types of questions.  While coming up with these projects, try to think of explanations/examples that fit the job duties if possible.  There are times where you are interviewing for a first time role and may not have examples that fit the job duties, such as working in the help desk for 10 years and now interviewing for a SOC analyst, which is okay.  If you have performed the duties listed in the job description prior or can mold examples to fit those duties, it would really benefit you.  If you do not have any examples or projects to fit the job duties, try to use examples that showcase your ability to learn quickly, your work ethic, and/or highlight being a team player.  Just try not to be a "broken record" by repeating the same story/example for every question/situation asked.  Again, this is something I've done myself, so I know it's easy to do.  Seeing it as an interviewer is where you notice how using the same story does hinder a candidate some, because when a candidate has multiple examples/stories it is more helpful for them to do their "sales pitch" of themselves.

Make sure you aren't deflecting instead of answering the question(s)  I never really thought about it, but after seeing it in an interview it is something you easily notice....or at least I did.  Let me give an example.  One of the questions I ask a lot in interviews is something to the effect of, "If you see an alert in the SIEM or receive an alert from the MSSP stating an endpoint in the environment was being attacked for a known vulnerability, what would you do or what process would you follow?"  The candidate I experienced this with said something to the effect of he would handle the easy stuff first and then he deflected to some project he had referenced several times previously in the interview.  The deflection, or project he referenced, had nothing to do with the question.  It might have been a case of him not knowing the answer or wasn't familiar with the topic.  Not knowing is okay, but just say you don't know (more on this in the next paragraph).  In this case instead of him saying didn't know, he said he would handle the easy stuff and then deflected, or switched the subject, by speaking about an unrelated project he had already referenced in the interview.  Not sure if he thought I would forget about the question or if talking about a successful, although unrelated, project would get him credit for a correct answer.  To be honest, I sort of felt like I was talking to a politician who didn't want to answer a question.  This is also a good example about using more than one project or real world example in your interviews.

You may need to analyze your interviewer to determine if this is relevant, because this is very subjective.  If you don't know the answer to a question, some would recommend saying you don't know and you would have to research.  Several people have said they would caution people from throwing out random answers hoping they are good enough or in an attempt to fool the interviewer.  In most infosec interviews, the interviewer will know the answer to the question or at least know what they are looking for.  If you think you know the answer, then of course give the answer and explain your reasoning.  If you know for certain you do not have the answer, it may be best to avoid randomly guessing.  Again, several have suggested saying you don't know and would have to research it or possibly say you don't have experience with that topic, but could get up to speed quickly.  Those answers are far better than being severely off base.  Again it is all subjective, but from most people I've talked with they said they would much rather hear someone say they don't know, but could learn quickly rather than hearing an outrageous answer.  I'm not trying to scare you, but I've seen candidates throw out answers when it is clear they don't know about the topic and most people would rather you be honest by saying you don't know.  There may be some people that would rather have a guess, but I think a lot of people in infosec would view a far off base answer worse than not knowing and admitting it.