I'll just throw out there that one reason I think coding interviews have some sort of value is because there are very few metrics to distinguish good engineers

I'll just throw out there that one reason I think coding interviews have some sort of value is because there are very few metrics to distinguish good engineers vs bad engineers when it comes to software engineering apart from working with them. For example someone was the lead Senior Engineer for 10 years at their previous company. Their biggest project was a rewrite and migration of the invoice handling system to optimize for data analysis leading the millions more in revenue. Based on this description I have no idea if this person a) Went to hundreds of meetings around priority, resources and timelines while other engineers did the actual work. While he went to the big wig meetings as the technical resources because he was trying to make optimal "architecture decisions" not because of talent but because his role as lead was built on having been with the company 10 years he knew how to navigate the internal politics as well as being an SME in the companies specific systems. or B) He was making major architectural decisions, leading the engineering team, mentoring other engineers, helping ensure best practices and trying to find time to squeeze coding in while trying to prevent the PMs and Execs from making the wrong decisions and getting the wrong ideas. The problem is these pieces of information can be hard to distinguish between based on the information that most people have access to during the hiring process. Now the looking at the github can be useful but if you are applying at a large organization a lot of the rules and processes are controlled not by the hiring manager but by HR who is trying to avoid anything that could lead to a lawsuit, so hiring managers have to try and navigate this field in a sub-optimal way.