The last stage in the hiring process after the machine learning interview is a coding interview. The interview is also over the phone where you get one or two computer science algorithmic problems to solve in an online coding sandbox. You can choose the programming language, but it’s often assumed to be Python. From my personal exprience and experiences of my friends, it seems that the company puts a higher value on the machine learning interview. Nevetheless, coding interviews are relatively difficult and require good knowledge of computer science basics and strong coding skills. In this post we dicuss the structure of such interview, what to expect, and how to prepare.
The focus of the problems are on simple computer science algorithms, such as binary search, sorting, and hashing. You can expect to get one or two problems to solve over 50 minutes time. The main difficulty here is that a Ph.D. research in machine learning or a related area rarely requires direct applications of such basics. Personally, I can hardly imagine coding the merge sort algorithm during my Ph.D., yet it’s not uncommon to get problems that require a divide-and-conquer strategy during a coding interview.
The best approach, in my opinion, is simply to solve a lot of algorithmic problems to learn the pattern of solving such problems. Also, to refresh basics, for example by re-reading chapters of a book on algorithms. There is a lot of information available online with mock algorithmic problems Cracking the coding interview I would recommend www.leetcode.com and a book Cracking the Coding Interview. The website and the book provide a massive collection of different coding interview questions, correct answers, and strategies how to solve them. Next we discuss what to expect during the interview and how to prepare.
Before the interview you receive a link to a coding sandbox where you’re expected to write your code. The sandbox has only simple functionality, such as syntax highlighting. Moreover, there are no debugging, autocompletion, and error analysis tools (e.g., type checking). Because the sandbox is likely to be very different from an IDE you’re accustomed to, I would strongly recommend practicing coding at leetcode.com or use another platform that provides only a minimalistic software development environment.
Breaking the habit
When one codes a program, it’s tempting to use a debugger to inspect variable assignments and progressively eliminate bugs. This style of code writing becomes a habit that is very hard to break. The bad news is that not only you will not have a debugger during the interview, but also you will not be able to run your program in the provided environment. This makes the interview VERY different from a typical programming experience where sophisticated tools are available at hand. Therefore, you will need to learn to eliminate all bugs before actually running your program. However, not only will it make you better prepared for the interview, but also train you to write bug-free code faster.
I would recommend to have a piece of paper and a pencil in front of you when you practice for the coding interview. Old school, I know, but it really works. When you try to solve a specific problem, it’s very helpful to come up with an example, or write down the provided one. Then try to sketch a logical solution without writing any code. Also, you might find it useful to run the program by recoding data manipulations on the paper sheet and progressively inspect the code. I personally prefer to write down variable assignments and erase and replace with new ones. This helps to track whether the run leads to the correct answer.
Vague problem formulations
When you practice using one of online platforms, you usually get problem formulations that are crystal clear. However, problems that you get during the actual interview are often going to be vaguely defined. Ironically, this is very representative of the real world where a client does not know what he wants, and it’s your job to extract necessary information to build the right solution. This means, from a practical perspective, that you need to ask for clarifications whenever something is not clear or is ambiguous. I also observed that some problems had hidden requirements that needed to be addressed, yet they were not communicated explicitly.
Verbalise of your thinking
While it can feel unnatural, you need to verbalise your thinking during the interview. First of all, the interviewer does not know whether you’re stuck. If so, he can help you by providing tips and suggestions. Additionally, it helps the interviewer to understand whether you’re heading the right direction, and he can guide you accordingly. I would highly recommend to ask your friend or colleague to play a role of an interviewer such that you get used to verbalising your thinking. Alternatively, you can practice verbalisation as you practice coding.
Finally, it’s very common for interviewers to attempt to find corner case scenarios that can break your program. This implies that you need to be careful and consider at least some scenarios that are beyond obvious. For example, what happens if the input string has only one letter? What about if it’s empty? What if the stack is empty and deletion is attempted?
To excel during the interview, you need to invest into preparation. There are no shortcuts, and it’s very unlikely to pass without remembering basics and refreshed algorithm problem solving skills. My recommendation would be to prepare in a similar environment to the one you will be in during the actual coding interview. I.e., simple programming tools, vague problem formulations, and no way to run your program. I wish you the best luck and remember - practice makes it perfect.