This is the 4th part of a four-part series. For those who want to jump ahead, here is a link to the entire framework. In addition, if you want to read the first three parts, they can be found here: first, second, & third.

Review

Now that you have inspected the problem, created a strategy, and coded, all of the hard work is essentially over. The final step is to make sure you review your code. Even if you have only a few minutes at the end of the interview, you want to review your code to make sure you didn’t do anything wrong. It is also better to catch any little mistakes before the interviewer does. In addition to ensuring that the problem you just coded actually works, interviewers want to see that you are someone who checks their code. Working at one of these Big Tech companies means you are sometimes impacting billions of people with your code. Interviewers want to know that you are not someone who ships out bugs.

In the absolute worse case, If you don’t have any time at the end of your interview, make sure you are at least pretending to try and review what you did before your time is up. This isn’t something you should really bank on doing but if you are down to the wire and still want to make it clear you check over your work, just try to go through the motions.

Do not ask “Am I done?”

Do not ask an interviewer “Am I done?”. It shows a lack of confidence in the work that you are doing. Instead, when you think you are finished, immediately start running through one of your input examples. If you followed this framework correctly you should of already explicitly stated what the input and desired output was and drawn up an example (done in step one: inspection)

In addition, there are a few things that you can run through to review your code that we will review in this article.

Questions to ask

Did I prove my runtime complexity?

You should look at the solution you wrote and make sure that it matches the runtime that you stated as you were strategizing. Compare them directly. If you have the time, go through your code and explain the performance of your code in depth.

Did I prove my space complexity?

You should do the same here but for space complexity. Look through the solution you wrote and make sure it matches the space that you stated out as you were strategizing. You can also go line by line and show that some lines incur constant space while others are more expensive.

Did I write up different test cases and process them?

After you try testing your input example, run through a few additional test cases. Start simple and get more complex.

Did I go line by line no matter how trivial?

Did you read through what you actually wrote? Did you read through every line in your function and make sure that it actually does what you think it does? Do you have any ‘off by one errors’? Is your syntax correct? After 30 stressful minutes of inspecting, strategizing and coding under pressure, it can be easy to forget a semicolon. Take it slow if you can and work line by line to make sure nothing is off. You don’t want your interviewer calling out some small error you missed because you were moving too fast.

Did I have to make any changes when reviewing my code?

This is more for your own personal reflection. If you are making the same mistakes and changing the same piece of code every time you do a problem, it should be called out and addressed. For example, if you are always having off by one errors when doing binary search, recognize that. Keep yourself honest here. The more you learn from your frequent mistakes the more you will grow.

If you have time

In a perfect world, you would have time to run through each of these questions at the end of the interview. You would test your code and ensure it is perfect before you finish. The reality is, sometimes you are running short on time and by the end of the interview you feel like there is no time to review.

Even if you only have a few minutes, it is super important for the interviewer to see that you are someone who checks your code. For a lot of interviewers this is just a box they need to check for them to know that you aren’t someone that will send bugs to production.

Conclusion

If you have the time, check your code! If you followed the framework correctly, this should be a super simple run through. Feel proud of yourself once you have finished this step! You can now apply a simple framework to attack every programming interview. This should fuel your confidence and allow you to enter your interview knowing you can handle anything that they throw at you.

Join the community

Looking for a study partner? Hackpack is the most active community of engineers studying for programming interviews. We hold each other accountable, provide support, and fight burnout to study more efficiently and get the job faster.

Apply Here

Events | Youtube | Twitter | LinkedIn | Newsletter