Giving interviews is hard.
I used to think interviews are a breeze, but this was before realising that "being yourself" in an interview is not an optimal strategy. Till date I'd been fortunate -- for the most part, my interviews had been conducted by somewhat like-minded people. In such situations, being "true" to oneself works quite well.
However, the trick is in sizing up precisely what the interviewer is looking for, in asking the questions that he is. The response then needs to be tailored to match the interviewer's expectations -- not the role's. and not the organisations, even though they should ideally be aligned.
In the case of a question looking for a factual answer, while the core of the response can stick to the facts, the language it is couched in can make a big difference (firm? conciliatory? with gusto? with a sense of distaste?). This also applies to the length and approach of the answer (curt? concise? rambling? detailed?).
Of course, the most correct, internally consistent, and confidently stated responses won't do you any good if the initial read on the interviewer is completely off-base. If your approach to validate a hypothesis is Bayesian when the interviewer is a fanatical frequentist, it may not matter at all that you were entirely right. Back in the day, expounding the virtues of JSP in an interview where the interviewer was an ardent PHP fan didn't work too well.
If you aren't applying to roles that are clearly out of your league (claiming knowledge of a tool or technology that you've only read about, or only dabbled in), then the associated interview should be a piece of cake. But humans being what they are, and ridiculously susceptible to biases, the best strategy for an interview is always to get a read on the interviewer(s) and manipulate said biases in your favour. If you're unable to do this -- ceteris paribus -- the chances of making it through the interview are entirely 50-50, which is really quite low.
I used to think interviews are a breeze, but this was before realising that "being yourself" in an interview is not an optimal strategy. Till date I'd been fortunate -- for the most part, my interviews had been conducted by somewhat like-minded people. In such situations, being "true" to oneself works quite well.
However, the trick is in sizing up precisely what the interviewer is looking for, in asking the questions that he is. The response then needs to be tailored to match the interviewer's expectations -- not the role's. and not the organisations, even though they should ideally be aligned.
In the case of a question looking for a factual answer, while the core of the response can stick to the facts, the language it is couched in can make a big difference (firm? conciliatory? with gusto? with a sense of distaste?). This also applies to the length and approach of the answer (curt? concise? rambling? detailed?).
Of course, the most correct, internally consistent, and confidently stated responses won't do you any good if the initial read on the interviewer is completely off-base. If your approach to validate a hypothesis is Bayesian when the interviewer is a fanatical frequentist, it may not matter at all that you were entirely right. Back in the day, expounding the virtues of JSP in an interview where the interviewer was an ardent PHP fan didn't work too well.
If you aren't applying to roles that are clearly out of your league (claiming knowledge of a tool or technology that you've only read about, or only dabbled in), then the associated interview should be a piece of cake. But humans being what they are, and ridiculously susceptible to biases, the best strategy for an interview is always to get a read on the interviewer(s) and manipulate said biases in your favour. If you're unable to do this -- ceteris paribus -- the chances of making it through the interview are entirely 50-50, which is really quite low.