[hardwaresofton]

Yeah that's exactly how it's going to work. Standardized testing is very rarely effective when employed in this fashion as a proxy for "talent" or "drive" or "good employee". It usually ends up being a proxy for something else.

This also pushed the onus on candidate selection even further on to the candidate, when it's clearly a lack of trust from employers that you are capable of what you put on your CV. Testing that should be the burden of the employer, not the employee.

One key difference between software engineering and other engineering disciplines is that there are many more ways to solve most problems, many more problems to solve, and an endless number of customizations. At a concrete level what does the canonical "web app" look like? We can say "3 tier architecture" but that's abstract -- which technologies should you pick? When should you pick ruby over python? What about when you should pick a document store of a relational database (OK that ones kinda easy) -- these are the questions that good engineers can answer and refute -- there's usually not an absolutely right answer, either.

I personally also feel the same way about the CKA (Certified Kubernetes Administrator) -- hire someone with a CKA and sure that means they know the Kubernetes basics/internals (as it stood whenever they took the test), but does that mean they keep up? Experiment with new tech/RFCs/features (so your company doesn't have to with the product on the line)? Can they choose not to use Kubernetes when it's not necessary?

Rather than just building good, multi-layered interview questions with subtly random parts and lots of room for interpretation (to see how they interpret and think about the problem), we just pick these solutions that are somewhat broken from yesteryear (see: it/sysadmin/networking certs).