"These companies don't notice that in this way, the good people a driven away, and only the desperate will apply."
This. One of the reasons I chose my last employer (SAP, or more specifically, SAP Research) was their no bullshit, yet very thorough, recruitment process.
Compare that with my <A very, very, well known software corp> experience, where the phone call interview with HR went like that:
HR drone: "So, what's your degree?"
Me: "Mathematics." [didn't you read my resume?]
HR: "Oh... well... Most of the people working here have CS degrees."
Me: "Ah, well, my last job title was 'Computer Science researcher' and before that I had several years of experience as a programmer, so I think I'll fit" [apparently not!]
HR: "Yes, but do you know algorithms?"
Me: bangs head on wall
Sorry, no matter how reputable your company is, if that's the recruitment process then I can do better.
I can absolutely guarantee you that the actual hiring manager briefed the HR department on the job spec and had to dumb it down significantly. The summary would have been something along the lines of 'Ideally the perfect candidate will have a CS degree from a major University as strong algorithmic knowledge is a fundamental requirement for the role.'
Ironically, it helps to think of the HR screening process as a really dumb algorithm. The HR staffer likely has little to no understanding of how to ferret out "knowledge of algorithms," (or any other job skill, for that matter). So he defaults to a list of keywords or phrases -- interpreted very literally -- from a job description received from the hiring manager.
His internal logic is pretty much driven by two directives:
1: If a keyword or phrase is in the job description, a successful applicant MUST have it on his resume. (Word for word, preferably).
2: Anything on a candidate's resume that is not on the job description is irrelevant.
In fairness, there is some legitimate value to the HR screening process. It is a filter. A dumb filter, but a filter that the hiring manager doesn't have time to run on X hundred (or Y thousand) resumes. Some HR filters are designed to screen out resumes that don't contain the right keywords. Others are designed to select for resumes that match all the right keywords. Either way, the effect is similar. Of course, such a process can (and does) weed out a lot of very talented, very qualified people.
The trick is learning how to game the filter. The filter penalizes creative or unusual word choices. The filter flags candidates who reference someone they've met or spoken to at the company (doubly so if that person is the actual referrer). The filter rewards fidelity to the letter of the job description. Tailor your cover letter and resume accordingly.
True. There's usually a correlation between annoying HR processes and annoying corporate cultures. But not always. Sometimes there's a really cool company that just happens to have a bad entry gate here and there. Usually this is the case at companies that have grown hot more quickly than they can scale up their initial HR systems.
To that point, oftentimes bad HR is really just a scale issue. A company starts getting more resumes than its people can deal with, and so it hires HR drones just to help with the workload. And this continues. Eventually, the managers are so far removed from the day-to-day HR filter that they don't really notice how bad it's become.
The point of departure is that HR attains life and influence of its own. What started as Payroll, having only a service role, morphs into an imperial organisation jamming its long beak into all corners. "It involves humans", goes the reasoning, "therefore we are in charge!"
I actually have a part in my resume that is intended for such filters (i.e. includes keywords like "OOP" and "Client-Server programming"). I call it "the HR blob".
Admittedly, it's not in the beginning...
I've actually gone so far as to have a mostly modular resume. There is no static document, per se, but a giant list of resume "modules" that can be picked and compiled into a coherent resume when the time comes.
Some modules are used pretty much all the time (name, address, education, previous jobs and titles). Others are swapped in or out (bullet points under each job, interests if applicable, etc.). I've found that customizing the resume to fit the job is worth the extra 30 minutes of hassle to compile it.
[Note that I do not advocate making shit up. Rather, I've found that sometimes even the same bullet point, phrased two different ways, can have positive or negative outcomes at two different job openings. Or sometimes Job X considers Accomplishment A very important, but Job Y considers A irrelevant. Etc.]
My university required my resume to be in HTML for applying through their system, so I used to have everything in one HTML file with irrelevant sections just hidden with CSS.
(I also exploited the ability to link external CSS to make a script that tracked everyone who viewed my resume, with a reverse DNS on their IP.)
This is a really good idea - like having a master license agreement (reads like a play book - think 50 pages of options and possible negotiation tracks for what starts as a 5 page agreement).
Of course, an army of lawyers put that together - is there an equivalent group to do that for technical resumes? A resume coach at the VFW wouldn't cut it...
I'm sure there is a cool, hacked-together way to automate the process. And that might actually be a great idea for an app or utility of some sort.
My system to date has been very paleolithic. I keep a spreadsheet with all my bullet points, categorized by job and mapped to different Skills and Experiences (i.e., the things to be demonstrated via the bullet points). When compiling a resume, I cross-reference by job description and its keywords, skills/experiences to be shown, etc.
Then I sort of treat the process like a compilation of overlapping sets, i.e., "The job requirements are A, B, and C. I want to show that I've done X, which demonstrates A and B. Then I want to show that I've done Y, which demonstrates B. But maybe Z demonstrates B and C in a more effective way, so I'll use X and Z as my bullets." There is definitely an easier and more automated way to do all this, perhaps with databases, but I still value the organic process of poring over everything myself and gut-checking if the overall narrative flow makes sense.
As you might imagine, I played too many RPGs as a kid.
'make' and a 'resume.d' directory tree with a vanilla and variant resumes works pretty well. Put the whole shebang under version control.
You can output various formats (HTML for web posting, PDF for distribution/printing, .DOC for recruiter's resume-uptake systems (many are based on MS Word / VBA macros). This is also handy for stripping your personal and/or contact information from resumes posted online (to keep annoying contacts down).
This sounds very clever and well engineered. And let me just say that I pray to all the gods I hold holy that I never be forced into a situation where I'd need to use such a thing.
Viewed from outside the box: this is a classic example of a clever hack to work around the wrong part of the problem.
This sounds like the way to go. Thanks. Especially because, as modular as I like to think my resume is, there really kind of is a vanilla/standard version from which all subsequent versions are really just mods. Might be less legwork than recompiling from basic modules each time.
Yea, you don't want to automate this. You need to keep your resume personal and truly tailored to the job. Unless you really work on natural language parsing the job description and the "about" pages of the company website, it's going to be a lot easier to do those little modifications yourself.
And as you said, you want to make sure the overall narrative flow as well as the overall design of the document makes sense for the job.
In my experience, there are perfectly good candidates that pass the filter with flying colours. Then there's the ok candidates with fluffed up resumes that also pass the filter with flying colours. Followed by the wanna-bes who have their friends fake references but fill their resumes with fluff.
Then there's people who've take a slightly different career path, or chosen a job at some unknown place, yet have lots of good experience, and they're ignored because HR doesn't know what to do with them...
"Then there's people who've take a slightly different career path, or chosen a job at some unknown place, yet have lots of good experience, and they're ignored because HR doesn't know what to do with them..."
I've been that guy on more than one occasion. I'm a self-taught hacker, and I made the mistake of majoring in English in undergrad. While I usually look great on paper at the hiring manager stage, I have pretty spotty luck with the HR filter. To make matters worse, I've graduated twice into very unfortunate circumstances: 1) I graduated from college into a recession (post-tech-bubble-burst); 2) I graduated from grad school into an extremely deep recession.
The necessity of my circumstances has forced me to get creative with my job searches. Hence, the "modular resume" strategy I outlined in a subsequent comment. And hence the general strategy I now take on all job searches. Conventional wisdom holds that a job search is a numbers game: get your name out there as broadly as possible, and eventually, you'll catch a few things in the net. In my case, knowing that I look iffy on paper to HR drones, I know I need higher-touch tactics. Casting a wide net won't get me many fish. I need rod and reel, so to speak.
So I'll hyper-prioritize, say, 10 openings. And then I'll really drill down on them: researching the best fit, reaching out to friends of friends, doing informational interviews, networking over a fairly long term, etc. My goal is to get the hiring manager to know me before my resume hits the HR filter. I'm dead in the water if I hit the HR filter blind. (My affinity for horrible, acquatically themed metaphors knows no limits).
In fairness, a lot of these tactics could be seen as good habits in general. But for me, they were born of necessity. So in some ways, I enjoy being an unconventional candidate. It forces me to experiment, to learn, and to adapt, and to persist.
I don't particularly think HR capable of evaluating or even understanding open source contributions. Unless, of course, the job description says, "must have contributed to open source."
Steve, how to recruiters themselves find their jobs? Do you guys find your respective jobs via the traditional resume-interview route?
I ask this because looking for word-for-word matches etc imply a lack of unfamiliarity with the process as viewed from the other side of the table. I understand that you have been a developer previously and probably understand the technical specifics better. But my guess is be that most of these recruiters might have gone the resume-interview route for at least _some_ job; I am surprised that they don't seem to understand how hopeless their techniques are.
Recruitment is one of the easiest jobs in the world to get into. Which probably explains the abundance of terrible recruiters. If you have any recruitment experience what so ever you will have employers literally lining up at your door with job offers. The last time I put my CV on the market I had 4 solid job offers within a week. I didn't apply for a single one, they all approached me.
I wonder the same about how SAP employees book time off... It can't be with their own software. E.g. I can't see the holiday calendar and how many days I have remaining on the same screen. I can't open them in different tabs because of the way it does session management, it will break horribly. You would think that they would get this bit right at least, just for their own sanity!
You're assuming an actual spec existed. When budgets are tight, the ability to hire someone occasionally comes out of nowhere with an insane deadline.
So instead of writing something up, the recruiter or manager googles around for "enterprise foobar developer", and copy/pastes a few pidgin english job descriptions from other places.
This arrives in HR, who then needs to translate slop into something that can be posted. Hence, the loop you described above.
Man, this makes me happy to hear. I'm CTO at a small startup, so hiring is crucial. We've worked really hard to optimize the recruiting process to make it easy on candidates, but it's been hard to know how much it matters.
To filter out the total idiots, I ask people to give me a one-paragraph answer to one of 5 technical-ish questions. That lets me spend plenty of time on the people that do make it through. I try to reply to all applications personally within 24 hours. Interviews take scheduling priority over pretty much anything else. We meet right after interviewing someone and try to get them an answer either way within a day.
If folks have other things they like (or hate) about hiring processes, I'd love to hear about it. We really want to get this right.
> I try to reply to all applications personally within 24 hours.
With that, you've addressed my biggest issue with the ordinary hiring process: Complete Lack of Feedback. When I was fresh (or nearly) out of college in 2003, the only responses I received were from the CMU Robotics Lab. And while they were "we're not interested" replies, they at least had a real signature on them. Nothing else I applied for produced even as much as an automated response - print, e-mail, phone, nothing. (My options and interests at the time were admitedly a bit too narrow, and geography worked harshly against me.)
Worse yet is when you interview somewhere and then never hear back. Thankfully that only happened once to me.
Otherwise it really depends on the group and the culture. It doesn't bother me when Megacorps use standardized tests or puzzles (large or popular groups need some sort of advanced filter), but I prefer the hiring process at smaller companies to be more personal.
>To filter out the total idiots, I ask people to give me a one-paragraph answer to one of 5 technical-ish questions.
from my recent job change (several offers). After supposedly reading my resume and after half an hour on the phone the company's staff recruiter asked me to write a paragraph on how i see my fit to the company. It became immediately obvious to me that there is no fit. Somehow that wasn't obvious for him. Next day he's calling and emailing - they really like to talk with me in-house and where is the paragraph? Couple days later - the same. Day after that - they really like to talk with me in-house. The paragraph somehow isn't mentioned anymore. Good luck guys. I hope you find the programmer(s) with a hobby for essay writing.
A paragraph isn't an essay. Even though essay writing isn't a crucial skill for programmers, clear and effective English writing often is, especially when you need to explain technical issues to non-technical people. Besides, good writing ability is often a pretty good indicator of general, well-rounded intelligence.
man, i'm not arguing about the importance of the essay writing skills (this is my weak one, and i know how important it is). My point is about when in the process you make candidates hopping through the hoops and the height and the number of the hoops. I don't have enough time to jump through all the hoops of all the employers that early in the process. It is like in marketing process - awareness, consideration, preference, action, loyalty - insisting and expecting action (buy) immediately at or instead of awareness.
Anyway, the process of filling a job vacancy is about mutual fit. Somebody, who'd like the process would obviously be a better fit to that company culture than me, so the filter does work.
Yeah, it sounds like they don't care about that, which is lame. And honestly, asking for a paragraph after you've talked with somebody seems weird.
In my case, it's basically a Turing test. I ask for it along with the resume link. It's just to weed out the obvious dolts. (Who, as somebody else mentioned, are unfortunately 90% of the applicants.) The questions I use are here: http://needfeed.com/about/jobs
I'm pretty sure that anybody would want to hire could toss off an answer to one of those in 5 minutes. Which, given that I'm going to spend 10 or 15 minutes reading their resume, their blog, and (hopefully) their open-source code, seems like a fair trade.
When I meet such corporate bureaucracy I'm always reminded of this paragraph from one of PG's essays[1]: "A group of 10 managers is not merely a group of 10 people working together in the usual way... for a group of 10 managers to work together as if they were simply a group of 10 individuals, the group working for each manager would have to work as if they were a single person—the workers and manager would each share only one person's worth of freedom between them... the result is that each person gets freedom of action in inverse proportion to the size of the entire [corporate] tree. Anyone who's worked for a large organization has felt this."
These companies don't notice that in this way, the good people a driven away, and only the desperate will apply.
It's a catch-22. Without this process, every man & his dog will apply for the job causing the company to have to filter through literally hundreds of applications in order to find appropriate candidates. Those that actually take the time to tolerate the process obviously consider themselves suitable and do really want the job.
As a Tech Recruiter, I'm generally the front line for job applications and I'll give you stats from my most recent role:
Python Dev- London - Circa £45k
Applications: 48
* 36 highly irrelevant and inappropriate candidates that were blatantly just clicking 'apply' on every job they found.
* 6 applications with no CV attached.
* 6 potentially relevant candidates.
* Out of the 6 potentials that I spoke to over the phone and face to face, only 2 were worth submitting directly to the client.
These stats are pretty much the norm for most of the roles I advertise.
Without this process, every man & his dog will apply for the job causing the company to have to filter through literally hundreds of applications in order to find appropriate candidates
Shouldn't that be the point of tech recruitment agents, though? It used to drive me mad when recruitment agents would phone up, ask for 25%, then email me two "top" CVs which bore zero relevance to the jobs previously advertised.
Out of the 6 potentials that I spoke to over the phone and face to face, only 2 were worth submitting directly to the client.
You sounds like the exception that proves the rule ;)
Shouldn't that be the point of tech recruitment agents, though?
Absolutely. You engage us to be your personal filter. We shield you from the deluge and provide you access to the handful of suitable candidates. I'm not surprised your recruiters are sending you irrelevant candidates. It's something I ranted about at length in my most recent blog post, link in my profile.
You sounds like the exception that proves the rule ;)
Most recruiters do exactly the same, the difference is the recruiters who actually understand the requirement, your needs & the technology involved will send you some decent CV's from the steaming pile of rubbish they receive, the 'salesman' recruiters will send you two CV's that appear to be relevant or are a high keyword match against the job spec and don't have a fundamental grasp of your needs.
IMHO one thing the client needs to do to get a decent Python programmer apply is either relocate that job somewhere cheaper, or pay significantly more. In London, too much of that £45k is going to be swallowed up by accommodation costs.
For better or worse, there are fairly low barriers to entry for Python devs, e.g. doing Django. Same with Ruby and RoR. The higher the barriers to entry, the higher the salary.
If you're looking for the coding jobs, ask them if:
- they have a github profile
- they have a stackoverflow profile
- they have a linkedin profile
(the latter will go for a CV - I actually used it when one $reasonably_big_and_known_company called me up wanting to hire me and wanted me to write a CV - I told them to use my linkedin profile, and it worked all right).
Arguably this is not a 1:1 relation - since there might be a lot of good programmers that do not bother to communicate much externally.
But if they have the presence, then you will be well able to judge their quality without having to ask them a single question. (I silently assume you can read code/judge programming questions - if not, then my blurb is of not much use indeed)
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.
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.
> 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.
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.
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.
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.
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.
But those statistics by themselves do nothing to counter one of the key points. How do you actually know they were irrelevant? How do you know the 4 potentials weren't worth submitting?
Your commenting history suggests you might have a clue what you're doing, but this comment taken by itself could easily be from a recruiter that's part of the problem and doesn't know it. Lord knows I've never (in the US) personally encountered a recruiter that really understood the position they were trying to fill.
How do you actually know they were irrelevant? How do you know the 4 potentials weren't worth submitting?
I'm a former developer. I'm currently teaching myself Python. I listen and understand my clients needs. I'm not afraid to ask a client or candidate to elaborate on a point I don't understand. Essentially I don't think that it's necessary for a recruiter to claim to know everything about every technology as I believe from experience that a lot of employers find honesty refreshing.
For some reason this story reminds me of one of the Arabian Nights stories, which, in the translation I read, began:
"Know, my friends, when I was no more than eight years old, I had already cultivated the remarkable habit of telling one really big lie per year".
I wonder if these hobbies could be combined? Indulging in these kind of pranks seems almost justifiable given the "can they really be serious" shenanigans perpetrated upon those of our trade by the interviewers and recruiters.
I am polishing my resume, with special emphasis on my glory days at the Austrian Naval Academy.
I'm really happy where I'm contracting at the moment, but like to apply for challenging-looking roles. Two big benefits here:
a) If somewhere offers you a lot money, you can take that back to your current employer. I've had a 30% payrise from that before on my day rate.
b) Slightly bigger companies with big pockets are often hiring 'unofficially'. That means if they know you and like you, they're often willing to employ you. If you've applied for a job, but turned it down while being very very positive about the company, you've got a set of contacts there to email when you current contract doesn't get renewed...
Interesting observations. As someone who has been in hiring positions over several years, the signal to noise ratio in recruiting consistently goes down. On-line recruiting used to be the domain of the talented. Now that everyone is on-line, the professional job-searchers have more time on their hands.
Let's say the unqualified outnumber the qualified by 5 to 1. They're also job-searching on company time, so they send out 5 times as many resumes as the qualified. Their resumes then outnumber the qualified by 25 to 1. This gives you the ratios that Peroni sees.
What's hard - very hard - is that good engineers aren't great at writing job descriptions that are useful to HR recruiters. Conversely, many good HR recruiters still don't understand technical job descriptions.
In the end, this is why the best recruiting method still seems to be, "Ask your best person who their most capable friend is."
I actually look for jobs with a thorough interview process, and having to spend a few hours solving a puzzle, on my own time, before an in-person interview, is a plus. It means the other people I'll be working with have been through the same thing, and there'll be a higher percentage of good programmers among them.
I get what you're saying, but I really don't think it's fair to ask people to do work on their own time -- for free -- in order to be considered for a job.
Most recently I asked a candidate to work a few hours on a real project for a fair hourly rate. I think this is much better for all involved. As a bonus, you get to see how they perform on a real project, rather than a contrived puzzle and they get to see what sort of work they might be doing if hired.
This is something we've struggled with. The final phase of our interviewing process is a few hours of pair programming. If folks worked on production code, we wanted to pay them.
Paying people for a few hours of work is difficult: if we pay them as an employee then we have to do employee paperwork and deal with the payroll company. If we pay them as a contractor then they have to sign a lot of contractor paperwork, including a confidentiality and intellectual property assignment agreement. It's the kind of thing I wouldn't sign without my lawyer's advice. It just seems like too much trouble.
Instead, we'll either work on a throwaway toy project or an open-source project. Both of those are working well so far, and people seem happy to actually ship some open-source code at the end of the interview.
"I get what you're saying, but I really don't think it's fair to ask people to do work on their own time -- for free -- in order to be considered for a job."
Bravo.
I can't stand when companies do this. Whether it's design or development, it's basically spec work. It's one thing if it's a general question, but if they ask you to do work related to their service, why not just pay them for a few hours or a few days?
I honestly don't know what the masses expect companies that hire programmers to do. We're told that we're not as good of a company if programmers don't program in the interview. But then the next thing we're told is that nobody programs on a whiteboard and/or with someone watching. To help, we come up with take home exercises that are custom to us so we know the answers are real. Now this article and the parent are saying we're wasting time with these "puzzles".
When I hire, I do a phone screen before asking the candidates to complete the code exercise. If it isn't going to be a fit from either of our perspectives, then they didn't spend time doing it.
It would be nice if companies simply asked for a code sample, and then asked the programmer to explain what it does, their reasoning for doing so, etc.
I have a major open source project under my belt, but I've never had an interviewer simply ask me about my code. Instead, they ask me to sort an array.
As an interviewer, I didn't see the value in asking candidates to complete FizzBuzz until one of them was unable to do it. Since then, I've had a half dozen or so candidates make it through the resume and phone screen process and still not be able to complete FizzBuzz.
In regards to discussing existing code, I'd be more than happy to do so, but my experience has been that about one person per stack of resumes has quality existing code available to share.
Well, my experience was that I wasn't interviewed at all, instead I was just asked to code up this blog system, even after demonstrating extensive knowledge of the area in my CV. The way you're doing it sounds better, but it also depends on the coding exercise. If it's an interesting problem, I'm much more inclined to work on it, rather than a simple model when I've already told you I launched dozens of projects using the technology you're using.
I think the key is that there are crappy puzzles (and coding a blog system is not a "puzzle") and there are decent puzzles. I've been giving applicants a simple word search puzzle for over five years and it has been great at differentiating candidates.
The biggest plus for me as the hiring manager is that it allows me to be much more confident in taking flyers on people without that picture perfect resume.
I can certainly understand that. I've definitely taken care to make sure that all of our examples couldn't be construed as free work. Code katas, like the bowling kata, are good for this.
I've never been asked to solve a puzzle by an HR department, but I have always been asked to solve a puzzle. Have you been asked to solve puzzles that were written by HR, and how could you tell?
I meant it in the broader sense of "the people who are interviewing me". I have been asked to program a simple blog system with various features, which seemed like a rather bad use of my time.
That same system was implemented on the company's website later on, which didn't make me feel any better. To top it all off, they never even replied.
I talk to them, ask them to show me some code samples they've written or projects they've developed in their spare time. If someone tells me they've written and launched an entire product with thousands of users by themselves, it's a bit counterproductive for me to ask them to code up a blog.
How would that work for someone who has a job where their code is proprietary and, in their spare time, they like gardening? Or do you just automatically exclude folks who don't develop their own sites with 1000s of users?
Ugh, why does everyone miss the point? If they can't show me any code, I'll talk to them and see if they know what they're talking about. I've found that you can tell whether or not someone is technically competent from a five-minute chat.
A) How many of those people who run their own products with thousands of users come looking for a job with you? (or, perhaps, 'ran' in the past tense)
B) How do you know they programmed that app with thousands of users even remotely well? Did they store passwords in plaintext? Does it need to be reboot every 5 mins? Is it slow as molasses, but hidden behind load balancing?
Someone could have written awesome sites with 1000s of users and loads of revenue, but it might still have been done like crap, and doesn't belong anywhere on your network.
A) I was illustrating a point, but I will clarify it as it didn't come across: If someone demonstrates extraordinary ability in projects before the interview, I will not ask them to spend four hours demonstrating rudimentary ability.
Oh no, I was mostly commenting on my past experience. If someone shows past achievements, I'm going to adjust the interview to their level, rather than ask them rudimentary questions or ask them to implement rudimentary and time-consuming functionality.
You can get a feel for whether the candidate can program a simple blog by asking them how they'd do it, you don't have to ask them to spend hours actually doing the nitty-gritty...
"Time I'm willing to dedicate to your interview problems" and "time I'm willing to dedicate to reading and writing on HN" are not freely interchangeable; you can (and presumably do) have radically different expectations of the costs and benefits that make them incomparable.
There are no positions which are good enough to complete such a form.
Like a poster mentioned elsewhere: the interview process is also a strong indicator of the internal atmosphere, too. I don't want to work for any company which believes such a form is a good idea.
Some part of me wants to believe that it is a weed out on the other side - 'if you value your time so low as to fill out these forms, we know we can pay you jackshit and get away with it'.
I have the same hobby, i'm a php contractor but sometimes go to job interviews for permanent positions even though its extremely unlikely i'll ever accept a permanent position, but i do it for the experience of interviewing and to become aware of the companies in my area. Also, its always nice to get an offer of a job sometimes.
Funny, as a company we sometimes invite contractors to interview for much the same reasons. It's good to know the freelancers that are around, and especially if they'll be able to fit into our existing teams, even though we rarely make use of that option. And it helps with long-term recruiting, since contractors regularly give up being self-employed for a variety of reasons.
I used to do this back in the late 90s! I was also self employed and happy with it, but the added ingredient was overenthusiastic recruitment agencies who wanted me to go. I had one particularly eager guy who wouldn't leave me alone and got me to take an interview at the BBC for Director of Online Media or some similar high flying title (the role was not as significant then as it is now).. I was wildly inexperienced and only 18 but I ended up spending a few hours in BBC Television Centre and it was quite the day out ;-) The recruiter never contacted me again after that.
While I think it's great to stay in the rhythm of things and really get your interview skills down pat, to me the idea of applying for a job when you don't need one is a bit arrogant and selfish. In the grand scheme of things you took a potential interview and maybe a job away from someone else who might have really needed it. It's great that people want to help themselves but doing the right thing and being nice can go a long way--if you really want to brush up on your interviewing or just not lose touch of the corporate game there are a lot of career centers out there just itching to give you tips and encouragement. I'm not taking away from your message about companies and their hiring practices in general but don't forget about what really matters.
I'm pretty sure that the commenter was being facetious, but I have worked at a company where they actually did this. They always had job openings posted on their website, and they would bring people in for interviews, even though they weren't hiring and had no positions to place those individuals in. I remember the CEO said "that way we'll have a pool of candidates to pull from if we decide to hire someone".
Needless to say, I never referred any of my friends.
Going through the motions of applying for jobs also helped me keep my resume up to date and polished. Now that I've been in the same place for a few years I've let that slide - time to get back in the habit maybe?
If he didn't apply for any jobs he would be mostly completely out of the loop as far as the world of working for someone else goes. If he had or wanted to get a job at some point, the knowledge of current practices would help a lot compared to never having interviewed in years.
It seems to be some bizarre tradition in this country (US) to kick applicants in the nuts every time they apply, call or inquire about a employment position at a company.
My theory is that if every company does this, then the current body of employees will work harder to stay out of that prison of unemployment, where everyone kicks you when you are down. I am in support of all the good programmers everywhere applying to jobs without intending to take them, and generally treating the system that hires you like crap. So next time you are unemployed and you are treated badly, you'll at least know why they are doing so.
This. One of the reasons I chose my last employer (SAP, or more specifically, SAP Research) was their no bullshit, yet very thorough, recruitment process.
Compare that with my <A very, very, well known software corp> experience, where the phone call interview with HR went like that:
HR drone: "So, what's your degree?"
Me: "Mathematics." [didn't you read my resume?]
HR: "Oh... well... Most of the people working here have CS degrees."
Me: "Ah, well, my last job title was 'Computer Science researcher' and before that I had several years of experience as a programmer, so I think I'll fit" [apparently not!]
HR: "Yes, but do you know algorithms?"
Me: bangs head on wall
Sorry, no matter how reputable your company is, if that's the recruitment process then I can do better.