Software Engineer Interview - Chapter 4.3: Programming exercise interview

What is programming exercise interview?

A programming exercise section is where the candidate is given a technical problem and asked to write a functioning, error-free code on their own, within a specified time limit, without any help from the interviewer, such that it solves the given problem. Unlike a whiteboard exercise, the candidate is required to provide a fully functioning code and not a pseudo-code, or a code that can have some errors. Another difference from whiteboard is that the candidate writes the code with no help or discussion with the interviewer. For programming exercise section, the interviewer is instead a facilitator whose work is to ensure that the candidate is provided a platform where they can code without running into any issues. The goal of the programming exercise section is to verify that the candidate can develop a production level code on their own, that solves a provided problem statement.

What to expect at programming exercise interview?

The programming exercise begins with interviewer setting up a work environment for the interviewer and explaining the rules of the interview section. A problem decription is provided to the candidate for which the candidate must code a solution. Mostly, the problem statement is not modified after it is given. Once this is done, the interviewer hands off the work environment to the candidate, which starts the timer for the section. Some tests may also be provided to verify that the code provided by the candidate achieves the desired goals. The interviewer does not interfere, except probably to notify the candidate on how much time is left, or helping out with any unexpected issues. They also do not discuss the problem / solution / code architecture with the candidate. For the programming exercise section, since the goal is to ensure that the candidate can be a productive developer, so they are also generally allowed to look up documentation on internet, like, using search engines, or StackOverflow, etc., because documentation lookup is something that developers often do in routine work. Once the time runs out, the interviewer collects the work environment back from the candidate.

Preparations / Things to consider

This section covers some of the preparations / things-to-consider for the programming exercise interview.

Considerations similar to ones used in whiteboard

considerations are identified for whiteboard interview

Generally, the problem description will be very to-the-point. It wil ask you to write the code assuming certain behavior for input and output. The answer to almost all questions you may have will be contained in the problem statement. You should write a code assuming those restriction. However, towards the end, if you have time, then you can identify various edge cases, generalized form of input or enhancements that can be applied to the code if the similar feature were being released in a production environment. If you have time, then you can make the changes, else you can simply include comments in the code identifying how you can enhance the code in future. Doing so is similar to this suggestion for whiteboard interview.
As suggested here for whiteboard interview, it may be helpful to write a prseudo-code, and then slowly change it to a working code.
As suggested here for whiteboard interview, it would be a good idea to identify some cases for the edge cases, particularly if the tests are missing.
As suggested here for whiteboard interview, you should use descriptive variable name in your code. This is discussed further in section below

Identify data structure and algorithm before coding

For programming exercise, the first emphasis is to ensure that you provide a working code with correct syntax and which is able to achieve perform expected operations. Let's say that you provide a code but using a naive algorithm full of repeated action and almost not data structures. This would almost definitely signal you as NOT being a viable candidate for a software engineer position. However, if you are able to identify the data structures to use and an improved algorithm, and mention it in your solution (for example, as comments), then that counts as a positive! Even better though, would be if you can spend a few minutes trying to identify the best approach to solve the problem before you start coding. Maybe give yourself ~5 minutes, and in this time, if you can identify the optimal algorithm and code using that, then it would make you stand out as a really good candidate. If you do so, then also add a small code comment summarizing your thought process. This helps convey your thought process to the interviewer since they wouldn't be directly interacting with you.

Aim to write production level code

If you ask your interviewer on whether there's any guidance on code style to use, it is very likely that you'll receive an answer like "do as you feel best" or "do similar to as in your most recent job". In reality though, you should interpret it as "write a code such that it will be reviewed by your peers and eventually deployed to production". Hence, an emphasis should also be put on ensuring code readability and maintainability rather than just writing a giant code.

Ensure that your code has low cognitive complexity. If this is not the case or if a method has become long (~50 lines or more), then you may want to break it and compose using helper methods. Also, if the method is small enough, then don't unnecessarily fragment it just for the sake of having helper methods in your code. If you feel that the interviewer may mistakenly count it as a negative against you, just add a comment mentioning that you are not fragmenting the method because it is small, and doing so can create cognitive burden.
If you are making a custom class, then use getters / setters to access the field. However, don't make a custom class just for the sake of it, and only do so if necessary to solve the problem can benefit from doing so.
Ensure that you are using suitable access modifiers for variables and method, i.e. as much possible, all helper methods should be private. All fields of a class should be private. For python, use underscore prefix naming notation to highlight that a method is private.
If applicable, ensure that the getter methods do not leak reference. Create a copy of the original object before returning it from getter methods. This improves thread-safety of the code. Do a general review of your code to identify if it is thread-safe and uses immutable data structures. If you identify issues, then fix them or at least identify them in a comment as something that should be fixed. Simlarly, if you identify that a particular code section is parallelizable, then at least mention it in a code comment.
Use descriptive variable names. Follow the naming convention as used in the language.
Add javadoc or docstring over method describing what the method does. I wouldn't suggest discussing the implementation of the method in the docstring, unless it is critical to understanding the caveats of method. Sparingly add comments in the code to highlight features / implementation choice in the code that may not be immediately apparent to the someone reading it, and is also not described by the method level documentation. If you want to do some enhancement but don't have time for it, those can also be described using a comment; But check with your interviewer before you do that!
Externalize constants used in code. If possible, pass the constants as parameters to the method.
Identify if there are any places in you code where you'd like to add log statements and what information you'd want to collect in the logs.

Things to observe during the interview

Every thing up to now has been about how you should be ready for a programming exercise interview. However, an interview is a two-way communication! This means, you can, and should also observe the interviewer to get a glimpse of workplace culture. There are common points that can be observed in all interviews and they are discussed in a later chapter.

First and foremost, did the interviewer identify that it is a programming exercise section and not a whiteboard interview section, or told you that it's not necessary to explain your solution. In this section, since the interviewer doesn't require any interaction from the candidate, so, to prevent the candidate from wasting time in speaking aloud or explaining whatever they are coding, the interviewer must give clear instructions to the candidate. If these instructions are not given, then it shows that the company doesn't prioritize clear communications, or doesn't value interviews or new hires as much! Maybe because it expects a high churn of software developers!
Some other behaviors that show a lack of communication or respect for candidates / new hires is if the interviewer doesn't doesn't provide complete instruction at the beginning and does so after the timer has already started. Providing a time-check is another small favor that an interviewer can do for the candidate without biasing the interview process; So, a failure to incorporate the basic courtesies highlight a non-mature interview process, which indicates that the existing software engineers who agreed to setting the interview process don't view these communication as being important.
Not stating that a production level code is expected from the candidate, but using related criteria to judge the code written by the candidate is another example of a communication failure on company's part. This reflects poorly on the company culture.