Sadly, I think more and more companies are posting for jobs/positions they don't really have available/open at the moment and are just proactively trying to find potential workers (because this whole hiring process is a mess and take so long).
Hiring is becoming an always on activity.
I can offer this bit of perspective on the practice, without justifying it because I do think it's bad. We (again, engineers) spent a long time pushing for hiring to move away from the desperate search because we need someone immediately model to keep our lanes open for whenever someone awesome is looking for a job. Management finally bought into the idea...kinda. Basically, what we're doing is the mixed up interpretation of a that idea, after it passed through the bureaucracy. Instead of keeping just a line open, we're still trawling with big nets, scooping up way too many resumes and letting those people down.
The root of the problem as far as I can see is that screening is atrocious. The people at the front end of the process, the actual recruiters, have no idea what we are looking for, and the output may as well be random. I still don't know how to fix it. :/
One is to have the hiring manager or someone who would be working alongside the new hire write the job description and not allow the recruiter to write it (no “17 years of experience in Airflow”).
Another is to have an engineer do a phone screen after the recruiter has screened them. Having the recruiter listen in is good as they will hopefully learn more about what is wanted.
Another is to carefully set the recruiter comp to take into account not only hires but percent that fail a phone screen.
Your recruiters aren’t your enemy but they are recruiting, not programming (you probably couldn’t do their job either) so there will always be a mismatch to some degree.
There are also people interviewing just for practice or to find a way to negotiate a raise with their management.
Much better to get someone qualified in the first place.
I typically use a small coding test, but not even as elaborate as described in this post — more like a 10 or 15 minute discussion/problem just to see if they really do know what std::string is or how to use an op amp or whatever. Some people can really bullshit well. Consider this the simple “do they know which end of the knife to grab when picking one up?” test.
Once that is clear, a conversation (usually just a conversation about a hypothetical problem) works well.
I don’t understand the coding tests that test your tools knowledge btw. If you know how to think and are somewhat familiar with the appropriate language then you can pick up the specific tools and frameworks. We hire for the long term so said tools and frameworks will change anyway.