Disclaimer

I initially posted this article on Substack, but as it doesn't have a proper code formatting tool yet, I decided to move it here.

Introduction

After 7 years working as a Software Engineer, I have done a lot of interviews. Most of them were introduction calls, technical introductions and past experience, and some live coding interviews, projects, software architecture screenings, and some hacker rank problems.

I wanted to share the knowledge acquired in this process, so that others can prepare for when their live coding interview comes, or just to understand how the interviews are.

The Series

1. Introduction
2. Webhook Log Parser
3. Coming Soon

I will be sharing the content in the form of a series of posts, each one with a different challenge.

I plan to share my experience with:

• Live coding interviews
• Hacker rank/leet code challenges
• Code projects
• Software architecture screenings

I will not be sharing the name of the company of the challenge in the post, for obvious reasons. For the same obvious reasons, I will not be sharing the challenges from positions I am currently in the process, or have been in the recent past.

I will try my best to provide the thought process and the most efficient answers to the challenges, as well as what I did and my outcome for them.

Preparing for an Interview

If you landed here, it is likely that you are preparing yourself for a live coding interview, or a tech challenge. Here are some tips that apply to all the interviews I have done, and to the tech challenges as well.

Live Coding interviews

Almost if not all my live coding interviews started with a brief introduction of the interviewer, followed by an introduction of myself, and then straight to the code. Be mindful of the time box, and try to start with the simplest parts first, as you may not have time to finish all the requirements.

Read the description multiple times, interpret it, and ask the interviewer if your interpretation is correct. Think of edge cases from the start, but don’t waste too much time thinking about them, they will appear during the test. Ask the interviewer if you are allowed to view the documentation for the language you will be using during the live coding, some interviewers allow not only this but googling for some specific scenarios.

In a live coding session, it is almost impossible to have a perfect code. You most likely won’t have the best variable names, and it will probably be a single file. Try to separate the concern as much as you can, either by creating classes in the same file, or by separating them into different methods / functions.

Note: all my live coding experiences were with non-functional languages. It is possible that experiences with functional live coding interviews will differ from this.

While you write your code, remember to ask questions, even if you think the answer is obvious. Most of the times, the interviewer wants to understand how you work in a pair-programming environment.

Another thing that is very important is to test your code as you write it. If you leave this step to when you finish the code, it could happen that part of your code is wrong, and you will have to refactor a good part of it. Catching errors before will benefit you and decrease the time you take on fixing them.

Hacker Rank/Leet Code challenges

Sometimes, the companies will have a challenge before going to a live coding session, or the challenge will be the only technical step in the process.

If you receive a challenge, it may happen to be one with a very weird algorithm that you may never use in your job. Don’t be afraid of them, study algorithms and data structures before. It is possible that the challenge could include more than a single problem, mostly unrelated problems.

Most of the times, once you open the challenge, you have to complete it in a single session. This means that even if you close the window, the timer will continue, and you may lose the chance to work on the problem again.

Again, be mindful of your time, and only start the challenge when you have a time window to actually work on that without interruptions.

In this step, most of the companies don’t allow using Google, but some live coding platforms include the language’s documentation on the sidebar for reference, so use it as much as you can when you are not sure about something.

Code projects

This is the type of test I prefer. You will receive a description of a project you will have to complete, the required features, and some times edge cases and examples to test the code with.

From my experience, most companies will give you about a week to complete the assignment, but this is sometimes flexible, so if you think you will need more time, ask the company and explain the reason.

Read the requirements multiple times. Choose the language you are most familiar with, if possible (sometimes, a specific language is required by the company). Make sure to use git (some companies ask you to anonymize the project, so remember to change your git configuration to use an anonymized email and name for the commits), this will help you and the person reviewing the project to see your progress, or if you need to revert something, it is easier with git.

With code projects, you will be able to search, design, and refactor multiple times the code you are writing. Do that, as much as you need. Start with the basic requirements, structure it in a way that you can do the required features first, and then refactor it to follow the known good practices (SOLID specially).

A very important step that a lot of people forget is to document your project. Add a README.md, include the reasoning behind your design, the chosen language, and the decisions you made. Include the way to run the project, a sample response, and if it is an API, include the API reference (endpoints, response codes and bodies, expected payload, etc).

Architecture screenings

This is similar to live coding: you will have a fixed amount of time, and usually the interview starts with the interviewer introducing themselves, and then you introducing yourself.

Then they will describe a problem, and just like the live coding, be sure to confirm with them if you understood the requirements, the constraints, etc.

Start with the basics, with a simple architecture, and build up from there. The interviewer will also add more challenges during the interview, so there is no need to try to find the perfect solution at first. Give an overall architecture, and improve it.

General preparation and tips

Before any technical interview, read about data structures and algorithms, try to apply them to some sample code. This will help you choose the appropriate structure during the interview.

Try to stay calm during the interview - I know this is very difficult, specially when you really like the company or the job. The more anxious and nervous you are, the chances of forgetting something important are higher.

What I usually do right before interviews is to have my bottle of water prepared, my phone on DND, if not turned off, and notify people you live with that the interview will start. I try to join the meeting around 5 minutes before the scheduled time, and while I wait for the other party to join, I read LinkedIn posts. This helps me calm down a bit.

Check if your laptop has enough battery (better yet if plugged in), and your headset as well. Test your camera and microphone before joining.

At the end of the interview, usually there is a time for you to ask them questions. Prepare yourself beforehand, have a note with the questions you plan to ask. Here are some common questions I usually like to ask:

• Is there space for growth inside the company?
  • Point out if you want to follow the specialist/staff/architectural side, or the management side
• What are the challenges the company faced?
• What languages are used in the company?
• What observability tools are used by the engineering teams?
• What is the balance between new features, maintenance, and tech debts / refactors?
• How is the team composed? Is there a dedicated product person, QA, designer, etc
• How does the average day look like in this position?
• How is the onboarding process once you join the company? Both technical and product-wise
• What do you like most at the company?
• What meetings does the team have?
• How does the team handle documentation?
• Next steps in the process

Select up to 4 questions to make, otherwise you might waste too much time on them.

Other resources

Here are some resources that could help you study and prepare for technical interviews:

• System Design - useful for architectural screenings
• Tech Interview Handbook
• The Software Architecture Chronicles
• Hello Algo - useful to study algorithms and data structures
• CodeCrafters.io
• kdn251/interviews
• Roadmap.sh