IMHO, neither. Most teams are typically too small to build up interviewing expertise. In my company (which has in the order of several thousands on SWEs), many

IMHO, neither. Most teams are typically too small to build up interviewing expertise. In my company (which has in the order of several thousands on SWEs), many teams don't have expertise for the role they're hiring for (e.g. it's quite common for a team full of golang people to be hiring their first JS dev, for example), so they often reach out to my team for JS hiring expertise, since my team is a platform level team with wide exposure to the web stack and extensive interviewing experience. 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.