7 Red Flags In Programming Interviews

In our previous blog posts, we covered a lot of interview preparation tips and hacks about what you should do before and in an interview in order to better your chance of getting hired. However, there are quite a few red flags in code interview that can potentially make you fail even if you have a good performance in other areas.

Similar to what we did before, we don’t want to tell you some sort of preach like the biggest red flags is fail to show great technical skills, which is too general and makes no good to you.

Instead, we truly believe that everything we provide here must be practical and detailed enough so that you can easily act on them with no confusion.


#1: No passion about the company/product

It’s quite obvious that no one would like to hire someone who shows no passion to his company and product, however this is one of the most common mistakes many candidates had. If you can hardly answer questions like tell me how much do you know about company X or you have never used the product before, you are very dangerous.

Quite honestly, this is almost the easiest thing to prepare before the interview since all you need is just doing some investigation about the company and spend enough time playing around its product. Also many people won’t apply for companies they don’t believe in, which is also what we normally encourage to do.

If you don’t know much about the company, it’s history, culture and product, you may not be a good fit. In this case, even if you got hired (very unlikely), it might not be a good job for you due to culture fit.

In short, do spend time doing investigation about the company especially the company is not well-known, which will also give you some extra points. Being familiar with its product and it’s even better to have some deep understanding and suggestions on it.


#2: Stop thinking

It’s totally fine and common that you can’t come up with a solution of the question in an interview, but the worst thing ever is that you stop thinking about it by telling the interviewer you have no idea.

First of all, no one will hire someone who gives up easily in general. It’s almost for sure that in your future work, you’re gonna encounter lots of obstacles and you need to show that you will be able to consistently work hard.

In addition, you can do a lot of things even if you have no idea at all. You can try to brainstorm approaches you haven’t tried yet. If you failed to give a recursive solution, you may try a non-recursive approach or the other way around. If you were using an array to store information, you may try with tree, hashset etc..

By talking loudly about what’s in your mind, the interviewer can also know that you get stuck and is more likely to give you hint, which we mentioned in The Interviewer’s Expectation. In short, all these approaches are better than sitting there staring at the interviewer even if none of them works.

Lastly, as we mentioned in our interview preparation tips in our Facebook page, not all questions the interviewer has an answer. In other words, the interviewer may come up with questions that are open-ended or have no clear solution, in which case they just want to see how candidates analyze it. Most of the time describing your approaches in general and trying to analyze the problem to some extend are already good enough.


#3: Have trouble with big-O analysis

Of course many people failed the interview due to lack of good technical skill and I don’t have many comments on this besides spending more time and effort on preparation and refer to our previous blog posts.

However, we saw so many candidates who have good computer science foundation in order to solve most of the interview questions but fail to analyze time/space complexity correctly.

As we’ve seen more and more this kind of cases, we noticed that majority of candidates didn’t pay enough attention to this area. In fact, I want to tell you that the big-O analysis is extremely important! I can hardly hire someone who is not clear about this even if he solved all the questions correctly.

Without a clear understanding of program efficiency, you won’t be able to analyze how costly your solution is in production, which can be really terrible. You can hardly imagine how much money Google will lose if there was an extra 1s latency in their search engine.

We encourage people to always analyze both time and space complexity for every question they practice before the interview. Space complexity is more likely to be ignored although it’s equally important.


#4: Lack of confidence

If someone is unconfident and uncertain in an interview, he’s more likely to be uncertain about things he will work on if getting hired. It’s okay that you are not clear about everything and no one is in fact, but when you describe your approaches, your opinions, and when you have strong reason to support them, it’s always better to be confident.

From another perspective, if you are often unconfident, it’s more likely that you didn’t spend enough time preparing for the interview. If you have seen the similar issue for many times, there’s no way for you to be uncertain about the solution. Also I don’t want you to be too aggressive or too assertive, it should be clear and easy to distinguish between confident and aggressive.


#5: Crappy code

You don’t want to fail the interview when you finished with perfect solution. However, some candidates didn’t make their codes professional. Someone may use variables that have never been defined previously, or put pseudo code in between.

Although you don’t need to remember all the syntax of C++ or Java, some common syntax like vector and list are better to be correct in your code.

Coding style is also important. Although you are unlikely to fail only due to bad style, code with consistent style looks much more professional. I’ve covered the coding topic in detail here.


#6: Late for the interview/bad signal

It’s really bad to show up late in an on-site interview or have bad signal during a phone screen. From the interviewer’s perspective, this candidate just didn’t take it serious. I don’t want to elaborate much about this topic since it’s so easy to avoid. Always arrive earlier for an on-site interview. And for phone screen, please find somewhere quiet and make sure you won’t be disturbed for the following hour.


#7: Bad answers to why you want to join us

In many interviews, you will need to tell the reason you are applying for this company. And for some company, this question is a must-have. Although there’s no standard answer here, some answers are clearly bad and it’s almost for sure that the candidate will fail.

Some candidates may say that they want to join here because they didn’t have much chance to learn in their old companies or there’s no room to grow. This seems even worse if they came from some large corporations. If you are working at a company with 100+ employees, how could you say that you have few chance to learn any more?

“I’m getting bored with my old job” or “I just hate what I was doing previously” are also not good answers obviously. What the interviewer really want to hear is why you really want to join us instead of why you want to leave your previous company. Companies are always seeking people who are great fit. If you don’t really believe in the value of the company and you don’t fit into its culture well, you are unlikely to get hired. That’s exactly why this question is very important.



I hate to see that good candidates failed due to non-fatal errors. People spend most of their time on technical preparation, that’s why it’s very easy to overlook issues mentioned above.

I hope this practical post can save your life to some extent. Let me know what do you think 🙂

The post is written by Gainlo - a platform that allows you to have mock interviews with employees from Google, Amazon etc..

I'd like to learn more

Share on Facebook0Tweet about this on TwitterShare on LinkedIn0Share on Reddit0

Leave a Reply

Your email address will not be published. Required fields are marked *