Hacker News new | past | comments | ask | show | jobs | submit login

Please tell me about the "highly irrelevant and inappropriate candidates" you were seeing.

Were you seeing people whose previous job experience was: Receptionist, Typist, Journalist, Janitor, Taxi Driver, etc?

Or were you seeing web developers who never mentioned python on their resume?

The reason I ask is, the majority of the times I've been screened by recruiters, they clearly were unable to tell what was relevant and what was not. EG: Thinking you're not qualified because you worked with a different version of a database the employer uses, even though SQL hasn't changed between versions and you probably usually shouldn't be writing SQL anyway in your code.

The inability to screen properly gave me the distinct impressions that those who were filtering me out were incompetent because they were being arbitrary, and those who weren't filtering me out just had low standards (they didn't ask better questions.) In the end, I was the one who filtered me out of inappropriate jobs because I could tell by their descriptions (if they let me see the job description rather than rambling on about how they need a "ninja coder to take their B2B accounting software to the next level").

Do you use any software to screen the applications for appropriateness? I know that keywords likely would only work to get rid of the 36 (or would they? Did they all say "python" on their resume?) Would machine learning or bayesian techniques possibly work better?




I don't use any artificial means of filtering candidates. If I receive 48 applications, I read 48 CV's.

There were a large number of graduates with zero commercial experience and zero open source contributions as well as a number of foreign candidates with completely unrelated careers simply looking for a job in London. There were also a number of underqualified candidates and people with strong careers but zero commercial or practical experience with Python.


One of my cow-orkers recently told us a story from his last job working for (a large company you have all heard of). They were outsourcing stuff to India and had gotten 12 Indian engineers to come to England for 4 weeks training. Of the 12 that got on the plane, 10 showed up at their office - the others simply got off the plane and having gotten a free flight to England, disappeared. Of the 10 that got on the plane back, 8 reported to the office there - the other 2 went to other companies with $large_company on their CVs. Within 3 months, none of the original 12 were left.

The outsourcing went ahead anyway.


I heard similar stories at a US financial company; lads would work for 6 months, get trained and up to speed, then they would either get head-hunted or look for a better paying job and leave. New people would have to be hired and then be trained and then leave etc

The US based staff would get grief if the projects weren't completed on time or had issues.

I don't blame the Indian lads, they were getting paid crap. Also, many of them weren't great, as the pay was crap and good programmers in India wouldn't work for the company.


That's the thing, in outsourcing you tend to get the people who could only get hired at a bodyshop.


> There were also a number of underqualified candidates and people with strong careers but zero commercial or practical experience with Python.

This kind of ignorance is why you should never use a "Tech Recruiter" to hire your technical candidates --- even the ones savvy enough to post on Hacker News seem to value programming-language knowledge you can pick up in two weeks over "strong careers".


A strong career is wonderful but when a client insists on commercial experience with a particular language, I'm not going to hand them confident C# Devs for their Python role.

If you sincerely believe that after two weeks, even two months, you would be as strong a Python Dev as someone who has been applying their Python knowledge in various commercial projects consistently for the last four years then you may need a significant dose of humility.


Well, I've been using Python for ten years, so I'm not the best example there. But, yeah, I'd be a better C# programmer than the vast majority of C# programmers with four years of experience, within two weeks. Of course my lack of knowledge of C# would get in my way all the time and slow me down, and I wouldn't be nearly as good as I would be after a few years of experience.

So why do I think I'd be a better C# programmer than most C# programmers in only two weeks? Because I'm a better programmer than most of them, and that's a more significant factor than language and library knowledge. A mediocre programmer can be mediocre in any language, and many of them continue to be mediocre for many years. Also, when you join an existing team with experience in a language, you can draw on their expertise.

There are a lot of programmers who are better than I am, thousands if not tens of thousands of them. I've had the privilege of collaborating with some of them. If someone had to choose between me and someone else at about my level, they'd be entirely justified in making the decision based on language knowledge. But the vast majority of experienced programmers are worse than I am --- much worse.


"and people with strong careers but zero commercial or practical experience with Python"

You probably missed out on some decent candidates with that as knowing how to program is often not limited to a specific language. Programming is more a way of thinking and approaching problems than knowing a specific syntax.

When filling a role for a C#/ASP.NET web developer the person we chose to hire had ZERO C#/ASP.NET experience, but had many years of Java experience making the same type of applications we needed. He got up to speed extremely quickly and was a great contributor to the team.


Well, for a good programmer it is trivial to learn Python, and especially Python, in a very (!) short time.


Learning a new syntax is not the same as actually learning the idioms (pythonic?) that are considered good practice. And after that you'll get into the field of infrastructure around that language. I guess if you've never heard of Python and the company is looking for a decent programmer to help in a (making something up as I type) medium sized Django application then you end up with

- you don't know Python at all

- if you learn it (might be very fast to learn to read it, fast to get into the basics) you're still missing out a lot (Maybe they use IronPython. Or Pypy. You need to learn the eco system: virtualenv et al?)

- even if you mastered that, you still don't know the basic technology they are using (in my sample: Django)

Compare that to a guy that used Python for a couple years. That one only needs to get into your code base and can start working right away.


darklajid,

of course you are right: someone who knows Python well may be better than someone who doesn't.

But if you look at the recruiters experience, who finds only two qualified applications, then I say: find a good programmer among the applicants who really wants to get into Python and you will get someone who comes to speed very quickly.

You might even find someone who is enthusiastic about his new job, instead of someone who does the same thing since 1996, who is good at what he does, but a bit bored too.

These recruiters always think in their own minds cage: according to them, you start something once, and do it for the rest of your life, because nobody will let you do something different. Most software developers are much too smart for that cage only.


Some software developers are much too smart for that cage only.

A large percentage of the population here falls in that category, but we aren't representative of the industry as a whole. What do you think a Blub programmer actually is?


I'll take the better programmer over the one who knows python already, any day and every time.

I think once you've learned enough languages, they become like lenses on a camera. You're as good a photographer as you are, whether you use one lens or a different lens.

The lens doesn't make a bad photographer good, and a good photographer will be just as good using a lens they've never used before, given a short period of time to familiarize themselves with it.

The environment of a particular job you always have to learn, even if you've used the exact tools at a previous job.

After a year, it is the strength of the photographer or programmer that is going to determine how much and how good their work is, not whether they knew the tool before they took the job.


"I think once you've learned enough languages, they become like lenses on a camera."

Very good reply and also a very good metaphor.


While that may be true, having a practical understanding of Python is very different from your knowledge of Python after several years of development. Every programming language is full of its own caveats and trusty passages, and experience is what teaches you how to avoid them.


I am always reminded of a very talented consultant friend whose client had a strong relationship with him. They had a short term (6mo) project and felt it was safer to pay him over 100$ an hour to learn the language than try to find someone off the street with ideal background. Turns out he finished two weeks early.


You raise an interesting point. Would an applicant with "zero" commercial experience (which i take as "not being previously employed in a similar role") but open source projects in Python under his belt qualify as suitable for this role?


Potentially. To be fair, the quality of their code plays a big factor. The problem with someone who has no open source commits means I have no way of judging their code. It's not just the code either. If you've built something cool & interesting in your own time then you instantly move up in the ranks of suitability.


Does a clean-room implementation of java.util.Map interface qualify as interesting? I ask this because someone might be perfectly capable of writing quality code, but might not be thinking up an idea that comes off as cool or interesting or original to you.


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.


Ironically, it is only because I thought you might be different that I went through the trouble of explaining why and how there was a better way.


In regard to #4, this works for very technical people to -- this is an interview strategy that is used by Ken Thompson! See Coders at Work.


I get what you're saying about recruiters and hiring managers having too narrow a view of what they really need in a candidate.

But let me tell you first hand (I'm trying to hire a PHP developer now), you get lots of truly and objectively bad candidates. People who want to telecommute even though the job clearly says you must be on-site. Or people who submit a resume that does not demonstrate the required skills and do not include a cover letter.

I've found that some University job boards make it way too easy for a student to check off a whole bunch of jobs (or perhaps all the jobs) and apply to them en masse.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: