On Leet Code Interviews

While not a big fan of leet code puzzles myself, I think that many people miss the essence of these interview assignments.

Their aim isn't to throw unusual and complex algorithms at candidates just for the sake of it; instead, it's to evaluate problem-solving skills using a focused and sufficiently generic problem.

When interviewing candidates for the most "hands-on" roles, I present an easy one – something solvable without specific knowledge of advanced algorithms and computer science topics.

The second half of the interview focuses on testing the solution, involving practical aspects like setting up tools, thinking about edge cases, and so on.

It's astonishing how much you can learn about a candidate's understanding of their daily language and tools, communication skills, attention to details, creativity, solutions, API design, and problem-solving abilities when asking to solve a simple puzzle and write tests for it.

I generally prefer discussing day-to-day job topics in a conversation following the coding part. This approach provides a better understanding of the candidate's grasp of what they use and how to build it.

It might surprise you to discover how many individuals are familiar with Redux for example, but lack knowledge of how it works or the ability to build it themselves (entering the territory of problem-solving and solutions design once again).

In conclusion, while leet code interviews may not be everyone's cup of tea, they can provide a valuable framework for assessing a candidate's problem-solving skills and practical abilities.

As such they might have its place in the interview if then combined with a more practical part and a follow-up conversation on day-to-day topics.

Thoughts?