But the caveat is that my domain is still rather specialized. Whereas many backend teams often rely on more leetcodey interview sessions, the type of pure algorithm sessions that Google uses are widely considered bad interview practice among JS candidates and interviewers alike because they tend to test absolutely nothing of what a JS person will normally encounter.
What I believe works better is some standardization in terms of having a set of people who have expertise on a domain and who can become highly calibrated in relevant interview topics within their domain through repeated interviewing. But not overly broad standardization that tries to use a single global criteria to evaluate for completely disparate domains. What a "domain" is depends on how much specialization is expected of an engineer based on the company size, team structures, employee growth strategy, etc. E.g. "backend" might be a domain, "golang" might be a domain, "infra" might be a domain, "security" might be a domain, and all of these may have overlapping concerns, but different curation of interview topics depending on where you'd expect to see the new hire 5 years down the road.