The problem with the typical tech recruiter is that they feel their job is to screen out unqualified candidates, but they do not understand technology well enough to understand the candidates, and thus they end up using completely arbitrary criteria. Some of this criteria sounds plausible, especially to junior candidates, and certainly to others in the HR industry who also don't know technology. But it is actually like excluding a receptionist from an interview because her last company had AT&T equipment and the new company has ITT phones!
In my career I've dealt with quite a few people like this, both as a hiring manager and as a candidate. As a hiring manager you get the opportunity to ask them some detailed questions about how they filter candidates, and I even asked one, once, to send me all of the resumes they got for the position, after she'd applied her filter. I went thru the entire stack of resumes myself, and filtered them by looking at them briefly, and then compared the ones I pulled out to hers. There was zero correlation. None of the ones I pulled out she did. All of the ones she pulled out -- and was busy giving me the hard sell on-- were ones I'd excluded. In fact my belief that the pickings couldn't be so slim was the reason I asked her to send me all of them, though I gave her some other excuse at the time. I also pulled twice as many candidates as she did, and was willing to spend up to an hour of my own time on the phone with them.
All of the people in your position think they know what they are doing and think they are good at being able to tell good candidates from bad ones. I understand why this might be, as this seems to be what they think is their job. "Anybody can exclude the janitors-- but I add value by being able to tell good programmers from bad ones!"
If you'd like to be a better recruiter, here's some changes to make:
1. Stop reviewing people's code. I've participated in many code reviews. I've often seen stuff that looked stupid, and asked the programmer about it, and then found out that they were expressing a level of understanding of the problem that was stronger than mine. Makes sense given that it wasn't my code I was reviewing, I was just reviewing, not writing it. That you think you can review someones contributions to open source in isolation is a big red flag. Just stop. Even if you're a great programmer, you can't do it fairly. In fact, if you were good enough to do it, you wouldn't want to do it because you'd know how easily it is to get wrong.
2. Just because someone doesn't list python on their resume, does not mean they wouldn't be a great python programmer. I've been using python off and on since the mid 1990s. I use it for utilities, tools and other support code, not for major projects, and it turns out (I just checked) I never actually put it on my resume. By your statements above I would have a "strong career but zero commercial or practical experience with python".
3. Just because someone has never programmed in python before, does not mean can't be the best candidate for the job. Programming is the talent. Python is a language. If you would say I'm unqualified to drive a ford because I've been driving toyotas, you'd be laughed at, wouldn't you? This is what you're doing. Every language has its strengths and weaknesses, sure. Unless you're hiring someone for a 3-5 week job, the quality of python code produced in the 6th week will have everything to do with the strength of the programmer, and nothing to do with the amount of python they've used in the past.
4. I once was interviewed by a recruiter and it became immediately obvious he was something special. I could tell he wasn't technical, so after he said he'd be setting up an interview with the hiring manager, I asked him how he'd come to the decision. He gave me a solution that you, and every non-technical person can apply, which is really quite brilliant: He said (paraphrasing) "I look for three things: ABC: Attitude, Bandwidth and Confidence. If they have a positive attitude, can explain things well to show they have a bright mind, and have some confidence, then I ask them a follow up question. I ask them to tell me about some technical thing they did that they're proud of. If my eyes glaze over, I know they are qualified to pass on." He didn't have to understand what the thing was, but he was uncanny in finding great candidates... in large part because his reputation caused them to seek him out. Maybe someone could bullshit him with a bunch of technical jargon that he didn't understand, that's fine, that's not his job. The idea of him judging my code is absurd, and would be to him too.
Please take this in the spirit it is intended, which is constructively.
> Please take this in the spirit it is intended, which is constructively.
It's difficult given the immense air of condescension.
1: Stop reviewing peoples code: You may want to have a chat with some of the countries top programmers & hiring managers. Almost all of my clients insist on seeing examples of the candidates code before interviewing them. I review the code first myself to ensure I am sending someone worthwhile.
2: Just because someone doesn't list python on their resume, does not mean they wouldn't be a great python programmer: If you have the wealth of Python experience you are claiming and were applying for a Python Dev role would you really not alter your CV to reflect your relevance for the role? That would be lazy and counter-productive giving an instant indication of your attitude.
3: Just because someone has never programmed in python before, does not mean can't be the best candidate for the job. If you would say I'm unqualified to drive a ford because I've been driving toyotas, you'd be laughed at, wouldn't you? That is a ridiculous analogy. There is absolutely zero difference in the machinations of driving a Ford over a Toyota whereas there is a significantly larger learning curve for someone making the switch from PHP to Python. Couple that with the fact that if a Techinical Director insists that candidates have commercial experience in a particular language as their current workload doesn't afford them the opportunity to wait for someone to come up to speed then I am going to insist on commercial experience in that particular language. A more appropriate analogy: Would you let a lawnmower mechanic rebuild the engine on your Ferrari?
4: ABC: Attitude, Bandwidth and Confidence: Typical, sales jargon. You can have the greatest attitude in the world, that doesn't imply that you are going to be a great programmer. In fact, I find the majority of highly skilled programmers are inherently introvert and humble.
I appreciate your intention is to provide an alternative perspective but the bottom line is this: I am very good at what I do. I have developed a significant reputation in the real world as well as here on HN as being a recruiter who takes a different approach to the business and my clients continue to come back to me as I consistently send them top quality candidates. I know what I'm doing & if I were to apply your advice I would be undoing a lot of the great work I have accomplished to date. My advice to you would be to stick to doing what you do best and leave me to continue doing what I do best.
In my career I've dealt with quite a few people like this, both as a hiring manager and as a candidate. As a hiring manager you get the opportunity to ask them some detailed questions about how they filter candidates, and I even asked one, once, to send me all of the resumes they got for the position, after she'd applied her filter. I went thru the entire stack of resumes myself, and filtered them by looking at them briefly, and then compared the ones I pulled out to hers. There was zero correlation. None of the ones I pulled out she did. All of the ones she pulled out -- and was busy giving me the hard sell on-- were ones I'd excluded. In fact my belief that the pickings couldn't be so slim was the reason I asked her to send me all of them, though I gave her some other excuse at the time. I also pulled twice as many candidates as she did, and was willing to spend up to an hour of my own time on the phone with them.
All of the people in your position think they know what they are doing and think they are good at being able to tell good candidates from bad ones. I understand why this might be, as this seems to be what they think is their job. "Anybody can exclude the janitors-- but I add value by being able to tell good programmers from bad ones!"
If you'd like to be a better recruiter, here's some changes to make:
1. Stop reviewing people's code. I've participated in many code reviews. I've often seen stuff that looked stupid, and asked the programmer about it, and then found out that they were expressing a level of understanding of the problem that was stronger than mine. Makes sense given that it wasn't my code I was reviewing, I was just reviewing, not writing it. That you think you can review someones contributions to open source in isolation is a big red flag. Just stop. Even if you're a great programmer, you can't do it fairly. In fact, if you were good enough to do it, you wouldn't want to do it because you'd know how easily it is to get wrong.
2. Just because someone doesn't list python on their resume, does not mean they wouldn't be a great python programmer. I've been using python off and on since the mid 1990s. I use it for utilities, tools and other support code, not for major projects, and it turns out (I just checked) I never actually put it on my resume. By your statements above I would have a "strong career but zero commercial or practical experience with python".
3. Just because someone has never programmed in python before, does not mean can't be the best candidate for the job. Programming is the talent. Python is a language. If you would say I'm unqualified to drive a ford because I've been driving toyotas, you'd be laughed at, wouldn't you? This is what you're doing. Every language has its strengths and weaknesses, sure. Unless you're hiring someone for a 3-5 week job, the quality of python code produced in the 6th week will have everything to do with the strength of the programmer, and nothing to do with the amount of python they've used in the past.
4. I once was interviewed by a recruiter and it became immediately obvious he was something special. I could tell he wasn't technical, so after he said he'd be setting up an interview with the hiring manager, I asked him how he'd come to the decision. He gave me a solution that you, and every non-technical person can apply, which is really quite brilliant: He said (paraphrasing) "I look for three things: ABC: Attitude, Bandwidth and Confidence. If they have a positive attitude, can explain things well to show they have a bright mind, and have some confidence, then I ask them a follow up question. I ask them to tell me about some technical thing they did that they're proud of. If my eyes glaze over, I know they are qualified to pass on." He didn't have to understand what the thing was, but he was uncanny in finding great candidates... in large part because his reputation caused them to seek him out. Maybe someone could bullshit him with a bunch of technical jargon that he didn't understand, that's fine, that's not his job. The idea of him judging my code is absurd, and would be to him too.
Please take this in the spirit it is intended, which is constructively.