> To each their own, I suppose. Applicant-submitted code samples don't correlate strongly with hiring decisions, in my experience.We evaluate their open source code or paid challenge project, not applicant-submitted code samples of unknown origin.
> They're too easy to fake, and don't capture the things you want to know about interpersonal communication, thinking style, etc.
All of those skills are important, but they're moot if an engineering applicant can't actually code.
> Nah, it's always really hard. Some senior engineers don't write a lot of code, but are superb at managing and mentoring teams. Others hole-up in their geek caves, churn out code of varying quality, but are dismal leaders.
You're conflating quite a few areas of responsibility here. Some people are good leaders, but leadership is also where poor engineers will run to if they can't actually code -- this is not something you want to occur in your organization unless they actually belong in management, and even then, you risk those individuals pushing for poor engineering decisions from a position of authority.
If a senior engineer isn't actually designing and writing software, they're not an engineer anymore, and should be evaluated by a distinct criteria. If you require non-coding engineers to provide a small engineering team with direction, then you likely either have an overly junior team, or too many directionless/mediocre engineers.
> My point is: once you've got more than a few people, team dynamics matter at least as much as "rock-star" coding ability (probably more), and you can't tell anything about this from code samples.
Nobody (least of all me) ever used the term "rockstar". There is simply an enormous difference between the efficiency and code quality of great engineers as compared to mediocre ones.
Most of what you're saying sounds like the standard bandaid approaches to big-enterprise engineering management with mediocre teams.