A candidate once told me a phone screen story. He wrote an algorithm on an online editor, and at the end of the interview, the interviewer asked him –
“If I copy-paste this code into an IDE, will it run?”
The candidate had used several small helper functions that he had not implemented (which is ok because this was a text-only editor) and he admitted that his code probably had minor syntax errors. It was obvious that his code wouldn’t run as it is.
Why, then, did the interviewer ask him this question?
The most likely reason is to see if the candidate is grounded in reality. It was obvious the code wouldn’t run, and if the candidate had said “Yes”, it would likely be a red flag.
While this question is not common, it is easy for many people to fall into the trap of saying “Yes”. After all, you don’t want him/her to think your code won’t run, right? Wrong.
This is part of culture fit. Companies want their candidates to be humble and accept mistakes if there are any. Here are some things they look for:
1. Are you humble? (Good)
2. Are you being genuine? (Good)
3. Are you overpromising? (Bad)
4. Are you being nice and courteous? (Good)
5. Are you showing genuine interest in the interviewer and the company? (Good)
6. If the interviewer points out a mistake, are you being defensive about it? (Bad)
For a lot of people, this will be second nature. But if it isn’t, maybe its time to start thinking this way at work.
A LOT of times, candidates who meet the technical bar will be rejected on one of these grounds. Be mindful of this while interviewing.
Here are a few more pitfalls you can avoid:
Interviewer: Is there a more efficient solution to this problem? (After you’ve already coded/mentioned the most efficient solution)
Red Flag: If you just say “Yes”
What to do: Continue thinking through the problem – don’t just say “yes”. Look at the different parts of the code and systematically conclude that this is the best solution. For example, “We clearly need to iterate through every element at least once, so we know that the solution will be at least O(n). So this solution should be the most efficient in terms of time complexity.”
The interviewer gives you a really easy and common question.
Red Flag: Quickly coding the solution because you have practiced it before.
What to do: The point of the interview is to test your thought process. If you don’t walk through the problem and think through it, it clearly shows that you have practiced it before and are not being genuine about it.
There are two ways to handle this situation: either you tell the interviewer right away that you have seen it before, or you work through the problem. Either way is fine in my opinion. Even if you work through the problem, you will have to demonstrate your thought process and a systematic approach.
One note here: In spite of walking through the problem systematically, if the interviewer asks you if you have seen this problem before, it’s better to be honest. For example, “Yes, I have seen a similar problem before, not this exact one, but one that utilized a similar algorithm”. That’s totally fine. The reason the interviewer asked you in the first place was that they suspected it. It’s better to be honest and genuine in this situation. Note that you have done nothing wrong – they asked you an algorithm question and you systematically thought about how to solve it.
Interviewer: Did you run into any production issues? (After describing a project)
Red Flag: Just saying “No”
What to do: In most work-related projects, you will run into production issues. if you didn’t, that either means there were not enough users, or it means it was a small feature that you tested thoroughly before launch.
If you ran into production issues, explain them frankly. It shows you have experience with handling real-world projects.
If you didn’t, explain why. For example: “This was a class project so we didn’t put it in production, but we did get some feedback from our users – our camera app sometimes crashed because we were not passing a parameter in XYZ case.”
“It doesn’t always happen, but in this case, we didn’t see any production issues. We had thoroughly tested the feature before launch, including stress tests and unit tests. We did catch many bugs before launch though, and fixed them quickly.”
Culture fit feels like black magic to many candidates. Sometimes when we are rejected, it is partly because of culture fit but we don’t know it. We tend to blame the performance of our algorithm or our system design, and the real issue stays hidden.
Don’t let this happen to you. If in doubt, err on the side of humility.