Some subjective tips on how to easily increase your chances of getting a great job after a technical interview for software engineering positions.

A technical interview is one of the most important factors in recruiting for software engineering positions. The reason for that is quite obvious — it checks what we need from programmers: the ability to solve problems, knowledge of data structures and algorithms, communication skills, etc. On the Internet, you can find countless typical interview questions for all languages and levels. However, since I started conducting technical interviews I’m still surprised by how a small number of people prepare for a technical interview. And I mean a whole interview — not only how to code some lines in a given programming language. Even a few hours spent on preparations can have a huge impact on the results and open for you a door for a dream job. So why do so many people neglect it? I believe some of them just don’t know how to prepare. If you are in that group — don’t worry! Below you can find some of my subjective tips on how to easily prepare for technical interviews and increase your chances of getting a good job. Interested? Let’s start with actions you can take before an interview.

Plans are nothing, planning is everything” ~Dwight D. Eisenhower

Before interview

“Plans are nothing, planning is everything” — those words said by Dwight D. Eisenhower are still actual, even today, many years after his death. For obvious reasons you don’t know which exact question will be asked during your interview or which data structure will be needed to solve a problem. Nevertheless, you can (and you should) prepare yourself before an interview. There are many websites with typical programming tasks where you can practice — like Hackerrank or Leetcode. There are awesome, but the majority of candidates already know how to use them so I will not describe them in detail in that article. It’s enough to mention they contain many programming/algorithmic problems in different programming languages and on different levels. You can practice problem-solving on them writing your code in an interactive workspace and checking solutions via automated tests. If you don’t know them yet, you definitely should try them! You can also check the “Cracking the coding interview” book written by Gayle Laakmann McDowell where you can also find a lot of interesting problems and solutions for them. However, in this article, I will focus on (unfortunately) less known actions you can take before the interview.

Mock interview

A mock interview is probably the most beneficial thing you can do before your real meeting at the company. It’s nothing else but conducting a “test” interview where the stake is not a job offer but the rest should be as similar to a normal one as possible. So you have an interviewer (ideally someone with bigger experience than you), time limit (about 1 hour), and task to solve and/or technical questions to answer. You both should behave the same way as during a normal interview — so no breaks, no repeats, no inside jokes, no friend’s tips. In the end, the interviewer should give you feedback — what was good and what areas you can still improve — it is an invaluable benefit of that method. What is more, you can practice how you behave in given situations and understand what you can expect. In effect, your stress level during the real interview should be lower as your brain has already “seen” a situation like that and know how to react. Sadly, it’s also the most difficult to conduct one from my tips. Why? Because you need help from a real person here and you both have to spend some time on preparations and conducting the meeting. However, if it’s only possible I strongly encourage you to test it — especially if you are at the beginning of your career and you don’t have much experience with recruiting processes.

Recall your previous projects and experiences

The next thing you can do before an interview is much easier to prepare — you just need some time and something to take notes. It’s also simple to apply — you just need to recall your previous projects and work experiences. Almost all companies will ask you about it. You can prepare yourself in advance and just refresh your memory to avoid wasting time for that during the interview. Ask yourself: is there any project you are especially proud of? Or something you could do better/differently now? What was the technological stack or the biggest challenge in a project you finished some years ago but it’s still in your CV? How you can describe your current project in a few words for someone who never heard about it before? Even if that questions are simple at first glance, thinking about the answers before an interview will help you to choose good examples, remember important/interesting details, and also increase your self-confidence.

Recall Big-O notation

Questions about experience are not only a must-have at technical interviews, but almost everywhere you can also expect questions about Big-O notation. Probably, you remember the basics about it but check also complexity for important data structures and algorithms. Do you remember how to estimate the algorithm’s complexity?

Prepare your questions for the interviewer

Almost every interview has at least some minutes for your questions on agenda. It’s good to know about it and use that time — just think before the interview about what you wish to know. It may be e.g. question about the team’s daily work, current challenges, technical stack, possibilities to grow, or what a given person likes in the company. I recommend writing your questions on the paper — time for them is typically at the end of the meeting so you can be stressed/tired and have a problem with recalling them. Probably, you have a lot of questions about your future company or team — don’t lose an opportunity to have them answered.

During the interview

The tips described in the previous section can help you in preparations for the interview but we cannot forget that the most important things are happening actually during the interview. It’s why the majority of my tips are focused exactly on that part. Don’t worry — they are simple and easy to introduce!

Rephrase a problem to solve

It’s a small but powerful tip — many complications in a coding part are caused by misunderstanding of a whole or a part of a question (especially, if it was not written but only said by the interviewer). You can easily avoid confusion, repeating the given problem with your own words and asking the interviewer for confirmation if you understand it correctly. It’s especially useful if you do not use your native language during the interview — some nuances may be lost in translation in your head.

Think about a whole solution before coding

Many developers start coding just after reading the task. They do not think about the overall program but want to start typing as fast as it’s possible. Unfortunately, that approach may cost you a lot of wasted time. Before you start implementing the code just try to sketch the whole solution and how your algorithm should work. Do not focus on implementation details — just think about the general way of solving the problem. Is this fully solving the problem? Are complexity and space restrictions met? What can you do to improve complexity? Answering those questions before implementing can save you from rewriting the whole code in the middle of the time when you discover you forgot about some aspects.

Think out loud

The interviewer’s responsibility during coding interviews is not only to score the candidate but also to give them tips when needed. Don’t forget about it. If you work in complete silence and do not explain your approach I (as an interviewer) cannot help you with problems. I’m trying to understand your idea from a code but don’t know if some mistakes are caused because small implementation mistakes or big problems in the algorithm. You can also save some time because I can show you some bugs in your approach before you implement it (so you don’t have to reimplement a huge part of the code). I know it may be difficult for introverts but in that case, you can at least stop for a while in the beginning (to explain a whole approach) and before more difficult/important parts of your code. Thanks to that you are sure that everyone at the interview is on the same page.

Implement any working solution and improve it later on

A non-optimal but working solution is better than nothing. Sometimes you don’t know how to solve the problem in a perfect way so you are stuck trying to figure out the best possible solution. Time flies but you have no line of code, no proposal on how to address the problem… Probably, you feel it’s not the best scenario. Of course, it may happen that you don’t know how to implement something efficiently. But you cannot give up! Try to find any solution — not optimal, using too much space, etc. Later on, you can analyze its weaknesses and improve them. And upgrading part by part you can come to the best solution. In a real-life, it’s also unpopular to find the best way at the first approach.

Think about edge cases

When we look for the solution we focus on “typical” cases — in the majority of cases the example from the description. But what about more difficult ones? How our approach will work if input will be extremely huge? Or quite opposite — we’ll receive some nulls? Should we worry about incorrect input? How we should e.g. handle problems when we need to divide by zero or data cannot be stored in a typical data structure? You cannot forget about that questions during the interview. Define edge cases for your program and confirm with the interviewer the expected output for them. If you decide to ignore that edge cases to simplify code say that loud — thanks to that you’ll show you analyzed different scenarios.

Split problem into smaller parts

Do you know how to eat an elephant? One bite at a time! It works for a code too. You don’t have to implement everything at once. Create a general algorithm and extract some logic to separate functions. E.g. if you need in your main program logic for comparing complex items just create an empty helper function with the correct name, assume it works correctly, and use it — you can implement the body of the function later on. Thanks to that you do not lose concentration on the biggest problem and avoid being overwhelmed by the swelling problems. Solving many small but well-defined problems is easier.

Use meaningful names

Yes, I know that time during the interview is limited. And because of that we sometimes use names like a, tmp or array. It’s not a huge mistake — but it can cost you a lot. If your code solves the problem more difficult than adding two numbers, there are a lot of things that can go wrong — using an incorrect variable, typos, etc. Finding bugs in code full of tmp1, tmp2, etc is not easy. So, just use more meaningful names from the beginning — it will help a lot in debugging and show your craftsmanship in development.

Test your code line by line

“OK, it should work” — that is one of the most popular words I hear at the end of a coding part of interviews. But how can we know it will really work? Especially if we cannot just run the code. My suggestion is to test your code line by line against some typical output. How exactly it works? You can just take an example input and explain line by line what will be a state of the program for given input at a given line (e.g. what value will be stored in variables, what will be stored in an array, what will be printed in the console, etc). If you have time, do it for at least two different inputs with two different expected outputs — thanks to that you can find (and fix) small mistakes or prove your solution is working. Moreover, you’ll be sure the interviewer fully understands your code.

Refactor if you still have a time

Let’s be honest — code written during the interview can be really ugly. Time is limited so code is not the cleanest or the most optimal. Everyone understands that. But if you still have time at the end of the interview it’s a good habit to refactor your code. It may not only reduce complexity (so improve solution) but also presents your good habits. All in all, you will refactor your production code at the end of development, won’t you?

After interview

When you finish the interview majority of the work is done — you can wait for the final decision (and hopefully an offer). But even after the interview, there are some small things you can do to improve your skills. First of all, think again about the problem (especially if you couldn’t finish it in a given time). Is there anything you could do differently? Can you somehow improve your code? Maybe given more time you see a better approach to solving it? What lessons you can take from that experience to improve your next interview? Secondly, ** ask for feedback**. All good companies have that step already in their processes but if you have no assessment, don’t be afraid of asking. Notes from the recruiter may be the best way to understand what is your strengths and weaknesses. And based on them you can update your learning plan — even if the answer was positive. After all, we are all learning something all the time

Summary

All the tips described above are the results of my subjective opinions and may not be 100% accurate in your case. However, I strongly believe they can help you to increase your scores at technical interviews. All of them are easy to understand, simple to introduce, and do not need any special tools or resources. Also, they are completely independent — you can use only part of them you find useful and ignore ones not applicable in your case. What is the most important — just prepare yourself to interview. Don’t let laziness or ignorance limit your potential. Show yourself from the best side — your dream work is definitely worth that. I keep my fingers crossed for you!