How to solve a coding question in a job interview? Comments First Approach with examples

If you are applying for a programming position, one thing is positive – you will be asked to write some code. On a white board. Without an IDE!!
In this post I will share the way I handle coding questions in a job interview, by asking questions, writing comments, and only then code.

In short – in this way I am sure I will have a well commented code, and even if I won’t have time to implement everything, the interviewer will know how I would solve it if I’d have more.

You might be a great programmer in real life, a coding ninja, a hero or even a superstar, but that might not be enough to be ready for interview questions.

Is your interview tomorrow?? Read this first, and then come back here.

The day to day of writing code involves Googling, reading documentation, consulting with friends and colleagues, having the assistance of your favorite IDE (mine is VSCode at the moment, before it was InteliJ). And hopefully code review and more useful techniques to make your code robust, readable, maintainable and… working.

All of the above does not exist in the environment of the job interview.
In real life, you are not writing code on a white board and then compiling it in your head (unless you are, in this case, please stop reading and leave a comment starting with “IM!=HUMAN”).

What’s different in coding on a white board?

When writing code in an interview:

1. You are by yourself (no Google, no documentation)
2. There’s no autocompletion by your favorite IDE
3. The deadline is very short – there’s pressure in the air
4. Someone is watching you while you code
5. You have to think real fast about the solution

In this post I will present my approach for solving coding questions in a face to face interview. In an approach named Comments First Approach.

It’s nothing fancy, but a way to organize your time for solving a question. It won’t make you succeed if you don’t know the answer. Sorry, didn’t find a technique for that yet 🤓

In case you are interested in practicing for the interview, I suggest reading this post.

The things I want to achieve when solving a question in a job interview

Stop a moment and think about the interviewers. You came to their office, and now they are sitting and watching you while you think and code.
Well, that’s an opportunity to express more of yourself then only answering the question.

I assume you would like them to know you can:

1. Solve the question in a decent time
2. Think about edge cases, weird inputs
3. Care about performance and complexity or at least have it as a consideration in mind
4. Express your familiarity with the language, its tricks and limitations

You don’t only want to solve the question, you want to make an impression.

The problems with thinking while you code approach

In the past, when I was asked an algorithmic question, I thought a bit and jumped straight to the board, starting to write the code as fast as I could.

This led me to code while I am thinking. Needless to say – I wrote the code before I had the complete solution in mind.
While this can work in some cases, it can be not such a good idea:

1. You will have many loops of writing and erasing your code, or entire blocks of it.
2. You might be stuck on a specific syntax problem for a long time before completing the over all solution. For example, forgot if the index is the first or second element in a foreach loop.
3. In some of the cases, when time was up, I ended up with only half of the solution written on the white board, doing the best to explain my intentions verbally to the interviewer.

It can work of course, and many people think while they code in real life 🙂 But in an interview you don’t have time for so many deletions and retries.

Comments first approach for solving a coding question in a job interview

The approach I suggest here, is very simple. This is the recipe:

1. Understand the question and ask for clarifications
2. Write the comments for the code (like you would if there was code inside) – [a bit similar to pseudo code] + get feedback
3. Start implementing code under each comment
4. Run some of the cases in your head to see the code makes sense

By the way, in a face to face interview you are most likely to be asked about your latest project, read here and learn how to craft your answer.

Comments first approach – an example

This is the question we are solving – my own original, copyrights protected, SHLOOF BLOOP (does not resemble to fizz buzz in anyway!!, or is it?)

1. Understand the question and ask for clarifications

Take a moment to think about the solution. Add some more input and output examples of your own.
I am thinking about these examples for inputs: [1,1,1], [‘a’,2], [13,12,1,0].
In an interview, I would present my examples and ask if the output is correct and I understood the question well.

I think I understood the question, but I have some more things I want to be sure of before jumping to the next phase:
Q: Oh, Mrs. interviewer? What about an empty array?
A: “Return and empty string”

Q: Can I assume all the elements are valid numbers, can they be strings, booleans, object??
A: Yes, no need for input validation.
Great, that saved me some time and code.

Ok, now I am all set, I understood the question, demonstrated the way I think about edge cases, and shared all of these with the interviewer.

2. Write the comments for the code (don’t write a single variable yet!)

The goal here is to think about the algorithm, express it in the comments (so eventually you will also have a commented code). After you write it, try to see what’s the response from the interviewer. It won’t work all the time, but it might give you some confidence to see a nod.

Here are my comments for the solution:

Go over the array, have a counter for odd and even numbers, calculate on the go the reduction result of each two neighbor numbers. Use the counters and the reduction result at the end for the return value.

Note that I wrote a comment about input validation, but I don’t think it will be necessary to actually code it.

3. Start implementing code under each comment

You got the green light from the interviewer? Let’s dig into the code.

I believe that in this point the interviewer knows already that you CAN solve the thinking part of the question, it’s only a matter of code.

Here’s my solution:

Yes, this code can be shorter, I know. And that might be the first question the interviewer will ask, and to it I will provide my ideas about optimization of the function I just created.

4. Run some of the cases in your head to see the code makes sense

After the task is complete, you are pretty excited and want to sit for a bit and take a break.

Wait with this for 2 minutes, and run the examples in your head. Do the code above cover the basic scenarios? Does it cover the edge cases it should?

It is perfectly fine to have a 90% bullet proof code.

Conclusion:

Coding without a keyboard, IDE, Google and time can be stressful and annoying. The good news are that you can still express your way of thinking, in depth analysis of a problem and coding skills, without having a 100% compilable (or transpilable) code.

Thanks for reading! Please share and comment if you like this one. I would be happy to hear what would you like to read more about,