Dave Fecak has served as the President and Founder of the Philadelphia Area Java Users' Group since 2000. He is an active blogger on software engineering career topics at http://jobtipsforgeeks.com, and author of Job Tips For GEEKS: The Job Search ebook (http://jobtipsforgeeksbook.com) Professionally, Dave has been a recruiter and consultant for 15 years helping startup and early growth firms to hire software engineers (primarily focused on Java/JVM, Python, Ruby, functional languages, and mobile). Dave is a DZone MVB and is not an employee of DZone and has posted 74 posts at DZone. You can read more from them at their website. View Full User Profile

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

  • submit to reddit

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, keep an eye out for my book (mailing list for the release announcement can be found here) and follow Job Tips For Geeks on Facebook, Twitter, or Google+.
Published at DZone with permission of Dave Fecak, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Barry Smith replied on Thu, 2013/02/14 - 8:05am

Actually, "how many gas stations are there in the US?" is probably a poor Fermi question. If I had that in an interview I'd be tempted to pull out my smartphone and Google it - I suspect I'd get a more accurate answer than working it as a Fermi.

Barry Smith replied on Thu, 2013/02/14 - 8:46am

I should add, of course, that the correct response to Fermi questions is to leave the interview and go and look for a job with a company where interviews are conducted by people with a bit more understanding.

The reason is that the interviewers don't actually know what response they want to this question because they have no studies relating the answers to these sort of questions with software development ability. They may think they know. They may believe that working out a sensible estimate to these questions demonstrates lateral thinking ability (or some other half baked cognitive concept they feel is important). But, is lateral thinking related to programming ability? I don't know, and neither do they because no-one seems to have studied it. How would you measure lateral thinking ability anyway and, if you could do that, why not use that test instead of questions which you don't know demonstrate that ability anyway?

Frankly, until someone stumps up some cash for some decent psychological studies, the only test of programming ability is programming. If you want a decent programmer set them a programming task and see how they do and stop messing about with questions you don't know how to interpret the answers to anyway.


Dave Fecak replied on Thu, 2013/02/14 - 10:04am

Barry - Thanks for reading and for the comments.  Negative opinions of Fermi questions were highly anticipated, which is why I included this in the aside

There is a large population that feel Fermi problems are useless in evaluating talent, but their value is not the point of this post.

That said, I'm not sure that interviewers would require any real studies to show whether or not candidates who answer these questions well (by the interviewer's definition) end up being better coders or better employees.  Hiring managers who have been hiring for long enough will have at least their own anecdotal evidence, and good hiring managers will have tweaked their interviews over time to be sure that their results don't include too many false positives.

I should add, of course, that the correct response to Fermi questions is to leave the interview and go and look for a job with a company where interviews are conducted by people with a bit more understanding.

I hear that sentiment quite a bit, and I'm always a little surprised by it.  I wonder how many job seekers actually walk out of interviews because they are asked questions they feel are not a fair way to assess their skills?  Some similar responses inspired another recent post "What If We _____ Like We Hire Programmers ", where I gave some thoughts on what types of questions were appropriate for interviews.  I don't know if there are scientific studies on how well great programmers answer Fermi questions, but I at least give the benefit of the doubt that experienced hiring managers that have been in the game for a while may have some of their own data.

If you are only asking Fermi questions in an interview, I'd say you are probably doing the company a disservice.  But if you are mixing in questions to learn about how one thinks with some other more relevant methods (like a programming exercise), I don't see why someone should be inclined to dismiss the employer.

Thanks for the comments, dialogue like this is important so hiring managers and the talent they covet can come together.

Barry Smith replied on Thu, 2013/02/14 - 11:00am in response to: Dave Fecak

Thanks Dave - I appreciate that I'm going a bit off topic here, but hiring techniques in the IT industry are a bit of a bugbear of mine. Frankly there are only two things really worth doing to assess a programmer and that is:

1) Programming tasks - There is a well established, 100% correlation between the ability to write good code and the ability to write good code.

2) References - you can never hope to get the same insight through an interview process as someone who has worked alongside your candidate for a number of years.

Guess which two things I've never come across in my thrity or so interviews in the industry. Instead I've had plenty of trendy questions and dodgy psychological tests with no empirically established link to technical ability. Frankly I think it would be cheaper to just flip coins.

Dave Fecak replied on Thu, 2013/02/14 - 11:47am in response to: Barry Smith

You are not alone in your feelings about talent evaluation.  As someone who writes almost exclusively about tech hiring, I get many visceral reactions to my posts.  I tend to agree with the two things that matter most, and I might add a third that goes hand-in-hand with the programming tasks you mention - prior code.  If someone practiced writing code for the most commonly used examples in interviews they may just get lucky, but showing code they wrote during their career and some repos would give the evaluator another means to evaluate.

Many of my clients are now doing coding exercises with candidates, whether during the interview or as a take-home assignment afterwards.  I think all of them are at least asking for some whiteboard exercise to demonstrate some understanding of topics as well as the ability to articulate that understanding. 

You may be interviewing at the wrong shops if you are only being asked riddles, or at least shops that may be hiring the wrong way if they aren't even mildly interested in watching you work.

Adam Davis replied on Thu, 2013/02/14 - 12:41pm

I should add, of course, that the correct response to Fermi questions is to leave the interview and go and look for a job with a company where interviews are conducted by people with a bit more understanding.
I hear that sentiment quite a bit, and I'm always a little surprised by it. I wonder how many job seekers actually walk out of interviews because they are asked questions they feel are not a fair way to assess their skills?
I've never walked out of an interview because of "unfair" questions, but I have gotten bad impressions from interviews that used these types of questions. IMO, the danger of asking Fermi questions is the interviewer can give the impression they're trying to show how smart they (or the people in their company) are, instead of trying to learn something about you. To me, an interview is a chance to learn something about where I might work, what I might do there, and what is the atmosphere like there. Fermi questions don't give you any hints about those things -- they just give you the impression that the interviewer knows best, even when they doing non-sensical things.

Andrew Thompson replied on Thu, 2013/02/14 - 1:14pm in response to: Barry Smith

I agree with you in principle.  In practice, these two items aren't terribly practical to use.  Nobody ever includes references that will be critical of them. 

And programming tasks, if done in the office become one of "how fast can you set up your development environemnt" or "can you program in notepad".  And if they're done out of the office, it becomes "what candidates are willing to put 4 hours into applying to my specific job" - which filters out a huge number of people.

Gaurav Saini replied on Thu, 2013/12/05 - 12:47am

Good one… I had a similar experiences and below is how I overcame those.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.