"I'm not really sure how this is true. I find that I can judge a software engineer very accurately based on his previous work, and intuit from the code a great deal of the context."
To each their own, I suppose. Applicant-submitted code samples don't correlate strongly with hiring decisions, in my experience. They're too easy to fake, and don't capture the things you want to know about interpersonal communication, thinking style, etc.
Crass Generalization: I think people who strongly emphasize code samples over everything else are sacrificing a chicken to the hiring gods. It smells very cargo-cult.
"It would be very easy to evaluate the senior engineers by evaluating their components, whereas the junior and/or average engineers can only really be evaluated in context by the senior ones."
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.
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.
> 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.
Applicant-submitted code samples don't correlate strongly with hiring decisions, in my experience. They're too easy to fake, and don't capture the things you want to know about interpersonal communication, thinking style, etc.
Yes, by themselves they're not much good, but if you explicitly ask for a recent piece of code that they're proud of, you can ask them questions about it: "Why did you use data structure X?", or "How does function Y work?" Much, much harder to fake.
To each their own, I suppose. Applicant-submitted code samples don't correlate strongly with hiring decisions, in my experience. They're too easy to fake, and don't capture the things you want to know about interpersonal communication, thinking style, etc.
Crass Generalization: I think people who strongly emphasize code samples over everything else are sacrificing a chicken to the hiring gods. It smells very cargo-cult.
"It would be very easy to evaluate the senior engineers by evaluating their components, whereas the junior and/or average engineers can only really be evaluated in context by the senior ones."
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.
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.