I love the art of software development. I love it so much that I talk about design theory, specifications, and testing strategies all day. I have these conversations and debates with many of my friends and co-workers. There is a substantial drive to understand what software really is and how we can make it better. Despite this intense passion, I like to think that I remain reasonable and can change my mind on firmly held positions when presented with new information and experiences. The controversial hiring practice of "The Coding Interview" is one I have held strong opinions on for many years. More specifically, coding interviews with LeetCode-style problems. However, due to some recent experiences, I've changed my mind about this hiring practice.
For those unfamiliar, LeetCode is a platform with thousands of coding challenges with varying difficulty that you are tasked with solving. A test suite is run against submissions to check for completeness. Accepted Submissions are then measured for space and time performance and ranked against all others. LeetCode is often cited as a necessary resource to prepare for technical interviews, especially for new grads and novices. However, many publicly denounce this platform's usefulness and the validity of LeetCode-style coding interviews. Some even go as far as to say things like, "If they want me to solve LeetCode problems, I don't want to work with them anyways."
There are common critiques of the LeetCode-style interview. Firstly, solving these problems does not necessarily make you a great employee to work with. The problems are not representative of the work you'll be doing day-to-day. And finally, candidates are being evaluated on their performance in high-stress and artificial environments. With these in mind, it's unclear how this interview-style could reliably uncover any helpful information about the candidate. The exercise would highlight individuals who practiced jumping through flaming hoops or somehow managed to impress the interviewer in another way.
I've come to appreciate the utility of LeetCode after trying a premium account for a couple of weeks. With LeetCode Premium, more features and functionality unlock. Specifically, access to premium solutions. The solutions teach one how to methodically break down each problem into basic patterns. Difficult problems are often smaller problems that can be recognized with practice and repetition. Usually, there is a somewhat prominent "brute force" solution. After outlining the brute force solution, they continue to reason their way to more optimal solutions. This process can often uncover the most optimal solutions but sometimes will require the application of tricky math, and those are documented as well.
As I worked my way through problems, I noticed a pattern. LeetCode wasn't trying to train me in the arts of data structure and algorithms. Even though that is the natural consequence of practicing, LeetCode was actually teaching me how to solve problems. Not all companies use this interview-style to evaluate candidates' problem-solving abilities. Some may be imitating this as a "best practice" without fundamentally understanding it. But let us assume companies want to hire and keep individuals who can solve arbitrary and ambiguous problems. These individuals are more likely to learn the company's domain, find new solutions to old problems, and adapt to changing requirements. The more a candidate can demonstrate these abilities in an interview, the less risky they appear.
Programming is our means to an end in solving problems with computers. Still, the more elusive and abstract skill of solving a problem is what LeetCode trains us to do. Your ability to solve these problems is contingent on your ability to reason your way to a solution. Your ability to collaborate with the interviewer and explain your reasoning demonstrates whether or not you'll be an excellent employee to work with. The problems aren't supposed to represent those you have and will see daily. If you were given a problem you've seen hundreds of times before, your ability to code a solution to that problem demonstrates nothing more than your muscle memory. You're not expected to produce fantastic software outside of your element. You're showing your ability to recognize patterns, define problems, and develop your own solution. There is no perfect way to measure this skill, but LeetCode-style interviews are not a bad attempt. For these reasons, I've decided that I change my mind about LeetCode.
Austin