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
- Email the interviewer and lead with a standard thank you sentiment.
- 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).
- Write out the question as best you remember with a synopsis of the answer you provided.
- 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).
- 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.
- Questions you find difficult, but at least somewhat within the scope of something you could/should know.
- Questions regarding incredibly minute and trivial details that you could possibly know, but that most candidates probably would not answer on-the-spot.
- 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.
- 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.
- 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?
- 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.
Programmers often experience a high degree of frustration during the interview process, and one primary source of annoyance is how the programmer perceives the line of questioning or exercises. In a buyer’s market where supply exceeds demand, hiring managers will often be a bit more selective in evaluating candidates, and talent evaluators may request or require more specific skill-sets than they would if the talent pool were deeper. These tactics are short-sighted but deemed necessary in a crunch.
I recently stumbled on two articles with an identical theme. “If Carpenters Were Hired Like Programmers” was written in 2004, and “What If Cars Were Rented Like We Hire Programmers” was posted very recently. The tl;dr of these posts is essentially that programmers being interviewed are asked incredibly esoteric questions or are grilled about experience with irrelevant topics (wood color for carpenters, car wiring for car renters). The comments sections on Reddit and Hacker News are a mix of agreement, criticism, and various anecdotes about interviews that reflected the articles’ theme. No analogy is perfect.
There are surely companies that are ‘doing it wrong’ and asking questions that will reveal little about a candidate’s potential as an employee, but I’m getting the sense that many candidates are starting to claim that even appropriate lines of questioning and requests are now somehow inappropriate. More importantly, it appears that candidates may not understand or appreciate the true value of certain questions or tasks.
To continue the carpenter analogy, let’s look at the types of questions or tasks that would be both useful and appropriate in evaluating either a carpenter or a programmer (or anyone that builds things) for potential employment.
- Overall experience and training – No one
willshould argue these.
- Experience specifically relevant to the project at hand – This is where we may first see some candidates crying foul, particularly if the relevancy of the experience is judged predominantly by the level of experience with very specific tools. Learning a new programming language is probably not equivalent to learning how to use a different brand of saw, but engineers can sometimes be overconfident about the amount of time required to become productive with a new technology. The relevancy of experience factors into a hiring decision most when project delivery is valued over long-term employee development.
- Answer some questions about your craft – When hiring managers ask questions, candidates should keep in mind that there can be a few reasons why a question is asked. Obviously, one objective may be to truly find out if you know the answer. However, sometimes the interviewer asks a difficult question simply to see how you may react to pressure. Another possibility is that the interviewer wants to reveal if you are the type of person who may confidently give a wrong answer to try and fool the interviewer, if you are more likely to admit what you do not know, and to evaluate your resourcefulness by how you would research a problem with an unknown answer. A genuinely, laugh-out-loud stupid question may be asked to see how well you may deal with frustration with a co-worker or an unruly customer. Lastly, the interviewer may simply want to see your method of approaching a tough question and breaking it down. Candidates that are quick to complain about being asked seemingly minute or irrelevant details often overlook the true purpose behind these exercises.
- Design something – I’m always amazed when candidates call me in a state of shock after being asked to do a whiteboard exercise in an interview, as if these types of requests were either unfair, insulting, or a ‘gotcha’ technique. Anyone who builds things should be somewhat comfortable (or at least willing) to either visually depict a past design or attempt to design a quick solution to a problem on the spot.
- Show us how you work alone – Assigning a short task for someone to complete either in an interview setting or at home before/after an interview is absolutely an appropriate request, which candidates can choose to accept or deny. It is both only an opportunity to demonstrate skills and to further express your interest in the position by being willing to invest time. Providing a bit more than the minimum requested solution is a valuable method to differentiate yourself from other candidates.
- Let’s see how you work with a team – As candidates are often hired to build things collaboratively, a short pairing exercise or a group problem-solving activity could be the best way to efficiently evaluate how well one plays with others.
- Show us some samples – Professionals who build things have the unique interviewing advantage of actually showing something physical that they have built. A carpenter bringing a piece of furniture to an interview should be no different than an engineer offering a past code sample. Companies are increasingly using past code as an evaluation tool.
- References – At some point in the process of evaluating talent, asking for references is a given. Being unwilling or unable to provide references can make someone unemployable, even if all other tasks are met.
If you go back and reread the articles about the carpenter and rental car interviews, you may have a new perspective on the reasons some questions may be asked. Think back on some interviews that you have had, and consider whether it’s possible that the interviewer had ulterior motives. It’s not always about simply knowing an answer.
Failing an interview due to a lack of qualifications is forgivable, but it is tragic when highly qualified candidates do not get an offer due to being unprepared. With the amount of information freely available today, the time and effort required to prepare for an interview is extremely low and a relatively small investment to make in your career.
Typically a candidate will have at least two or three days advance notice to do some research and prepare for any interview. Here is a checklist of things for technologists to investigate to be sure you are ready for what will come your way.
- Company intel – Learn as much as you can about the company, and try to have at least one minute of material memorized to answer the “What do you know about us?” question. Be prepared to present on the company history, the products or services the company provides, details on the business model, and the industry itself (competitors, health of the market, etc.). For technologists, the ability to give an eloquent response to the “Describe what the company does” question is a huge asset that should not be overlooked and could be a significant factor in your success. Gathering substantial information on a young company’s funding status or finances might be difficult, but there will generally be at least some info in press releases from venture partners.
- Tech environment – Get specific details about the technical environment by doing some basic web research, reviewing any available job descriptions or LinkedIn employee profiles, and talking to your recruiter or any appropriate company contacts you may have. What frameworks, languages, databases, operating systems, and hardware are they using? Even if the details aren’t all entirely relevant to your interview, it will show that you are taking this process seriously. Look up any buzzwords or acronyms you don’t recognize so you can at least discover if you may have experience with a related item (“I haven’t worked with ______, but I’m familiar with ________ which appears to be a similar tool/language”).
- Tech moves – Knowing the company’s current tech details is valuable, but knowing about some of the company’s technical history will show great initiative while also providing potential insight into how the company views technology and makes tech decisions. Has the company made significant changes to their stack, and if so, why? Are they heavily invested in open source? Do they seem closely linked to a specific vendor? Does the company have an engineering blog or a company GitHub account for you to explore that might contain this information?
- Interviewer intel – Insight into the technical background and past employers of the individual(s) you will meet is a great advantage, as you may have some similar history. Personal GitHub or Twitter accounts? Technical blog posts? A LinkedIn or web search of the interviewer(s) might turn up some helpful details to use during the interview, as long as you use the info wisely. Showing that you did some research displays initiative, as long as you respect personal space.
- Confirm the basics – Where are you going and who should you ask for when you get there? Who are you meeting with and what is his/her/their role in the company? What is the preferred dress code? (NOTE: Some companies actually ask that candidates dress more casual, so be sure to ask)
- Prepare questions and anecdotes – Most interviews will provide you with at least a brief opportunity to ask questions. Although you ideally want to have these memorized, it is generally a good idea to have some questions listed so you don’t forget them under possible duress. There are also some fairly standard questions in the “tell me about a time when…” family which are commonly answered with anecdotes. Give some thought to past challenges, failures, and successes, and especially what lessons you learned from each project.
- Documents – Some companies may ask you to fill out an application and other relevant documents before the interview. Find out if this is the case and if so get those completed before interview day. Make sure to print out at least three copies of your resume and one copy of your list of questions. Think about who you will list as references if asked on the application, and have their info (name, email) available.
Keep in mind that making a solid impression in an interview is something that can make a huge impact down the road, whether or not you get the job. Interviewers remember candidates who impressed, and they absolutely will remember those who crashed and burned as well. Do your homework and take interviews seriously, not just for the sake of getting this job but for opportunities later in your career.
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?
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.