Recently, I’ve been looking for new jobs - typically through your standard methods of LinkedIn, direct applications, Indeed, etc. While a good amount of this application process is stuff you generally associate with the tasks of applying to any job (brushing up the resume, making your profiles look good and up to date, practicing interview questions, etc), there is one aspect of the preparation I’ve been doing that feels uniquely “software engineering”: Leetcode. Which brings me to my main thought.

I’m not convinced of the value of Leetcode.

I don’t mean that they’re not inherently valuable, in that they don’t actually contribute anything to a person as a programmer. In fact, I think that the things that Leetcode (and Hackerrank, etc) can teach you about the fundamentals of programming solutions to certain niche problems are really good for people to learn. I’m just not convinced that it’s good interview prep.

I know that there are some companies that see Leetcode and other such platforms’ questions as a way of differentiating “good” progammers from “poor” programmers, primarily the FAANG (is that what they’re still called?) companies that have hundreds or thousands of applications to very few positions, and in that case I think they’re actually an okay method of allowing some level of differentiation between applicants and their baseline knowledge of algorithmic approach and complexity analysis. Generally though I’m not sure that companies should be asking them during (or, compiler forbid, before) their interviews.

Interviews for SWE roles should ideally be a showcase of how a candidate can approach a problem, and I think Leetcode tends to push people towards rote memorisation of the potential solutions to any problem.

Consider the following scenario: you’re a person (like myself) who likes to wake up in the morning and do your traditional “dailies” - the NY Times Connections, Wordles, Dots of the world - and you incorporate the daily Leetcode problem into that set of daily rituals. You open that problem, and it’s a Medium, and the first and foremost thing you do (after the zeroth thing of, well, reading the question to begin with) is you run through the list of every possible approach to any Leetcode problem you have done in the past six months. Your brain ends up pattern matching the potential solutions to any problem: is it Mappable? Is it two-pointers? Does it require a sort? Et cetera, et cetera.

This approach, in my opinion, isn’t awful for the fundamental types of questions that Leetcode wants you to solve. It does, however, cause an issue when it comes to interviewing. You shouldn’t be loudly (or, even worse, silently) pattern matching potential solutions to the simple problem of “turn this array into a hash table” that you get given, because that’s not the point of the question.

These questions are typically either:

• Easy, so that it’s moreso an identification of “can you do this?” or
• Challenging, so that it’s an assessment of how you think, act and - most importantly - question under pressure.

That second one is the most important part, both for the interviewer and for the interviewed. I think the best interviews I’ve had are the ones where I almost crumble, not because I enjoy that, but because the act of not knowing what to do and having that conversation with someone to figure out a solution together is really enjoyable, and a great indicator of what it’s like to be on a team with that group of people.

That, I think, is the principle failing of Leetcode-esque questions: you can’t ask those clarifying questions that you can in an interview without really spoiling a good portion of the act of figuring out the approach to getting the right answer.

The lack of clarifying questions compounds with (sometimes) unclearly written question descriptions and leads to frustration on the behalf of the solver. Maybe if the questions’ descriptions were better handled, Leetcode questions wouldn’t feel so pointlessly vague and insurmountable without clarification. Perhaps they would be nicer to ask in interviews, and they would feel like they align more closely to what I think their general value is: as algorithmic practice that supplements the other projects every developer should be working on anyway.

Or maybe I’m just lamenting the lack of take-home assignments in any applications I’ve made recently.

</end>