Hire an individual. Don't hire an old person or a young person or a guy or a girl or a... just.. don't.
An individual at age 40 is generally more qualified than he or she was at age 25. However, absent of other context the fact that one individual is 25 and another is 40 has no bearing on the prediction of whether the one individual or the other is a better fit for a technical role. Go for the individual who can show adaptability and/or a history of compounding success in the areas that you need.
My anecdote:
I once had an argument with my former non-technical manager. She was arguing in favor of hiring a woman in her late 30s with two masters degrees to serve as a lead software architect. The degrees were in two subfields of physics, one theoretical, one applied. This would be the candidate's first position outside of academia. I participated in the candidate's entire interview process, and I recommended against hiring her for any position. She didn't have enough experience and she was awful at all of the technical portions of the interview process, especially her code. At the same time I was arguing that I should've been the lead, as this was a position the rest of the team had thrust me into and I was effective in the role. The manager's argument was that the candidate was more qualified. After some discussion, "more qualified" turned out to mean older (we both agreed the degrees weren't a strong indicator).
In the end, the candidate was hired for nearly twice my salary (apparently upper management likes letters after a candidate's name). She never fit the lead role, so the team never accepted her for it. Further, she was very ineffective as a developer (we were working in Java, her experience was in Matlab and R), so we either had to refactor a lot of her work or let it go to review and decline to accept it. Everything that went her way took months longer than necessary. In the end I think she wound up working in some type of higher-end sales/administrative capacity.
Being at least an average coder is a prerequisite to leading a team of coders.
A team lead that can't code is like an Army officer that can't pass his physical tests or clean his rifle. He will not have the respect of the rank and file. A team lead (as opposed to a project manager) that can't code is doomed.
(Notice I don't mention language, a good programmer can be coding in something new within a week or maybe two and after a couple of months should be completely fluent.)
> a good programmer can be coding in something new within a week or maybe two and after a couple of months should be completely fluent.
It's a risky choice.
The project we were working on had very, very heavy emphasis on idiomatic Java. In this situation a good manager would need to recognize the deficit in the prospective lead and only ever accept the candidate if they have a rock-solid track record of success, if the team is proficient enough with the language that they can fill in the architect's gaps, and most importantly, if the team is on board.
Unless you have a very mature team that has bought into the leadership of this individual, deficit in language skills might be perceived as a deficit in overall skill, and the team will have difficulty accepting the new leadership.
[Edit: My very, very strong preference is to never hire leads. Hire team members, pay them what they're worth with frequent raises for good performance, and let the team decide who does what.]
Agreed. Learning a language is one thing. Learning its libraries is another; a stack a third; its idioms a fourth; its broad patterns a fifth. The J2EE part of my resume is an alphabet soup of supporting technologies. Rails is almost as bad, just with double entendres instead of acronyms. If you're learning the basics as you go, how are you going to make strategic, architect-level decisions? Did this potential hire ever encounter MVC in her work with Matlab/R?
I've never understood why the common line is that any good hacker can pick up a new language and be just as effective as someone who has used it for year in a short time.
I've been thrown into overdue projects in languages I hadn't used before, and have been able to start fixing bugs almost immediately... but "tweaking existing code" is a far cry from implementing new functionality, which in turn is far below making architectural decisions.
Languages exist in ecosystems that develop over years; knowing those ecosystems in depth takes a lot of time.
Absolutely--however, there are issues with rockstar/lone-wolf devs.
My old boss was an amazing coder--dropped KLOCs like you wouldn't believe, very smart guy, and could debug damned near anything through sheer stubbornness. I respected his technical skill and learned a lot from him. :)
That said, leading a team is more than just being able to catch the ball when your subordinates drop--it's structuring things so that the balls are small enough and obvious enough that even a greenhorn can make useful progress, it's making a supportive environment and architecture that is able to be extended without your supervision.
Depends on what the "lead" means. Certainly, he won't be able to be a technical lead, but non-technical people can lead technical people on other senses as long as the leader is humble, recognizes his shortcomings, and is willing to listen to and apply advice.
It is extremely arrogant for developers to believe the only thing of value a leader can bring to the table is coding chops. Compared to what it really takes, coding chops are immaterial.
While that is fair enough, I've never seen a company put a non-technical person in a lead technical role. Conversely, I've see no end of "a non-engineer can't manage engineers", which is what this feels like.
Of course, all other qualities being equal, having the addition of technical skills on top of managerial skills is good, but I've had more non-technical bosses I'd choose to work for again than technical bosses.
An individual at age 40 is generally more qualified than he or she was at age 25. However, absent of other context the fact that one individual is 25 and another is 40 has no bearing on the prediction of whether the one individual or the other is a better fit for a technical role. Go for the individual who can show adaptability and/or a history of compounding success in the areas that you need.
My anecdote:
I once had an argument with my former non-technical manager. She was arguing in favor of hiring a woman in her late 30s with two masters degrees to serve as a lead software architect. The degrees were in two subfields of physics, one theoretical, one applied. This would be the candidate's first position outside of academia. I participated in the candidate's entire interview process, and I recommended against hiring her for any position. She didn't have enough experience and she was awful at all of the technical portions of the interview process, especially her code. At the same time I was arguing that I should've been the lead, as this was a position the rest of the team had thrust me into and I was effective in the role. The manager's argument was that the candidate was more qualified. After some discussion, "more qualified" turned out to mean older (we both agreed the degrees weren't a strong indicator).
In the end, the candidate was hired for nearly twice my salary (apparently upper management likes letters after a candidate's name). She never fit the lead role, so the team never accepted her for it. Further, she was very ineffective as a developer (we were working in Java, her experience was in Matlab and R), so we either had to refactor a lot of her work or let it go to review and decline to accept it. Everything that went her way took months longer than necessary. In the end I think she wound up working in some type of higher-end sales/administrative capacity.