The most common mistake you are making in preparing for a technical interview
1. Often technical people prepare to answer technical questions, not to ace a technical interview. That’s why the smartest and most qualified people are not necessarily the ones who get the job. The ones who interview better do (assuming they are qualified);
2. Becoming proficient at interviewing will take very little effort and time compared with being able to answer technical questions, which you are already prepared for anyway;
3. You can leverage your technical skills to understand and prepare for the interview process to structure your answers in a way that are more compelling for the interviewer (i.e. that get you the job);
4. Interviewing better instantly increases your chances to get the job no matter how smart and technically prepared you are.
If you are preparing for a technical interview for a job you really want, you are probably researching the most common algorithms, what data structures are more efficient and how to calculate the order of complexity. Once you have practiced them all you will likely feel confident and ready to go to the interview and maybe even answer all of them right. But you still might not get the job. Why?
Because you prepared to answer the technical side of the questions. But you didn’t prepare enough to organize the content of the answer to be well received nor how to answer questions about yourself. They are two completely different things, evaluated by the interviewer separately. To get the job you will need three main things:
1. Be technically qualified (i.e. degree, certifications, skills, experience);
2. Fit the culture of the company;
3. Be able to communicate effectively during the interview that you have 1 and 2;
If you are great at 1 and 2 but you cannot convey it well enough (i.e. you don’t have 3), you will likely fail the interview. Not only because they might think you don’t have 1 and 2, but also because, possibly, a technically weaker candidate was able to create much more compelling answers and got the job.
Think about it in these terms. Compare yourself with someone who had your same degree and similar skills and work experience. You both were called to interview. How will they decide who to hire? Simply. The one who interviews best.
So if you are smart and technically qualified as Martin (we will call him so), this can probably help you get through the last mile that separates you from the job you want.
First of all the good news is it’s not rocket science. This is something you can learn in a day, practice and be ready right after.
Martin was a developer. Having a developer’s mindset is something that you naturally achieve after months of coding. Let’s see how you can use it to capitalize on it. Think at the interview preparation process as if you were to deploy a new functionality to production and you just finished writing your first “Hello World”.
There are 4 steps you need to accomplish if you do it right:
1. Learn the development patterns of the language you are coding with;
2. Learn when and where to apply them;
3. Test your code until you are sure it works as expected;
4. Deploy to Prod;
5. If you did it right there is no need to hotfix ;).
When preparing for your interview, they translate into:
1. Learn the interview patterns and frameworks - Understand how interviewers frame their questions and how they expect you to frame your answers (again, it’s about HOW you organize the answer, not WHAT you say);
2. Learn where to apply them - Prepare to say what you want to say using the right structure at the right time (with the right interviewer);
3. Test - Rehearse your answers;
4. Deploy - Put your new findings into practice on your next interview;
5. Hotfix as needed - If you get an offer there is no need to go back to step 2.
The concepts are as easy as a “for” and a “while”, but as you very well know when you start coding, it might take you weeks to do it all right. Thankfully for interviews, you can do it in days, if not hours, if you get the right advice.
What Martin stated helped him the most was to get a clear structure of how to build his answers.
1. ^ Learn the interview patterns and frameworks
You can look at every question about yourself, your previous experience, your strengths and weaknesses the same way as you think at a technical question.
For instance if they ask you to code an algorithm to find how many times the character “c” appears in a given string, you already have in your mind a framework to solve it.
Similarly, when they ask you “tell me about your most difficult project” you have to immediately know that you don’t have to jump into the technical details right away. You first have to explain the context, what was the challenge, why you did what you did and what was the positive outcome.
There are just so many patterns of questions that they will ask you. After you are clear on which ones they are (see resources at the end of this post) and how you need to structure your answer accordingly, you are ready for step 2.
2. ^ Learn where and when to apply the frameworks in your answers
Do you remember that moment when you are done learning the syntax of a new language and you are trying to use it for the first time to solve a problem? This is where your creativity comes handy. You know what you want to achieve. You know you now have the tools to do it. But you still have to figure out which one of all the possible combinations will work better for each case.
When preparing for your interview you know what you want to achieve - impress the interviewer. You know you have the tools - e.g. recognize and answer a behavioral question. Now you have to figure out how. Of all your previous experiences, which is the one you should mention in each case? What should you focus the interviewer’s attention on?
To do this right you can use another skill you are already very likely good at as a problem solver. Pattern recognition and matching.
In this case you will have to match the most important skills the interviewer is looking for with the situations where you succesfully used them in your previous experience.
For example, let’s say the job description and/or the interviewer states that they are looking for a candidate who is a quick learner and is passionate about coding. Let’s also assume that during the job interview they mention their stack is .NET. And although you worked a little bit with it you have much more experience in MEAN.
Eventually, they ask you a question about your biggest accomplishment. What do you do? Do you talk about your relatively simple .NET project to show you are familiar with the same stack they use, or do you talk about a complex project you successfully worked on in MEAN?
You can do both. You can do that by framing your answer the right way. You first say you are familiar with .NET, you then mention your most complex project was developed using MEAN. Then you clearly state what was the context (challenge), your action and the successful result. Finally you can add “A few months before starting that project I was not as familiar with MEAN either, but I have been often told that I am a quick learner and I am sure I can quickly get up to speed with .NET as well. In fact, I am excited by the challenge and I believe that having a broader experience and an open mindset will be very valuable assets I can bring to this position and the team.
This way you accomplished 3 things:
- you said you know .NET
- you showed you have a strong problem solving background and also,
- you match the job description for being a quick learner excited to be challenged
As you can see there is no silver bullet in terms of the right answer. But if you have in mind the right framework to analyze what they are looking for and how you can match it, you can take advantage of any question to show it off.
Also note that this same answer for instance would have worked just as well if they asked:
- What is the technology you are more familiar with?;
- Tell me about your biggest accomplishment
- How deep is your experience with .NET?
- Why should we hire you over someone who has more in-depth .NET experience?
- Why do you think you can do this job?
It’s like when you learned how to use Class Inheritance. The ways you can use it are unlimited. But if you didn’t know it even existed, how much more time would you have spent on writing spaghetti code?
Now you are all set, ready to deploy to Production?
3. ^ Test your answers
Of course not. You are obviously going to test it first, aren’t you? If you don’t feel almost offended by the fact I am insinuating you would actually deploy some untested code to Prod, maybe the interview skills are the least of your problems ;P
Here is where Martin was facing his second big challenge. He didn’t have someone to talk to because, although he had a lot of successful friends, nobody had quite the same story as he had. Additionally, when searching online, he didn’t to trust the “yet another website that gives you a silver bullet to ace your job interview.” So how do you test?
Testing in this case means that you already have a good idea of which are the most common job interview questions and which ones are the skills you want to highlight for this specific position at this specific company. You also have already prepared (i.e. written down at least a few bullet points) your answers and now you want to know if they sound compelling.
This is the part most candidates don’t do because they think it is tedious. Or they think they have the answers figured out. Or they don’t like to feel judged.
This is not about judging you, this is about working with someone who can help you figure out if your answers need to be adjusted to match your interviewer’s expectations and how. You can still skip this step and take the risk to just show up at the interview and hope for the best (i.e. “I don’t always test my code. But when I do, I do It In Production“).
The interesting thing you want to consider too is that by rehearsing your answers with the right person doesn’t only help you refine them, but also boosts your confidence. Think at how confident you would be to deploy to production in a new environment by yourself vs doing it after several times you have done it with someone that knows it well. When you show up to your next interview, you will feel much more confident and the interviewer will feel it too. He will also interpret your confidence as you are ready to do this job rather than you are ready to do this interview. Which is what you want. So, who can help you?
Once you decided that you want to double check your answers, you want to do it with the right person. He or she has to have experience in interviewing people, and has to be direct and transparent enough to tell you the truth on how to improve. Avoid family members if you can. You have too close of a relationship and things can get emotional pretty quickly. Also, if they haven’t interviewed anyone recently in their daily job, it’s like using a text editor to do the work of a compiler. Your coders friends who got hired in some other firm, maybe even in the same firm you applied to, might have had a good story that worked for them. But it does not mean it will work for you.
The ideal, and free, solution is a smart friend who is experienced and trained to interview people in his daily job (e.g. a recruiter, a hiring manager, or a Sr. team member who is involved in the candidates screening). He or she does not even need to be working in your industry, because - remember - you are not measuring your domain knowledge here (the what), you are evaluating your interviewing skills (the how).
If you really don’t know anyone that can help you, you can also hire a coach and get a mock interview. This can is usually pretty expensive if you hire a good coach. Or, if you can wait a couple of days, you can also use an e-coach which is much cheaper and can give you qualified feedback in writing.
Whoever you decide to use, he or she needs three pieces of information to be effective: your resume, the job description of the position you are applying to, and your answers to the questions you will likely be asked.
After your mock interview, you might have a few things to adjust based on the feedback you received and now you are finally all set to ace your interview.
4. ^ Use your new skills in your next interview
It is important you also understand one last thing: an interview is a complex situation with many moving pieces, some of which are out of your control. This is a good reason for you to be very prepared at least on the things that ARE under your control.
Think at what happens when all your code worked in staging and then you deployed it to Prod and it crashes because someone recently wiped one of the DB lookup tables you were using without telling you.
Many things can happen during the interview process that have nothing to do with you, but will affect you. Maybe another candidate might have your same skills but he is in a worst position to negotiate so they extended him a lower offer than the one they would have given you and he accepted it.
What you can use as an advantage is that many technical people, either do not understand that interviewing is a skill by itself, or they don’t take those couple of hours to practice it. Or they just never even thought about it. Whichever is the reason, when you compete with them, even just because you had the patience of reading this far, puts you in a much better position.
It is now up to you to decide how much you care about getting the job you want and after how many painful attempts. You likely spent several years and tens of thousands of dollars to get qualified to get this job. But so did everyone else. Isn’t it worth increasing your chances to get it by investing a couple more hours and maybe less than one hundred bucks?
Now you know. Whatever you decide to do is now your choice and you now have a different lense to look at how to prepare for an interview to stand out from the majority of people who don’t.
^ FasterSkills and other resources you can use:
1) Learn the questions patterns
You can Google which are the most common interview questions asked and you will find articles with top 5, 10, 30, 50 questions that will give you an idea of the patterns.
You can check Glassdoor too, that gives you more specific questions types based on the actual experience of people who applied for a specific position at a specific company.