And I do 3-4 hiring interviews a week here in NYC. What connections? First show that you can code; a lot don't pass this filter. Then show that you can architect a large distributed system on a whiteboard; a lot of people applying for a senior software engineer position lack the breadth of knowledge and the consideration required.
And after that you'd speak to CTO, where maybe you can say or do something so silly to be rejected; this happens very rarely.
So, genuine question then: What are the final and most important criterion that would be used to differentiate between two completely successful candidates being equal in their performance in your pipeline?
I think the answer to that will give more credit to the comment you are trying to negate.
Yikes! You may want to review laws about hiring... immediately.
Some people have very little idea about load-balancing, DNS, database scaling (replication, sharding, etc), fault tolerance, graceful degradation, queues, throttling, caching, you name it.
https://www.educative.io/courses/grokking-the-system-design-...
This is just every candidate, certainly at the senior level. It’s impossible to use these questions to discern anything. Even asking them to give these details about past real systems they designed you’re just getting the same 5-layer-deep inception rote memorization of everything they could be asked and every follow up contingency.
I mean, hell, that's a great skill. I wish I had it. Then again, I've seen people forced to build "large distributed systems" to solve things I can solve on one thread on one CPU because they don't have my skills. It's almost as if there is more than one skill that qualifies you as "senior" or something!
All of those quotes were because they are all relative terms. Like high-scale meaning 10,000s of concurrent users; and single server for the web app (separate database server, or utilities server for cron jobs, offline processing, etc); and efficient meaning nothing really.
Non-senior SE candidates don't have to do this exercise.