Reading and assessing resumes and having a single interview with HR and the hiring manager or a panel. And this process should fit within the larger operational framework and processes of a company.

How can 2 measurements (CV + 1 i/v) be better than 8 measurements (CV + 7 i/vs, with different kind of questions, to boot)?

This is a misplaced concreteness fallacy.

This is you deflecting a valid question.

Have you been involved in hiring software engineers much?

Certifications should mean something, not be a sales channel for AWS

That sound terrible. Most jobs are for specialty positions, so you'd need 10,000's of different certifications tracks.

A written engineering competency test (basically, an industry-standard set of whiteboard questions) sounds good, but, having hired credentialed-but-incompetent engineers from other fields, I can definitely say it helps a lot less than you'd think.

There is no reason why we can't have that, and I don't think you'd need that many tracks. Even something as narrow as cybersecurity has several different (ISC)2 tracks. They could have a different cert for each major programming language, for instance.

So, I write mission critical software that sits behind narrow interfaces. In my field, security and correctness are basically synonyms. Other people manage large fleets of machines, and there intrusion detection is probably the best you can do. Still other sets of people write frontend software with 10,000's of dependencies, so dependency management is the name of the game. Still others deal with PII and credit card numbers, and in that space compliance matters deeply.

I could list many more sub-disciplines of cybersecurity, but I'm already up to five (and haven't even mentioned cryptography!). None of the skill sets from the five I mentioned really translate well to each other.

Also, what purpose would having a cert for a programming language serve? For things like C++ and JavaScript, there are so many sub-dialects that the cert wouldn't say much about whether you could write inside a particular code base. For things like rust and go, the certificate would need to expire every few years.

Also, it takes an experienced developer a day or two to pick up a new language. Getting a certificate for a language would take longer than that. That lands us where we are right now, where such certifications exist, but they're simultaneously too much trouble to be worth it, and also not worth the paper they're printed on.