Technical Interview at Alan

You want to join the engineering community at Alan? You started the hiring process or planned to do it and wonder what is the best way to prepare for our tech interviews? Here, we’ll give you an overview of the format of the first tech interview at Alan, and reveal a bit more about our expectations.

🤔 When does it happen?

The first technical interview at Alan comes after a screening interview and a written interview where we make sure the candidate’s motivations and expectations are aligned with what we offer.

It is the first time we will assess your technical skills through the resolution of a coding exercise. (but not the last 😜)

🎯 The goal of the interview

The format and difficulty of the coding challenge is the same for all candidates, but don’t worry, it is basically made to check if you can code and test a simple interface, with little algorithmic complexity. Of course if you finish the exercise we might deepen the discussion with bonus questions 🤓.

NB: all our technical interviews are LIVE. We believe live resolutions enable us to get a much better understanding of your skills while saving you precious time! Indeed we pay as much attention to your technical level as to the structure of your resolution strategy. Clear communication during the session is critical : the live interaction with the interviewer is a good way for us to see how you welcome and use feedback from your peers.

Set up of the interview

A live coding session 😱? Please tell me more!

🕵️ The interviewer

The technical interviewer is always an Alan Software Engineer. Our communities are deeply involved in the recruitment process of their peers, it is a great opportunity for you to meet a potential future colleague and get to know our way of working! They are really here to guide you during the exercise, and make sure you do not stay blocked on potential problems for too long. Again the more interactions you will have with them, the more inputs they will gather to assess your level.

⏳ Resources available

Flexible and powerful, the Alan way:

• Duration of the interview: 55 min for solving the coding exercise and 5 min Q&A about Alan in general.
• Coderpad: Coderpad is a collaborative programming environment. Its live editor enables you to write, execute and debug code in the language of your choice! (more than 30 languages are supported). It also comes with many features like autocomplete, unit testing suites and other common libraries. Nonetheless, we don’t recommend using NodeJS as it requires too much boilerplate.
• Starter code: the interviewer provides a piece of code or pseudo-code to start the exercise inside the coderpad editor.

💡 We advise you to use the free coderpad sandbox to train and discover the environment before the interview, and read their user guide for candidates.

🎨 A simple illustration with the FizzBuzz challenge

To illustrate what is a good resolution strategy, we will resolve in this article a famous coding challenge: FizzBuzz.

The statement is the following:

Write a function that takes a number as input.
- If the number is divisible by 3 (means number % 3 == 0) write Fizz
- If the number is divisible by 5 (means number % 5 == 0) write Buzz
- Else, write the number on the screen

How to start the interview

You start thinking about a solution, your heart rate speeds up… no rush 💆‍♂️

🙋 Understand the problem and explain your strategy before you start

First thing is to be sure you understand the problem. The statement can be purposely vague and requires you to take a step back. For example in the FizzBuzz exercise, we would expect you to explicitly clarify what to do if a number is divisible by 3 and 5 at the same time. Disclaimer: it should print FizzBuzz 😉

Then you should take the time to explain your strategy: it will help you to forecast potential issues, and will give the interviewer a chance to challenge it. You will never be blamed on your first strategy, but heading in the wrong direction will make you lose lots of time!

⚙️ Test run and debug

A great strategy is to start with a basic, sub-optimal implementation that runs. The interviewer will usually wait until you have some tests running before asking you about bugs or performance characteristics.

⚠️ Writing test is mandatory!! Our engineering culture strongly relies on testing. It is key to ensure trust within the community and to build robust products. Overall it should also enable you to develop faster, by anticipating errors and bugs. Depending on your choice of language, Coderpad gives you access to basic testing libraries (e.g. unittest or pytest for python).

💡It is worthwhile to practice writing your own tests on coderpad to prepare for the interview.

Try as much as possible to split the problem into small parts with their own testing classes. It will ease the discussion with the interviewer, and be easier to debug. Also we recommend you to run your code as often as possible. Coderpad gives you a detailed stack trace when errors occur, waiting too long before testing will make it harder to read.

⛳ Simple solution of FizzBuzz challenge

In our example, the implementation is quite straightforward.
A simple solution could be:

🗣️ Interaction with the interviewer: If the interviewer notices a bug or an edge case, they might suggest a test that will surface the bug and see if you catch it:

Here for example the interviewer could ask you to add a testing case where the fizzbuzz function takes a string as input. Would it raise an error? Should you validate the data? There is no single correct answer, but it is worth discussing it with the interviewer 🙂

Optimisation and discussion

🏃 Improve your solution

Once the test coverage is good and the implementation works, the interviewer will drive you toward improving your code.

• If you are familiar with runtime complexity then doing an analysis of your code’s performances is a really good way to start the discussion. Of course we do not expect the same level of awareness for all candidates, but basic knowledge like costs of appending to a list, inserting to a hash table, or standard sorting algorithms are largely sufficient to make a good analysis.
• If not it is not important as long as you are able to improve your code. There are many ways of measuring code performances and we are totally fine with it 🙂

🧗 Going further

At some point the interviewer can also make the challenge more complex to emphasise optimisation issues:

Now we also want to write Alan if the number is divisible by 7

With the new challenge, the basic implementation looks very redundant, and is clearly suboptimal. We expect you to take a step back and challenge the first solution:

🗣️ Interaction with the interviewer: a question from the interviewer about runtime complexity could be: If we call L = [3, 5, 7] the list of all the divisors, could you express the runtime complexity as a function of length(L)?

💅 Refactor

Your testing classes should enable you to refactor your code confidently, don’t forget to adapt them if the exercise evolves. Do not hesitate to try several implementations, as long as you explain your choices and communicate clearly on why you think it is a good idea.

Here is a suggestion of a better solution using a list of tuples to store the words to print. We build the result iteratively so we get rid of useless and redundant list of if statement:

🗣️ Interaction with the interviewer: What would be the new runtime complexity as a function of length(L)? As a function of n?

End of the interview

🕰️ 5min Q&A

Five minutes from the end, the interviewer will end the problem. You should use it to ask any questions about the organisation, the engineering community or ongoing projects at Alan

You’ll get detailed feedback very soon by email 💌

To sum-up:

• Write clear code, carefully name your variables, split your functions
• Use a testing library
• Read and understand a stacktrace
• Communicate clearly with the interviewer

Extra resources to train

• Coding challenge platform : Hackerrank and Codingame are great platforms to train on various challenges!