I applied for a middle C++ developer position and was invited for a coding interview.

At first interview, I solved both (relatively simple) problems and answered all questions regarding the language. At the same time, the solutions were not "beautiful", they were rather straightforward (but optimal in terms of space and complexity), and I was correcting myself most of the time and made several typos which were corrected by the interviewer.

The second interview went in a similar way. I solved two problems, but when I was asked extra questions, I failed a couple of them (for example, with difference between "resize" and "reserve"). I was clearly nervous and even the interviewer noticed it asking me to relax.

When I was rejected, I asked for a feedback from HR and was given the following one: "improve your coding skills". Is it a fair one? Is it rude?

I mean, I can accept that at the moment I am probably not so experienced for a middle position, but I solved all problems and answered most of the questions, and all solutions (yes, with typos) were optimal. And these typos are mostly due to nerves.

What do you think? I can give more details if interesting.

  • 4
    Downvotes are likely the same reason: this is not an answerable question. Ultimately asking for feedback on rejection boils down to: "others were better" and why companies don't give it out is that, at best, nothing happens, at worst there's now drama to deal with. Whether it takes the form of direct "others were better" or something more mundane like "your coding is not up to our standard" doesn't matter much. May 29 at 18:38
  • Agree, and I would be ok with the feedback "we hired more suitable/experienced/whatever candidate", or "you lack this and this skill that we need". But simple "go improve your skill", on the one hand, tells you nothing about your weaknesses, and, on the other hand, is confusing taking into account that I didn't fail the interview completely. Of course, HR's and interviewers are not career coaches and don't have to waste their time explaining you what you should learn. I also understand this.
    – user43283
    May 30 at 5:49

2 Answers 2


Gonna disagree with the VTCs here - I think there is an answerable question:

If your solution had typos that you didn't pick up on and you didn't answer all the questions - then the interviewer is right - you need to improve your coding.

Those little details can cause massive headaches. I remember one of the Alien series of Games that was released and every panned the AI as really terrible. Turns out in the code there was a 0 when it should have been a 1, which meant that all the wonderful code that was written for the enemy AI didn't get activated. When the bug was discovered and fixed by the community, the reviews were night and day.

When you get into the position and there isn't an interviewer there to check the work you've submitted - what then?

Certainly, there are more diplomatic ways or more verbose ways that the feedback could have been given - but ultimately - it's fair critique based on the mistakes you've acknowledged in your technical interview.


For the typos, I'd suggest you do the weekly contests on Leetcode. There is a five minute penalty for every submission that is incorrect. In addition to that, when practicing on Leetcode, I'd suggest you resist the urge to press the run button until you're 99% sure your code is correct and runs as intended. Proofreading the code you've just written is a habit. You need to practice that habit.

The same goes with debugging your code. Ideally, you should get into the habit of manually stepping through your code with a concise example and a pen and paper (or by using a comment at the end of each line keeping track of the current values of each step). Since you're rarely given access to a debugger during interviews, this is good thing to train yourself on as well. And being able to do this not only proves to yourself that the logic is correct, but it proves it to your interviewer as well.

Just make sure that you step through the entire example since many bugs only appear at the very end of the input. This is why your example needs to be as concise as possible, if it's too long, you're more likely to lose patience and skip it.

But otherwise, I agree with Tymoteusz Paul. It doesn't really matter how good you think you are. It only matters that this potential employer has higher standards, or has seen other developers that could code with fewer typos than you had.

but when I was asked extra questions, I failed a couple of them (for example, with difference between "resize" and "reserve"). I was clearly nervous....

Please research the topic of recognition vs. recall memory (or watch this video). If I had to take a guess, I would think this is the reason you made this mistake.

In other words, if you want to fix this kind of problem, you need to practice these kinds of questions under simulated conditions, you can't just read these questions and answers and think you will remember them.

I solved all problems and answered most of the questions

How do you know you solved all the problems? Many interviewers won't bother giving you a hard problem if they saw you struggle with the first problem.

  • >How do you know you solved all the problems? They said in the beginning of the interview, there will be 2 problems. In fact, after each problem they gave a more complex version of it which I also solved. Thank you for your nice feedback!
    – user43283
    May 30 at 5:34
  • So, to make it short, what I failed (and I admit it), were typos in the code (mostly incorrect signatures of functions). Partially, because I don't remember them by heart and google them when needed in daily work and partially because of nerves. It's my first interview for a middle position and seems you either need to be ideal or you go home. At least this is the lesson I learned.
    – user43283
    May 30 at 5:42
  • 1
    @user43283, If this was your first interview in a couple of years, you did really-really well. Do not frame this as a failure. It wasn't. Finding a job is a numbers game. Interviewing with companies is good practice. Keep on doing it. Also, do the free peer-to-peer mock interviews on pramp.com and do mock interviews with your friends. May 30 at 6:12

You must log in to answer this question.

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