Interviewing for a technical role is often a hazing experiment disguised as valid criteria to select a candidate rather then actual, effective process for hiring said engineer. Take a service like Karat, their entire premise is to help you find quality, candidates and engineers. The trouble with a service like that, is the interview focuses on algorithmic problems and solutions.
What’s wrong with algorithmic based interviews
If you’re hiring for a data scientist or some role where your job is to design complex algorithms dealing with charts, or graphs or any of the myriad of obscure options there are, then yes, use this approach. But are you an Enterprise or Startup building a web app that interfaces to a GraphQL or Rest API with mostly out of the box secret sauce like search, or databases, then you probably don’t need your web developer to know how to convert text into a adjacency matrix or design an algorithm to figure out what the probably is of some event occurring. Or worse yet, implement your own version of insertion sort.
I have a CS degree. I studied trees, graphs and all sorts of things in my design pattern class, about 10 years ago. Not one day in my entire career have I had the need to reach for implementing my own tree or hash table. I’ve used the standard lib.
Hiring managers, know what you’re hiring for
If you’re a hiring manager, please for the love of everything good, understand what your ideal candidate needs to know. If I’m building a React UI, I should know a lot about State, Components, Reducers, Redux, Routing, JSX, maybe some type script and how to interface with a rest or graphql api.
If you’re hiring a backend developer who’s main job will be to design APIs to convert data from one form to another, implement some arcane business logic and integrate into a client application, you should hire someone with a lot of knowledge and experience in your tech stack, about REST vs GraphQL, how HTTP works, how routing works, maybe a little bit of nginx and cli / bash tooling.
If you’re hiring a ML / AI engineer, you should NOT be talking to me.