How To Pass a Technical Interview: Recommendations - DZone Agile

What This Is Article About

Maybe you were or you will be a candidate for a technical interview. Here, I'll share my personal experience as an interviewer. I'll share the best strategies to pass technical interviews considering the interviewer (company) side.  I'm sure both juniors and seniors could learn something from this article.

Earlier I published an article with recommendations on how to conduct technical interviews for interviewers. In that article, I recommended asking high difficulty questions first and then moving to simpler questions. In such a way, the interviewer can identify the candidate's knowledge quite quickly. However, this approach has one disadvantage: interviewed developers might experience a lot of stress. For this reason, companies may follow a different approach.

A Simple Technical Task Is Not That Simple

As you might guess, the main idea of an alternative approach is to request the implementation of a simple technical problem.  From a first look, there doesn't seem to be any threat here. Such simplicity might confuse developers at the very beginning. What might potentially go wrong?

One Step Aside and You Fail

No one actually cares about the problem itself, but this step is to compare candidates during the interview by filling the list with all important actions achieved by the candidate. List? What List?

The little details are by far the most important. And for every small detail, the company has a record in one "secret list". Such a list might look like this:

Perfect Strategy

When you know what a company might expect from you, you can stick to a winning strategy. To fulfill all potential criteria, you need to choose the right actions from the very beginning of the interview. Below, I provide an example of a potential win strategy. The blue squares are an action list you can follow. On top of each, you can see corresponding achievements in a secret list.

Depending on the problem/language, some aspects might be different. In any case, the solution has to be built as an instance of the ideal expected solution that follows best practices. Unfortunately in practice (according to my experience), even senior developers with 10+ years of experience may not follow any strategy at all, and at the end of the interview, my interviewer's list is pretty empty because the only thing I have is just a regular, poorly implemented solution.

Additional Recommendations

The interview process is stressful, but without it, you can't get a job. One of the reasons why people fail interviews is that they can't handle the stress. If you just surrender and accept this stress, then your mind finally can be focused on the questions and problems. Don't be ashamed if you don't know something: it's not a crime. In the worst case, try to guess by providing your explanation. The IT domain is one of the highest-paid, but to join it, you have to keep good interview skills, even with a lot of work experience. In general, I recommend to:

• If the interviewer is rude to you, interrupt the interview and leave. Respect yourself. 
• Start the interview with the expectation that you will fail. Be professional, not emotional. 
• Be focused on the problem during the interview.
• Be honest and clear in your actions. Don't mislead yourself and the interviewer.
• Remember all the questions asked during the interview and Google them later (you will learn new technologies and one day know more answers).
• Don't give up on interviews. Passing interviews is a skill and improves over time.

Conclusion

In this article, I've described an interview strategy that fits simple tasks intended to check your general code writing/IT skills. This might not work for different types of interviews; for example, classical academic tasks. For academic whiteboard problems, the most important part is to solve the problem, and only after (if you have time) you can use the additional tips I shared. Overall I hope my recommendations were helpful. Thanks for reading.