Tagged: phone screen

How to Prevent Crying During Your Technical Interview

endcall

A recent blog post Technical Interviews Make Me Cry by Pamela Fox tells the personal tale of a technologist and conference speaker who gets a Skype/Stypi interview for her dream job, becomes stumped on a technical question, breaks down in tears, almost abandons the interview, fights through it, and eventually gets the job.  Everyone loves a happy ending, and it was courageous for the author to tell her story so publicly as a service to others.  However, I think some of her takeaways and the advice she provides can be improved upon.

So how can we prevent crying or freezing up during a technical interview?

Let’s start with the author’s advice.  She offers that interviewees should prepare for the format and not just the material, and writes
Continue reading

“I Dunno” – Recovering From a Botched Technical Interview Answer, Postmortem

A recent post on Stack Exchange’s Workplace forum posed a rather unique question and perhaps raised a few more.  The post asks if it is appropriate to follow-up with a correct response afterwards if you answered a technical interview question incorrectly (or responded with “I don’t know”).  As a recruiter of engineers, I’ve taken my share of calls from candidates upset about fumbling a tech question that they would have slam-dunked 99% of the time but froze in the moment,  only to have the correct answer come to them while driving home from the interview.  At the time of this writing, there are four answers listed and (in my opinion) at least a bit of poor advice for job seekers.

The posted question brings up a few topics for thought, which will also be detailed in (plug warning) my book.  First, we will cover this specific scenario and the best way to ‘recover’, as well as what is wrong with the answers provided.  Then we will dig a bit deeper into the “I don’t know” problem and reveal the motivations behind technical interview questions and why a simple “I don’t know” (which was recommended by one respondent) is almost never appropriate.

Recovery From A Botched Interview Question, Postmortem

The answer in the forum accepted as the best suggested that it was not recommended to send a correct response as it may make the candidate appear ‘obsessive’, and added that the answer could have been looked up after the fact.  Two distinct points were made, and both were (IMO) not helpful.

If the candidate sends a note resembling “I just HAD to get this off my chest, I’ve been losing SOOO much sleep about that answer I messed up“, then of course the obsessive label may be legitimately applied.  However, if the correct answer is provided tactfully using some careful language, the result should be more indicative of tangible interest in the job than an obsession to be correct.

The mention that the candidate could have researched the answer afterwards is probably irrelevant unless the question was a complete softball that any industry professional must know.  If the question was difficult or perhaps a complex programming exercise in an environment approximate to what the engineer would encounter in the real world, one would think that the test should be open book in order to simulate the office experience.

How To Make The Recovery

  1. Email the interviewer and lead with a standard thank you sentiment.
  2. If there were any legitimate mitigating circumstances that negatively affected your performance, it is relatively safe to mention them (with a slight risk that you are regarded as fragile or that life will impact your work).
  3. Write out the question as best you remember with a synopsis of the answer you provided.
  4. Provide the correct answer and dive a little deeper into your knowledge of the subject.  Be careful not to go too deep (which could risk the obsessive tag mentioned earlier).
  5. Close by reiterating your interest in the position and your willingness to be tested again with either another interview or some exercise (programming task, white board exercise, etc.) that will allow you to demonstrate your ability.

If code is appropriate as part of the answer, write it and send it.  Go slightly above and beyond in your answer if possible by pointing out some other relevant points during your explanation, such as any experiences during your career related to the question.  Results will vary.

Plain “I Dunno” Answers

One of the participants in the thread added

“…’I don’t know’ is a safe answer as many places use negative marking for wrong answers.”

Partial credit for that, but incomplete.  A simple “I don’t know” could possibly be indicated for a specific set of questions, but in general it is better to give a longer response to questions that you can’t solve.  What?  Questions that will typically get the dunno answer usually fall into three categories.

  1. Questions you find difficult, but at least somewhat within the scope of something you could/should know.
  2. Questions regarding incredibly minute and trivial details that you could possibly know, but that most candidates probably would not answer on-the-spot.
  3. Questions about a subject that you have absolutely no exposure to and couldn’t possibly be expected to know outright.

Motivations Behind The Three Types of Questions

Category 1 questions are fair and the only motivation is to discover what you know and what you don’t.  Nothing to see here, move along.

Category 2 questions are probably a mix of items that could conceivably fall into Category 1 or Category 3, depending on the level of the candidate being interviewed.

Category 3 questions along with some Category 2 crossovers are the ones that almost always have a hidden agenda, and it surprises me when I hear a candidate react surprised when being asked “How many gas stations are there in the US?“.

Category 2 and 3 questions typically are asked for one or more of three reasons.

  1. To measure your brainpower and memory (mostly Category 2) – Some employers do expect their staff to have an abundance of knowledge readily available without using outside materials.  With the vast amount of resources used by technologists today, most managers value this ability much less than in years past.  In certain cases, the interviewer really does want to know if you can answer the question asked.
  2. To observe you under duress (both Category 2 and 3) – It can be difficult to simulate various scenarios that happen on a day-to-day basis inside of any particular company.  By asking a difficult or even an impossible question, the employer can get some sense as to how you may function when required to quickly improvise a solution.  Will the candidate admit a lack of knowledge about a subject area or will he/she attempt to feign expertise to potentially appease the interviewer?
  3. To understand your resourcefulness and how you diagnose problems (mostly Category 3) – Questions with no widely known answer are a somewhat effective way to see how a candidate might approach and break down a future real-world problem, or where the candidate would go to find out.  An example would be Fermi problems, where it is expected that respondents will not have an answer in memory but should be able to provide some estimate by using other information that is more widely available.  “How many gas stations are there in the US?” is a fairly common example of a Fermi problem where an immediate numerical answer would be unexpected and defeat the purpose of the exercise.
Aside:  A fourth motivation increasingly cited by interviewees is to measure your subservience or your tolerance for and willingness to even try to answer such questions.  There is a large population that feel Fermi problems are useless in evaluating talent, but their value is not the point of this post. 

Better Alternatives to “I dunno”

A simple “I don’t know” is rarely appropriate.  Try one of these instead.

“I don’t know x, but I do know y” - This answer is appropriate for questions related to specific technology experience.  If you are asked if you have used MySQL, you might mention that you have not but you have used another RDBMS.  This lessens the impact of a straight ‘no’ answer, implying that any learning curve will be less severe.

“I don’t know x, but if you would like I can tell you how I would find out” – This answer allows you to demonstrate your resourcefulness and creativity in solving problems on the spot.  Managers should also value your modesty and the fact that you are not the type of professional that would rather claim expertise than admit not knowing.

If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search helpful.  You can also follow Job Tips For Geeks on Facebook, Twitter, or Google+.

TALK! It’s An Interview, Not An Interrogation

Several times a year I will get a call or email from a hiring manager telling me that an interview never really ‘went anywhere’ because the candidate seemed either unwilling or unable to dive very deep into technical topics.  It can be impossible for an interviewer to accurately gauge whether the cause was a lack of tech skills or just an inability to communicate those skills, but it really makes no difference as the end result is a rejection.  This observation is probably a bit more prevalent during phone screens, where the parties do not have the advantage of proximity and body language to assist.

Whenever I hear feedback like this from clients, I imagine what the interview may have sounded like:

INTERVIEWER:  Have you worked with Ruby on Rails before?
CANDIDATE:  Yes, I have.
INTERVIEWER:  Could you elaborate on that a little bit?
CANDIDATE:  Yes, I could.
INTERVIEWER:  (VISIBLY ANNOYED)

It brings to mind the old joke (which of course reinforces gender and programmer stereotypes):

A wife asks her computer programmer husband, “Go to the store and get a gallon of milk, and if they have eggs get a dozen.”  A short time later the programmer returns with twelve gallons of milk.  She asks, “Why did you get twelve gallons of milk?” and he responds, “They had eggs.”

In the short two question interview scenario above, the candidate is answering the questions being asked, and the candidate is providing all the information that was being requested.  If you look at the questions in a literal manner (as many engineers tend to do), this candidate may not feel he/she is being dodgy at all.  Just as the programmer in the joke did what his wife asked (by his literal interpretation).

Let’s now look at a brief example of a police interrogation:

INTERROGATOR:  Where were you on the night of the 8th?
SUSPECT:  At home.
INTERROGATOR:  Were you by yourself?
SUSPECT:  No
INTERROGATOR:  Who was with you?
SUSPECT:  My husband.
INTERROGATOR:  WHO WAS WITH YOU??!!
SUSPECT:  My lover!  (CUE SCARY MUSIC)

These answers provide the minimum amount of information the interrogator requested, and a lawyer will probably advise you to keep your answers short and precise during questioning.  The interrogator’s job is to get a suspect to say something that he/she does not want to reveal.

A job interview is not an interrogation, and it is important for candidates to be sure they are not treating it as such.

Keep in mind that interviews, particularly in technology settings, can be awkward situations for participants on both sides of the table.  Most interviewers are at least slightly uncomfortable being placed in a room with a complete stranger for the sole purpose of judging him/her in order to reach some conclusion about whether he/she should be hired, a decision which could greatly impact the life of at least one party (the candidate) or even both parties (if the hire is made).  If an interviewer gives even a small consideration that this stranger may have a family that depends on the income that the job would provide, the potential for an awkward exchange is even more likely.

Most interviewers want to get a dialogue flowing, where the discussion will allow them to evaluate your technical and interpersonal skills.  They want to control and moderate the conversation, but they would like to listen more than they speak.  The candidate’s ability to communicate his/her thoughts will be apparent after a few questions.  At some point most interviewers have to ask themselves, “Would I want to work next to this person every day for several years?”  If the candidate answered their questions in a fashion resembling the Candidate or the Suspect in the samples above, the answer is always “No”.

Some candidates may argue that they have answered the questions as asked, and that if the interviewer wanted more details he/she should have inquired for them specifically (“Tell me about Ruby on Rails experience.”).  This is a valid observation, but it doesn’t solve the problem.  It’s purely a function of conversational English, and it is one reason that chatbots with artificial intelligence may give answers like our Candidate did in the example.

So, I’ll just keep talking and talking to solve the problem?  NOPE.  There is also the possibility that if a candidate answers every question with a long-winded response, he/she may be rejected for not being able to provide succinct answers.  Managers are often unwilling to hire someone who they feel is unable to express themselves efficiently, and in the case of software engineers you may hear, “Being that chatty, I can’t imagine what his/her code (comments) looks like!

How do I appear to be open, honest, and transparent without sounding chatty?  How do you avoid being labeled as unable or unwilling to answer interview questions?

  • Don’t take every question literally – Remember that a good interviewer is trying to engage you in a dialogue and an exchange of ideas.
  • Pause before answering – Some candidates seem programmed to immediately start talking after a question is asked, and then find that they haven’t really answered the question.  Taking a moment to reflect on the question and to organize your thoughts gives the appearance that you are making an effort to supply a strong answer and that you are not impulsive.  A little white space does not have to be an uncomfortable silence.
  • Pause after answering –  If the interviewer does not respond with a follow-up after a few seconds, he/she may be waiting for you to go deeper.  Ask if he/she is satisfied with your answer and offer to continue with more information if necessary.  “Would you like some more details on that?
  • Ask questions to clarify what type of answer is expected – If you are asked a question where there could be both an acceptable short answer (yes/no) or a longer answer (details), give the short response and offer the interviewer more.  “Yes, I have used Ruby on Rails.  Would you like me to discuss my experience further?
  • At the end of the interview, ask the interviewer if they have any other questions that will help them make their decision. Invite them to contact you in the coming days if any additional information is required or if they would like any clarification on the answers you provided.

Go into the interview with the goal of having a conversation which should put the interviewer at ease.  Be willing to follow the interviewer into any direction the discussion may take, and ask questions so you know that you are on the same page.

If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search even more helpful.  You can follow Job Tips For Geeks on FacebookTwitter, or Google+.