I feel like a large number of software engineer positions interview as if they are looking for computer scientists.
The distinction is subtle, but important in terms of what is needed for the role.
Most software engineers are going to be asked to solve problems and actively avoid recreating algorithms and libraries from scratch while doing so: it represents added time, risk of bugs, and complexity to do so for minimal gain in many cases.
For most software jobs, the more important role when it comes to algorithms is in choosing which algorithm is most relevant to a task, not implementing it from scratch. To do so is often wasting your companies' time.
It's unpopular, but most software engineering (including most of my own career) is closer to a plumber than a scientist. And you know what? We provide a lot of value as plumbers, as unsexy as it sounds.
It's for these reasons that I think leetcode is an unsuitable test for most software engineering positions.
The distinction is subtle, but important in terms of what is needed for the role.
Most software engineers are going to be asked to solve problems and actively avoid recreating algorithms and libraries from scratch while doing so: it represents added time, risk of bugs, and complexity to do so for minimal gain in many cases.
For most software jobs, the more important role when it comes to algorithms is in choosing which algorithm is most relevant to a task, not implementing it from scratch. To do so is often wasting your companies' time.
It's unpopular, but most software engineering (including most of my own career) is closer to a plumber than a scientist. And you know what? We provide a lot of value as plumbers, as unsexy as it sounds.
It's for these reasons that I think leetcode is an unsuitable test for most software engineering positions.