28

I had a technical interview with a prestigious company and I did quite well during all the questions and the interviewer seemed pleased with me ... but after the interview I noticed that the code I wrote had a bug (not a very big one but still). I spotted the errors a few seconds after leaving the interview.

Would it be a good move for me to also include an "errata" into my thank you message to the interviewer? I would include it as a "post scriptum", or should I write it as a separate message so that my email does not look too long?

Personally I am the kind of person that will be bothered by leaving my solution as is. But I do not want to jeopardize my chances by sending an errata if it is considered a bad thing.

UPDATE: So to conclude my story. In the end I sent the errata and it was received well and I was accepted for the next "phase" of the application process within that company. To give more context, we are talking about a american company with footholds in may countries. It is well known for the quality of its recruiting process too and the quality of its engineers/programmers. I, of course, shall not give you the name of that company.

Thank you all for your answers.

migrated from programmers.stackexchange.com Aug 6 '13 at 11:11

This question came from our site for professionals, academics, and students working within the systems development life cycle.

  • 13
    Personally I would give you bonus points for pointing it out. It shows you care about your work. Every developer knows bugs happen and the fact that you wrote one is less important than the fact that you noticed and corrected it. Also, don't send it as a PS, though not as the first thing either. Simply make it part of your thank you note as an "by the way, shortly after the interview I noticed that... " – Marjan Venema Aug 6 '13 at 10:26
  • @gnat I have seen all questions until page 10 and couldn't find one. – le_douard Aug 6 '13 at 10:37
  • 2
    I already did that. Returning home after the interview, I just noticed one of my answers was wrong. I call the interviewer, and said if I could send the correct answer soon as I got home. I don't know what the interviewer thought, but I sent the correct answer and was approved. (In the end I declined the offer...) – RMalke Aug 6 '13 at 11:23
  • 1
    I wouldn't write about the mistake only if it is something very small (like a typo) or something that could be slightly optimized (like re-arranging if-else clauses). – superM Aug 7 '13 at 9:54
  • It might come across as obsessive and pedantic in the worst case, and won't make any positive difference, so leave it be. – pmf Jan 26 '18 at 12:22
26

Personally I am the kind of person that will be bothered by leaving my solution as is. But I do not want to jeopardize my chances by sending an errata if it is considered a bad thing.

If this is the way you feel and this is the way you are, I think it's dishonest and ultimately counter-productive to hide it. These are the people that you're potentially going to work with for years or even decades.

Trying to conceal or suppress your character traits will end up making your and the people depending on you unhappy. If you consider this is a negative character trait (personally I believe the contrary), that you would like to work on, then just say that. Or if you feel slightly awkward about sending errata, you can also express that - doing something uncommon (which this would be) without acknowledging it, may also give the wrong impression.

Communication is important. If you manage to be open, friendly and concise, you're doing it right ;)

16

I can't speak to the UK experience, but as a professional programmer and a manager of geeks here in the USA, I can say that it would be unusual. How the hiring manager will respond is likely to be a very personal issue for them. Myself, I'd see it as a mostly-good indicator - the candidate may be a little too fastidious, but he recognized a problem and called attention to it. I'd suggest you think about the specific person you're addressing and try to see it more from that person's perspective than from a general case.

  • 1
    Honesty and integrity are key traits here in the UK, and sending a correction in or recognising a problem would be considered as a sign of integrity. – James Snell Aug 6 '13 at 12:29
  • Honesty and integrity are important in the US as well. I don't see that sending in a correction has either of these attributes. – Beska Aug 7 '13 at 11:43
11

Send your thank you email and include the code fix with a small explanation. They can choose to ignore it.

Personally I am the kind of person that will be bothered by leaving my solution as is.

If this company considers this inappropriate, you probably don't want to work there. As programmers, we often compromise our standard of "good enough" by external constraints, so why impose this on yourself? To me, all programmers or any other professional who creates and fixes things for a living, should have a bit of an aversion to mistakes, but not to the extent you paralyze your productivity.

  • 3
    I think this is the right answer. I've been on the receiving end of one of these - and while it was unusual, I viewed it as a positive thing. It communicates "this is a thoughtful, thorough person". – Ben Collins Aug 6 '13 at 21:57
3

You should discuss the bug - but not necessarily fix it - in a followup thank you email. Don't take too long with the followup.

If you send a short email discussing the bug before they make a decision, it can help you. If you send a brilliant email fixing they make a decision, it will be too late.

Also if you fix the bug, then you might create a new bug, which won't help you.

  • This is worded a little weird. You meant "don't take too long sending the followup", but you said "don't fix the bug". He said it's a minor bug he noticed as he was walking out, so he probably already has the fix – Michael Mrozek Aug 6 '13 at 20:57
  • 1
    In my case it is an important one liner, breaks the function though, but is fixed very obviously. But I like this answer because sometime you might need to overhaul the code you gave and it is true that the more lines you write the more bugs you might introduce again. I will definitely bear this in mind if I am in a situation where the mistake is on a broader stroke kind of question. – ɭɘ ɖɵʊɒɼɖ 江戸 Aug 7 '13 at 7:37
  • @MichaelMrozek I agree that my wording was poor. I still think discussing the bug is more important than fixing it. If you just make a one line fix, I don't care. Tell me why your one line fix is important, what bad things will happen without it, etc. Why should I care about your fix? – emory Aug 9 '13 at 16:38
2

My experience is that such interviewes are to get a gut feeling for your tech skills. A follow up would probably not change your chances as such since real world situations differ much from interview setups.

However, sending the errata will make you look more like a perfectionist. If this is good or bad depends on your employer, if they earn profit by "quick n dirty" or "perfect".

  • 2
    Knowing who is the potential employer that actually reassure me. They are known for coding excellency. Thanks +1 for the morale relief. – ɭɘ ɖɵʊɒɼɖ 江戸 Aug 7 '13 at 10:24
0

Recognizing your own flaws is a skill that no employer should undervalue. When you recognize flaws in your code before it is pointed out, it is a skill to be appreciated.

You can be pretty sure that you will not be the first programmer to write flawless code and how good you are at identifying your own mistake, is basically how small your own blindspot is.

There is one thing that goes deeper here though. How does your employer react to your own flaws that you point out yourself? Will you be punished? Or will you be rewarded for fixing mistakes? Successful companies encourage you to fail often and fail fast. In other words, this is a great opportunity for you to test how your employer responds to mistakes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.