From a hiring perspective, it cuts down the size of your candidate pool. Interviewing is expensive, so it’s better to choose from 5 people instead of 30.
From a personal perspective, I don’t want to work with you if you don’t know how to use a hashmap. There’s a difference between filtering duplicates efficiently and validating a binary tree, so it does it some injustice to lump it all together as irrelevant algorithms testing.
To me the way your teacher described Calculus as something that differiantiates two job candidates that are equally qualified it seems more like an Order Winner, but you then went on to say you should narrow your whole group of candidates by that. You shouldn’t cut down your whole pool of candidates by an Order Winner, but by an Order Qualifier. As an example if you’re hiring web developers they may pass an Order Qualifier if they have necessary web development skills. The Order Winner might be that they have good people skills. That may be backwards depending on what you need gaurenteed more. If you feel they can be trained you can certainly do it the other way around. It all depends on what you feel qualifies them and what differentiates them in the final choice.
If the process is giving equal outputs to multiple candidates, then you might need to fix it to be more granular. There's plenty of room for subjective criteria, e.g. it shouldn't be hard to have a few ranks on "seems nice to work with" metric and so it shouldn't be hard to have a process where equal outputs are unlikely.
On the other hand there's the concept of a journeyman in the craft world, anyone with that level of skill is basically interchangeable for the usual jobs. So you might by design have a test that just outputs "at least journeyman level" or not, and you can just hire the first one you find.
Well, I suppose if we only look at first year college grad, there is a lot of duplicates.
Front-end devs don't need to understand algorithms?
I'm sure database admins would be less than thrilled to have to duplicate a mock in CSS. You wouldn't judge an electrician on their carpentry. It's a tired subject that a lot of companies still seem to have trouble grasping.
People will tell you all sorts of things.
It's objectionable because it doesn't test the skill set that would be used on the job.
Maybe they just say that because that's easier than investing the time to develop a good understanding of basic algorithms?
Don't get me wrong... I'm all about specialization of labor and all that, and I'm not saying every programmer in the world needs to be able to write a provably correct implementation of a PriorityQueue from scratch, at the drop of a hat. But I would argue that all developers, front-end or otherwise, benefit from algorithmic knowledge, and that it is reasonable to test front-end devs on that knowledge - to a point.
And given how much more complex "web apps" are becoming with pretty complex SPA's delivered with lots of complex logic executing on the "front end" I think that's become even more true over the past few years. It's not like "Front end developer" means "person who does CSS styling and can add a few neat effects to a page using javascript".
You wouldn't judge an electrician on their carpentry.
No you wouldn't but that analogy really doesn't fit the present discussion at all.
I think it must be a relic of the Google-style interview cargo cult approach to hiring.
Far too often, the technical expert solves a problem on the basis of their current solution space tools and not what the actual problem requires. In other words, they cannot think outside of the solution space box they are stuck in.
Knowing that there are all sorts of algorithms available for all sorts of variations of problems and knowing where you can get the information to implement a solution to your problem is a lot better than being able to reel off one or two algorithms and not know that there are other solutions.
Over the decades, I have become involved with various projects that were created by "programming guru's". They knew the systems involved and made solutions that showed off their "guru-bility". The problem - well the systems were a nightmare to make changes to. They used "industry standard" practise and supplied a solution that forced people to change how they did their business, without actually considering the business at hand.
One such system was built using dynamically generated SQL. Had the original "guru" actually thought more carefully about the problem in hand, no dynamically generated SQL would have been needed and making changes to the system would not have been difficult. In that particular case, I was there doing "after the fact" technical and functional specs. As part of my package of documentation, I included a specification for rebuilding the entire system so that it would be very easy to maintain and change and the runtime for each system run would have been (on my estimates) reduced to about 5% or less on then runtime of 25 hours.
To get everything back on track generally required rewrites (sometimes complete rewrites) to be able to extend these systems.
It is our responsibility to enhance the end-user experience not make life easy for ourselves.
Let's not forget companies that send algo-heavy tests for front end roles (my personal favorite). Can't they come up with a front end version? Is it better that they don't?
I'd find it, and similar sites, less objectionable if they were used as interview "extra credit," rather than as gatekeeper screening tools.