Negotiation and top-down programming in your coding interview
Disclaimer: The following post reflects my experience as a candidate at past interviews, and does not reflect my experience as an interviewer in various companies. I can assure you that using the below-described technique in the final rounds (aka “on-site interviews”) has proven to be successful and ended up getting job offers from world-known industry leaders.
I’m a seasoned software engineer and throughout my career, I have interviewed in several rounds and with many companies of different industry domains.
It’s natural for candidates to get stressed during an interview, especially when they believe they are interviewing for their “dream job”.
Several companies, not just FAANG or FAMGA or other well-known companies use coding interview questions that are based on data structures and algorithms.
Many candidates practice for these interviews using platforms like LeetCode.
When one codes on such a platform, their code is run against a series of test cases, and if all tests pass the candidate will usually continue and solve other questions. In case of a failure, most candidates will try to fix the issues with their code, and submit their code to be tested again.
Many candidates forget that not all companies will actually let you run your coding exercise during the interview, and while that might be frustrating, a candidate might also take this situation to their advantage.
It is well-known fact that interviewers want to hear the train of thought of their candidates.
A candidate cannot simply write down the code with no explanations.
When we look at a problem, it usually can be divided into smaller parts. The main part will be the main algorithm or flow we’re trying to solve, and the smaller parts will be subproblems/functions/helpers that will be used or solved in order to provide the overall problem.
Some of these smaller parts are easy problems to solve for seasoned engineers.
An example of such a smaller part is creating a counts/occurrences map from a given string.
Other examples might be:
a. Checking if a binary node is a leaf
b. Checking if a coordinate is within the boundaries of a matrix
A candidate solving a question may ask the interviewer if it's ok to defer the implementation of the simpler problem to a later part of the interview, if time permits, and suggest focusing on the more interesting/challenging part of the interview.
A candidate may also ask to defer the implementation of “boilerplate code”, for example, they may mention that they know a class in Java should have constructors, probably an all argument one, and have getters (and maybe setters) and offer to implement them at the end of the interview.
In some cases, even if there is time left, the interviewer may decide they have gained enough positive data points/signals and will allow the candidate to not implement the smaller subproblems.
You can achieve division to subproblems by using a “top-down” approach to your code and use stubbed functions. I will demonstrate this approach in the attached code snippets: