So I had a technical interview and the interviewer asked me a question which can have multiple answers. I came up with a solution and explained it to him but he had another solution in mind and didn't accept my solution even if I gave him logical reasoning behind my approach. I wasn't 100% confident because I just came up with the approach and I had no background of the given problem.

After the interview I confirmed that the solution that I came up with is perfectly acceptable and one of many solutions. So should I mail him back with proper references that my solution was correct? Is that a good practice?

If I don't do this, I'm afraid I might be rejected because of this and after rejection there is no point mailing him.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Kilisi
    Commented May 7, 2021 at 12:53
  • 2
    My first job interview I got the job. 6 months later my boss mentioned to me that in one of the questions I found a loophole that simplified the question significantly, and he'd changed the interview question because of my answer, to close the loophole :) so you may find they hire you anyway.
    – stanri
    Commented May 7, 2021 at 15:18
  • 2
    Are you sure him "not accepting" your solution to a multiple answer problem wasn't part of the interview? To see how you handled adversity? Being able to handle a solution you don't agree with gracefully is an important part of being in a team...
    – WernerCD
    Commented May 8, 2021 at 4:10
  • 2
    @WernerCD The problem with interpreting mind games questions is it can go the other way too. What if he's testing how resolute the OP is in his opinion that he knows is right or if he will just be a yes man to superiors?
    – Jack
    Commented May 8, 2021 at 13:15
  • 1
    I conducted tons of interviews for many companies. Some with good colleagues, some with less good colleagues. One common thing, though, is that everybody I ever partner with to give an interview knew the problem in and out. Throughout, in depth. Why? Because there's no way you can handle giving an interview otherwise. So, what gives me pause is how to reconcile "he had another solution in mind and didn't accept my solution" with your story. So either there was an important flaw in your solution, or you just spot a big red flag for this company.
    – Jeffrey
    Commented May 9, 2021 at 1:41

10 Answers 10


The chances of this helping your situation are slim to none. Depending on how the e-mail would be worded it could even significantly hurt your chances.

If it was just one of many questions I wouldn't worry about it too much. If the rest of the interview went fine and you did show a general knowledge in other situations I'd be somewhat surprised if they rejected you for just that one question.

From the little knowledge I have in hiring people. Even in a technical interview, I'd be more interested in your communication skills and how you attempt to solve a problem, rather than you knowing the answer or not.

In this case it's best to just wait and see what happens.

  • 36
    Sometimes the point is to see how the candidate defends their solution and reacts to criticism more than whether they got the “right” answer.
    – ColleenV
    Commented May 6, 2021 at 14:50
  • 5
    @ColleenV If, after an explanation of the reasoning the interviewer still insisted the answer was wrong. There's not a lot more to do other than arguing, something you'd never want to do. OP also stated that there was no real criticism or explanation why the correct answer is what it is. If it was the interviewers plan to gauge the criticism response in that manner, it was a pretty bad way of doing it.
    – skippy
    Commented May 6, 2021 at 15:16
  • 3
    I was speaking more generally than about this particular situation. I did upvote your answer—I was just adding an additional thought, not criticizing.
    – ColleenV
    Commented May 6, 2021 at 15:23
  • I think your point is true in a lot of cases. However, I interview people all the time and if I got a POLITE email stating something like "Hello, I thought about the problem we discussed in the interview more, and the x approach we took MAY be correct BECAUSE" would sway me to reconsider. Another thing to keep in mind though is that we usually give feedback from a technical interview IMMEDIATELY, so it would be a lot of effort for the tech guy to pass it back up the chain.
    – VSO
    Commented May 7, 2021 at 17:58
  • @VSO While it might work for you, even then one or two differences in how the mail is written or even just having a bad and busy morning while reading may change how that mail is received so even if you have someone who it might work for on a good day your chances are not great. And purely a feeling of mine. If they refuse to explain on the spot, they'll probably won't appreciate you pushing your answer.
    – skippy
    Commented May 7, 2021 at 21:25

It seems to be a little-known fact among society but lots of problems have more than one solution. Maybe telling you your answer was wrong was the test. Sometimes employers are looking for you to push back and say "Look. My answer is also correct and here's why..." or maybe they were looking for you to entertain the possibility of the interviewer's answer and consider that it may be the better way to go.

They're gauging your response to a certain stimulus. They want to see how you handle the situation because similar situations likely arise on a regular basis in their workplace and you'll need to be able to handle them effectively. In many cases, this necessitates being an exceptional improv artist in order to handle unexpected situations with grace.

It just depends on what they're looking for and this is why it helps to research the employer as much as possible beforehand or have experience in the industry. If you have no idea what they're looking for it's nearly impossible to come up with an acceptable response. You need to ask yourself how somebody in this role would handle the situation and research/experience certainly helps you figure that out.

  • 2
    A technical interview is kind of a bad place to do a "personal interaction test", but it's definitely possible. They may want to see if the OP will nag them about their own correct solution, instead of taking feedback and learning. If this is the case, sending an email is a Very bad idea, as they don't want people always "lawyering" why their code is correct when a code reviewer said it wasn't. Commented May 6, 2021 at 22:39
  • 1
    @computercarguy, Solutions to coding technical interview problems are usually judged on two criteria: time complexity and space complexity. In most cases, find a solution that works is simply not enough. You need to tell which solution is the most efficient one, time-wise and space-wise. Since the OP only talks about the logic of his solution and not its efficiency, I'm assuming this is the reason why the interviewer preferred another solution to his. See my answer for a longer explanation. Commented May 7, 2021 at 5:08
  • 1
    This. And sometimes, discussing the merits of two solutions, a third will emerge that improves on both. But that's now water under the bridge. Commented May 7, 2021 at 10:58
  • @StephanBranczyk, your answer also makes a lot of other assumptions, most of which I disagree with. Yes, they could be true, but they have the same probability of being wrong. As such, they offer little in the way of being The Answer, especially since those assumptions are based on a WAG of what the OP and interviewer had for solutions or even a question. I'd expect a code review to have those type of requirements, but an interview question just doesn't have the time or unit testing capabilities to require that detailed an answer. Commented May 7, 2021 at 16:12
  • And if all you are looking for is someone who already knows the Answer in an interview, you probably are stifling creativity and ingenuity. Commented May 7, 2021 at 16:13

Unfortunately, it is a case of "just forget it".

(IF it was someone you knew very well and had a lot of back and fore chat with, you could email and say "I was thinking about X, and ...". But it sounds like this is just another corporate interviewer.)

So should I mail him back with proper references that my solution was correct?

Unfortunately, in 99.99% of cases, they'd just delete the email.

Much as CVs are only glanced at for 2 seconds, interviewers just churn through tech interviews and cross people off lists.

Is that a good practice?

I would say it's harmless. It won't, say, annoy the person. But unfortunately in 99.99% of cases, they'd just delete the email.

Unfortunately, the general answer to your question is "In 99.99% of cases it's completely pointless following up on a tech interview question."

  • "interviewers just churn through tech interviews and cross people off lists." -- That's assuming that the candidate pool is large though. Even if it is large they may not be "churning" through them. This is just an assumption and I think the conclusion is the same without it so I don't see how it is relevant. Commented May 7, 2021 at 13:18
  • @CaptainMan - it's a good point; due to the extreme shortage of programmers in many fields, there may only be 1 or 2 candidates anyway
    – Fattie
    Commented May 7, 2021 at 14:26

Keep in mind that interviewers are not perfect. In particular for your case, interviewers are not always strong coders. It's not out of the question that they simply didn't understand your solution.

Along those lines, part of most programming jobs is justifying your solution to others. If you can't do that in the course of a meeting, your solution would really have to be superior to justify bringing it up again.

If your interviewer is a strong coder, keep in mind a "correct" solution may not be good enough. They prefer something readable, testable, efficient, and idiomatic. Another thing I have seen strong coder interviewers do is show an alternative solution to see if you can point out the trade offs between it and yours.

In either case, there is not much benefit to you bringing it up now. Take it as a learning experience and try to think of how you might handle it better next time.


Should you send a follow-up about this? Yes. No. Maybe.

I wouldn't expect this to make a huge difference (if it makes any difference) in their decision in any case, but let's go through the options.


If you explained it well enough during the interview and he still didn't accept it, there's a good chance he won't respond positively if you follow up further.

Some people are less open to feedback than others. It may also be that he understood it perfectly well, but there was some other problem with it.

Are you 100% sure you're right? If you follow up and you were actually wrong, that's going to send the message that you are the one who's not all that open to feedback (unless perhaps you word it very, very gracefully).

If you might've missed some hidden constraint or there could've been some other valid reason he didn't accept your approach, it also wouldn't be a good idea to follow up. Of course you presumably don't know this, but perhaps you can come up with a reasonable guess as to how likely it might be.


If you explained it poorly during the interview or it's an explanation that would greatly benefit from some links, it might help to follow up.

Some people would very much appreciate a candidate thinking about the problem after the interview and spending some time on it. It shows that you actually care about the work.

Others might not appreciate it that much, or he might've already made the decision, but in those cases it probably still won't hurt.

  • I would probably try to include some runnable working code or a link or two to a reputable site if applicable.

  • Don't make your reply too long nor include too many links and try to keep the code to the minimum necessary.

  • Don't frame it as "you're wrong". If in doubt, just entirely avoid addressing how he responded. You could go with something like:

    I was thinking a bit more about the problem and came up with this code to show that it works.

    (That's a fairly rudimentary response to give the basic idea. Add flair and adjust phrasing according to taste).

In conclusion: maybe.

If the interview went well apart from this issue, you'll need to make the choice of following up yourself based on your situation, how exactly the interview went, how significant this question was, how you think they'll receive your follow-up and which sort of employer you want to work for (and which sort of employer you don't want to work for, although it's also worth keeping in mind that one interviewer won't always be representative of the overall culture of the company).

If the interview went okay, but not well enough for you to get an offer, there isn't much risk in following up. You don't have much to lose.

If the interview went terribly, however, this is extremely unlikely to salvage it, so following up would probably just be wasting both of your time. Although you still don't have much to lose and you'd probably be wasting more of your time than theirs (as they would likely just ignore it).

Although you may also have misjudged how it went, which can happen, so I would be careful about jumping to conclusions.

  • I think you hit the nail on the head here: "If you explained it well enough during the interview and he still didn't accept it, there's a good chance he won't respond positively if you follow up further." Commented May 7, 2021 at 13:37

Don't email him, that time has passed and you already explained. If he's a serious professional he may actually have looked it up himself to check your answer. I certainly do if someone disputes what I think is correct.

Having said that if there are multiple possible answers and I'm looking for a particular one, then it makes no difference if your solution is viable, it's not the solution I'm looking for for whatever reason. In your specific scenario the probability is he was looking for the simplest solution.

In any case there is a potential risk with a negligible chance of a favourable outcome from emailing.


No, and don't accept an offer from this company.

There's an expression used when hiring people - "A" quality people hire "A" quality people, "B" quality people hire "C" quality people. The explanation behind this is that people who are really good want to keep learning and hire people they can learn from, while people who are insecure in their positions will pass on someone better then they are.

The interviewer wasn't looking to find out how good you were at the interview - he was looking to find out how good he was. He's not interested in hiring for diversity of thought, he's only interested in hiring people who think about problems and look at problems and solve problems exactly the same way he does, no better.

After an interview like this, if he recommends to hire you, it's only because he thinks you're worse then he is and you're walking into an already toxic work environment that allows people to rank themselves, and where the hierarchy clearly matters (or someone wouldn't be interviewing this way).

Interviews are a Two Way Street

This is not just about them getting to know you, this is about you getting to know them and finding out if this is a place you want to work. How they interview - and how they treat the answers you give them, speaks volumes about what's important at the company. From this interview, you can glean that outside of the box thinking probably isn't welcome.

Factor into this the interviewers position at the company. If this was the tech lead for the team you would be reporting to, you can expect any different in opinion to get squashed if you take this job. He's not looking for proposals or new ideas, just a code monkey to bang away slavish at the computer all day.

The Problem with Gotcha Questions

Most jobs (and you specifically mention Technology, and I've been in the technology field for almost 20 years and its especially true there) are entirely situational. You will find over the course of a career that people will use the same technology and the same tech stacks and they same tools in vastly different ways. Exposure to as many of these things as you can is key to a good career.

However, most interview questions are equally situational and based on the interviewers experience. (This is why I strongly recommend doing 'opposition research' on your interviewer if you are afforded the name and the time - understanding what their background is can help your interview prep to match their likely questions).

These sorts of situation questions are helpful ONLY If you're dealing with a rare, unique, and specific piece of (usually legacy) technology that a candidate has proposed to have a skillset in. Asking questions with only a single solution or with a loop hole that makes the question a trap doesn't help you evaluate how smart a candidate is. It's frustrating to the candidate, and it makes you come across as being extremely arrogant. It's literal gatekeeping in the IT industry.

If your response to this is "Everyone whose worked in tech should know that." you're part of the problem and so is whatever question you are asking. If you hear that at an interview it's a huge red flag.

Telegraphing Feelings at an Interview is a Bad Idea

When interviewing a candidate you should never provide any sort of feedback during the interview. It will alter the candidates state of mind and change how he responds to you. Interviewees who are nervous will have trouble answering questions, and if they think you are looking for a specific thing they will try to give you the answer they think you want to get the job. This is bad because it doesn't give you an opportunity to properly interview the candidate.

One of the most surefire ways to tell a Candidate how they are doing at an interview is to tell them what the 'right' (and I use this term loosely) answer is. Broadcasting to a candidate that they are unlikely to get the job will at best unconsciously cause them to do worse, and at worst intentionally cause them to check out. That someone would do this in an interview shows that they lack the sort of people skills necessary to be evaluating candidates to begin with.

What Should Have Happened

In this case, assuming your answer was technically correct (and perhaps the interviewer legitimately believed it was not) he should have followed up with more questions. "Why would you take that approach?" "What advantages does this solution bring that other solutions don't?" "What's a potential weakness of this approach?"

If indeed there is only one right answer, the answer should be presented instead of asked for and then the question should be posed as follows: "What problems do you see with this approach, and what approach would you take instead?"

However, as I mentioned previously, that requires a candidate to divorce themselves from their tricky 'gotcha' question that they came up with on their own and most people have a hard time doing that.

An Example, In Practice

Recently, during an interview process I asked someone a question (How would you rename a file in Git?). This question has many answers, and none of them are inherently right or wrong, but some have more benefits then others (Using the move command in Git preserves history attached to that file, versus renaming the file and recommitting it). This question was designed to tease out the skill level of someone interviewing at the company. An advanced user will understand the subtleties involved and someone at a more intermediate stage will not understand the disadvantage of the approach that they choose to take.

When the candidate answered with the 'wrong' (for the purposes of this conversation) answer, I then followed up with asking them about the pitfall of their solution as compared to the other one (In this case, "You would lose the file history if you did that, though. Wouldn't you?").

This doesn't tell them what the right answer is or that they necessary got it wrong, just expands the conversation to convey back to me how they think about the problem, which as other answers have better alluded to and explained, is the goal of the interview:

The purpose of an interview is to evaluate a candidates skill level to assess if they can perform the duties as described.

Gotcha Questions need not apply.

  • 4
    funny story: git preserves history even if you rename the file manually. it doesn't really have any notion of a committed rename at all; it figures out renames based on similar files being deleted and added in the same commit
    – Eevee
    Commented May 7, 2021 at 4:06
  • 1
    Merely renaming the file without git mv "preserves history" just as much. You may be thinking of git log --follow which is needed to see the history of a renamed file across renames (even if you use git mv). If this question was designed to tease out the skill of the candidates then please be sure you understand it lest you become the interviewer OP is complaining about. You can test this by making a file with text, moving it with and without git mv and seeing that both "lose history" with git log -- file but "keep history" if you use git log --follow -- file. Commented May 7, 2021 at 13:50
  • This answer taught me a lot
    – Stilez
    Commented May 8, 2021 at 19:49

This happened to me in an interview with a FAANG company once. I was very upset. However, it's really not worth it. It's seen as unprofessional behaviour to contact anyone involved with the recruiting process except for your recruiter directly, unless otherwise specified, for any reason, and in this case specifically it comes off as argumentative and borderline bullying (even though you're right).

Having gone through FAANG interview training (at a FAANG company), interviewers (at least at those companies) are specifically told not to bias towards one or a small subset of "acceptable" answers, and to listen honestly to whatever the candidate has to say; as you did, sometimes the answer given by the candidate is correct but not expected. However, unfortunately, as in my situation, sometimes the interviewers do not abide by that training. It sucks, but it happens.

If you feel really upset by this, you might want to mention this to your recruiter. It's unlikely they'll do anything to help you, but it's possible, and it couldn't hurt.

Noteworthy is that another point in the FAANG interview training that I took is that the fact of whether the candidate comes up with a working answer is not actually as important as you think it is. I'd say maybe 20% of your "grade" for the interview (such as it is) is whether or not your answer is actually right. More important is how you approached the problem. Did you ask clarifying questions and/or state your assumptions? Did you break down the problem into chunks or just try to conquer it all at once? When the interviewer prodded you with hints and guiding comments, did you apply them and react to them in the way the interviewer expected? Those things are much more important (at least in the company I did my interview training) than whether or not you actually got the "correct" answer. So even if you got the right answer, you could still fail if you didn't meet those criteria, and even if you got the wrong answer, you may still pass if you did well in those criteria.

  • Do you mind editing this answer to explain what the acronym FAANG means? Thanks. Commented May 9, 2021 at 1:19
  • "Facebook, Apple, Amazon, Netflix, Google". It's basically a slang to mean "top tech companies", and it's common enough that most people know it (or can google it).
    – Ertai87
    Commented May 9, 2021 at 17:11
  • Yes, I did google it. But it's nicer if answers can be self-contained. And "most people know it" probably refers to most people in software development. There are plenty of other occupations represented on this site. Commented May 17, 2021 at 12:22


  • If they reject you because of that, you don't want to work for them.
  • If they reject you for other reasons, it doesn't matter.
  • If they accept you anyway, it doesn't matter.

I came up with a solution and explained it to him but he had another solution in mind and didn't accept my solution even if I gave him logical reasoning behind my approach.

You can email him if you want, but if you do, I recommend you specify the time complexity and the space complexity of your desired approach vs. the time complexity and the space complexity of his suggested approach.

I'm not saying your interview performance needed to be perfect. It doesn't need to be, but if you're going to contradict and possibly email an interviewer about a potential mistake they've made, you really have to be sure that your solution is the most optimal one both time-efficiency wise and space-efficiency wise.

After the interview I confirmed that the solution that I came up with is perfectly acceptable and one of many solutions.

I doubt that. Just to give you an example, take a look at what this person did:

He looked up the answer on HackerRank and thought that his solution was perfectly adequate for a coding interview problem that someone else had posted.

His answer: https://codereview.stackexchange.com/a/212530/7219

Original question: https://codereview.stackexchange.com/questions/212492/bracket-matcher-in-python

Unfortunately, he did not realize that the same problem can have many slight variations and that the solution he found may have been optimal for the problem he found on HackerRank, but it sure wasn't optimal for the coding interview problem that the OP had to solve.

Please don't be that guy.

To this day, he doesn't what he did wrong, and he's still in denial, despite the fact that two senior engineers pointed out his mistake to him.

  • 2
    Copying and pasting an answer without understanding it is completely different than what the OP states. Also, they don't go into the details of what the actual question or their answer was, so making blanket statements about how "basic" their answer was is worse than useless. And comparing their code with "90% of other people" is also not a valid assumption. All that does is reinforce people's imposter syndrome, and that's never a good thing. It ignores the possibility that the interviewer was in love with their own answer, so anything else was "obviously" wrong. Commented May 7, 2021 at 16:06
  • @computercarguy, Please don't misunderstand me! No one expects a perfect answer during a technical coding interview. With that said, if justifying your decisions based on time complexity and space complexity hasn't been drilled into your head yet, do not go about contradicting or emailing your technical interviewer about which approach you should have taken. Commented May 7, 2021 at 17:17
  • @computercarguy, Tonight, I'm going to amend my full answer to restate what I've said in my previous comment. Bear with me while I do that. Commented May 7, 2021 at 17:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .