5 most frequent mistakes that programmers make at the interview

Original author: u / BigDisc
  • Transfer
Translation of the Reddit user's post

Over the past year I have conducted more than 50 telephone interviews, and watched people make the same mistakes over and over again. On the Internet, you can find a lot of tips on skills that are useful for interviewing, but I haven’t seen texts that describe strategies that help people succeed. I think that most of our candidates who have come to the interview have the necessary skills, but they are just nervous and do not apply these skills effectively. So that the context is clear, our company is a startup for 100 people, and about 50% of people reach the second round of interviews.

1) Assume that there is some very good solution.


When you hire a person for a station wagon in a software development company, it’s unlikely that you will be required to have knowledge of the Bloom filter (hot is a cool thing) and how to use it during the phone interview . However, candidates constantly cross out satisfactory, not ideally optimized solutions, and begin to look for something out of the ordinary. As in programming, here it is necessary to leave complex and specialized data structures for situations where their use is beyond doubt. There is a reason that we have been using arrays (and merge sorting) for more than 70 years.

How to fix: use standard algorithms and data structures as building blocks.

2) Ignore interviewer tips and tricks


This error can manifest itself in different ways. A glaring option is when the interviewer makes a very transparent hint, like “what if we take the stack instead of the tree?”, And this hint is ignored or rejected. I, as an interviewer, am trying to help you! In this case, there are no situations in which they would try to deceive you. When the interviewer makes a clear offer, he tries to either put you on the right path or force you to prove that your current decision is optimal (and in this case you probably already know that your decision is good). Regardless of what he does, ignoring the prompts does not lead to anything good.

Sometimes candidates take a hint, try to work on a solution for a while, and then discard it and return to what did not work before (or move on to something else). If someone gives you a hint, and it seems to you that it does not work, it's okay - but you should have a clear explanation of why an alternative solution will be better than the one proposed. Remember, we are trying to help you make the right decision, and we have the answer, so our decisions will most likely be useful (however, sometimes people come up with great solutions that we haven't provided).

How to fix: carefully consider what the interviewer gives you.

3) Push a square peg into a round hole


This error intersects with the previous one, however, candidates often meet with a decision early enough, and then they put improvements on it to solve any problem. If it seems to you that the answer is not quite well suited to the problem, most likely, there is a problem at the heart of your solution. Do not be afraid to throw away the current solution (especially if you can name its negative sides) and choose a new one. The correct answer will usually be quick, so don’t worry about time constraints.

How to fix: do not be afraid to throw away the current solution and choose a new one.

4) Too quickly burrow into the details


This mistake does not drown candidates right away, but causes them trouble in two ways. First, having described the solution in great detail, they become attached to it and do not want to abandon it, which leads to problem (3). Worse, the interviewer takes more time to understand that the decision is wrong. Interviewers usually lead you away from the wrong decisions, and lead you to the right ones, therefore, the sooner they understand your decision, the faster they will direct you where necessary. Since interviews are limited in time, it is better to give the wrong decision in 30 seconds than in 5 minutes. And if the decision is correct, or close to it, the interviewer will always be able to ask you for details.

How to fix: quickly give out the right or wrong answer and move from there.

5) Do not fill the silence


I blame this advice on advice from college seminars on “how to get an interview for a technical position” and articles from online publications. It is important to bring your thoughts to the interviewer, but it’s not worth mumbling. None of us sits down at the computer right away and does not immediately start writing code after receiving the task - so you can not start talking right after receiving the question. It is quite possible to say something like “let me think for a moment,” and concentrate for 30 seconds or a minute. For reasons from (4), do not linger, but the correct answer after a minute of silence is much better than 2 minutes of chatter without a good answer. A short silence allows the candidate to gather his thoughts and give a coherent answer, which is much better than a ragged one.

How to fix: communicate your thoughts, but do not be afraid to put them in order before it.

Also popular now: