What If Cars Were Rented Like We Hire Programmers?(highscalability.com) |
What If Cars Were Rented Like We Hire Programmers?(highscalability.com) |
I will however say that 90% of the interview questions I have been asked are heavily biased towards C type answers, although I did manage to use Scheme once!
Sure a linked list problems don't technically have to be written with pointers, but we all know what the interviewer is asking for.
Actually that brings up a good idea, I am going to come up with a bunch of contrived answers to the "find a loop in a linked list" problem, memorize them all, and next time someone asks me that question I'm going to give 5 weird answers in the course of 30 minutes.
It's true, if you have a solid foundation software, you can catch up to the 2012 platform. It will take some time.
So I think it is less that software changed so fast that solid programmers are unable to catch up so much that software changed so fast that recruiters have been unable to keep up.
"Are you sure I'm qualified? I don't feel like I'd be very useful. I've never done Java, only C++ and JS and lisp" "No, you'll be perfect. We don't hire people for specific languages"
Of course, my experience is with Python, and trying to get hired by a Ruby shop (no matter my experience outside of work with Ruby or any other language, or my experience with the rest of the stack) is impossible.
Perhaps it's a different world the lower down the language abstraction level you look.
Regarding your Ruby-outside-work experience, is it on publicly visible projects?
The underling problem is very true though.
1) While renting a car you are paying. 2) Interviews are for getting PAID.
It is buying versus selling.
The buyer will be cautious, try to get the best deal. The seller will be sweet, nice and somehow sell it.
So, we should ignore this post.
I argue recruiters should act MORE like car salesmen =)
I've both participated in and executed hiring processes in a mid-size (~500 emps) corporation where just about everyone wears ties or biz-casual (gross).
I sat in on one department's hiring rounds with about six candidates. What the dept was looking for was a programmer who had MS/.NET experience to develop on the MediaRoom platform (I managed the internal development team, hence my sitting in; responsibility for operating MediaRoom was under the other dept, however, so this candidate was not going to be able to be part of my team (stupid corporate organizational bullshit where dept mgrs squabble and scramble for stupid feelings of control and shit)). The questions the dept came up with and spent 1-2 hrs torturing the candidates with included zero questions about programming experience and aptitude-gauging type of inquiries. No questions about past projects, current interests, or anything remotely helpful. All the questions that were technical revolved around sysadmin tasks or how many damn acronyms the candidate was familiar with from MS's alphabet soup of platforms & products--literally asking if the candidate knew what they meant, not if they understood purpose or anything else like that. For a fucking programming job. The position stayed open for a year-and-a-half without being filled.
Biggest problem I saw? The interview was designed by a guy with zero programming experience trying to hire a programmer. Why the questions he chose? Best I can tell, servers and sysadmin tasks were something his dept had long done, and something he semi-understood (but didn't do himself).
In contrast, when I ran hiring for my dept, I requested explicit permission to direct the interviews myself, instead of having them led by HR (though an HR rep was still there). Before setting up an interview, my team and I would meet the candidate for lunch just to get to know them a bit. It was sort of our version of testing- or phone-based screening processes. We could figure out more in an hour lunch that we could trust than automated tests or other devices.
After the first candidate's official interview, I heard HR was talking about it. By the second candidate's interview two days later, the SVP of HR sat in on the process with the other HR person who was always there. What was most interesting to HR, apparently, was that candidates didn't display any of the typical nervous behaviors that are so common. About 10 minutes in, we had them relaxed, talking and smiling and laughing like normal, discussing things they did in their free time to take a break from programming, talking about the projects they'd loved and hated the most--even talking about times they'd fucked up. That last bit was really fun to watch HR react to, as they hadn't ever experienced anyone talking about times they'd done something wrong in an interview.
There were no bullshit how-would-you-resolve-a-stupid-conflict-with-a-coworker questions. We asked some general tech and programming questions, shot the shit about open source projects that impressed the candidate. The focus, though, was on collaborative tasks where the entire dev team went through a couple exercises with the candidate as if s/he was part of the team already, letting the candidate lead, but basically serving as a normal team would--asking questions, raising objections, saying what a good idea or novel approach something was. It was a great way to get a feel for what it'd be like to work through a problem together.
By the time we'd interviewed 4 people, we'd already hired 2 of them and I had to push pretty hard to get a very competitive offer out immediately before finishing all the rounds. I nagged the hell out of them till they were willing to break their own rules of waiting till all interviews were done. Our positions did not stay open even one month before we hired three new people. But making them successful required a lot of effort on my part to plead and nag and bargain to get processes bent so we could pull it off.
Hiring feels broken in many businesses. But it doesn't have to be.
Disclaimer: This was a mid-size company. I'm not saying that companies who receive hundreds or thousands of applicants can afford to take the time to do things this way. I can say that every interview that has ever meant a damn to me were the ones where the people interviewing actually took the time to be relaxed, get to know me a bit, and just make interviewing more like having a conversation. It's not coincidence that each one of those happened to be over coffee or lunch or somewhere away from a conference room and table as the first meeting.
Some say that his not only the man-in-the-middle, he's at both ends and has wiretaps on Alice, Bob, Carol and Dave. and that he once crashed a 10 way IBM sysplex by staring at at it all we know is hes the stigs nerdy cousin.
Like - can you land Curiosity with off the shelf java and JVM? Why or why not?
I was actually wondering if this was written by a programmer or a man that hires programmers at first...
In this case, the person renting the car would be "interviewing" the car rental company to determine if their service is worth their money.
It goes both ways... the rental car agency interviews the person to make sure she is trustworthy of driving the car. The author is asking you to think about the relationship a little more abstractly than simply who is giving money to whom.
Having said, that, I think this is a poor analogy because I don't find it particularly illuminating and the situations just don't seem very... analogous.
Instead of "whoever is giving up money should do the due diligence," I would suggest you consider "both sides should do increasing due diligence as the importance of a decision increases."
From this perspective, the article is pointing out the dumbness of some due diligence methods currently being used at software companies.
To walk into a job interview with the same expectation of being "served" is ridiculous. It's true that if they're smart, they will try to entice you and provide a nice experience, but primarily they are trying to decide whether to spend large amounts of time and money on you versus someone else. Most companies are not in the business of quickly and efficiently hiring as many people off the street as possible. You can be flustered by an interviewer's poor technique, but don't be impatient to receive the job offer you feel entitled to.
Interviewer#3: How long you been driving your 2010 Escort?
Applicant: About 3 years.
Interviewer#3: Sorry, but we are looking for someone with
experience of driving 2010 Escort for at
least 10 years.To add:
Interviewer#3: We are looking for someone who knows how
operate the navigation screen on the 2010 Escort.
Applicant: My car does not have the navigation option
installed.
Interviewer: Then you do not qualify. Knowing how to
work the navigation system is a priority.
Applicant: I know how to work navigation systems in
general. My car before this one had a navigation system
and I learned it pretty quickly.
Interviewer#3: No. We need people with 10 years of
experience with the actual navigation system on the 2010
Escort.
Completely off-topic response to your note, but I loved my 2000 Focus and I was almost sad to sell it. It went through air intake hoses on the transmission about as fast as it did gasoline (hyperbole, but the Arizona heat was hell on that little rubber elbow. Fixing it took 5 minutes and cost $3 once a year, though, so as far as chronic car problems went it was pretty mild). It was still running strong after 12 years, and got my wife from Tucson to Seattle as safe as could be :3
First Android phones were release at 2008.
In other news - I thank god I never were in as bad as interviews as some of you. My worst experience was the interviewer giving up and starting to ask me personal and professional stuff about another candidate to the same position. I guess I did a good job because the other candidate got it, company shutdown withing a year.
If I sense during an interview that things aren't going to be a good fit, I still try and finish the interview graciously. There is no use burning any bridge, even if it's one you're 100% certain you'll never use. One trick I do to keep myself from seeming aloof or displeased is to start asking questions about the industry. At this point, I know I don't want the job and probably don't care about the culture, but learning something about an industry you may not know much about could be useful down the line.
Agency : How much did you pay for your last rental car?
Applicant : I don't see how that matters. What are you charging?
Agency : We like to know what you paid before so you get a fair rate.
Applicant : I paid market rates.
Agency : Sorry, we must know how much...
For future interviews, I've collected similar questions to ask of them (questions that I have conveniently worked out or looked up the answer to beforehand), my rationale being, "I want to make sure I would be working with competent peers." And I don't give a fuck if it rubs them the wrong way.
During my interviews, I was very charismatic, confident in my skills, was asked technical question that were things I would need day in day out. I landed the job on 100% of those interviews.
There was this one time were the guy kept asking me crap I would never EVER need while working for his company.
Binary tree's, linked lists, pointer arithmatic. "What the fuck?", I thought to myself. This was for a C# developer position for a small 20 person company. Anyways, I thanked him for his time and left. He called me with an offer two weeks later, and I declined. Not going to waste my time with that crap.
---
99% of us will never work for Google, or Amazon, or Twitter - but for your run of the mill software shops. And that's ok.
Our job is to stop you getting hired.
If we get 100 people applying for the job, then our job is to not employ at least 99. So we are looking for anything that identifies you as being one of the 99.
That you could go away and learn what color the middle wire is is great. But the guy next to you has been fixing wiring in distributor caps for years. And right now, I need people that know what color the middle wire is.
Just like having a drivers license is no guarantee you are a good driver, having many years of job experience programming is no guarantee you are a programmer.
On the other hand, you are liable for any damage you do to a car you rent, plus the company is fully insured in the case you do any damage and can't pay. Hiring and firing someone (which is the only real way to know if someone is a good developer) is very expensive.
Here's what it would be like if we hired programmers like we rent cars:
You walk in to a software company and are immediately hired under these conditions: "We'll take you on for 6 months, but if it doesn't work out you need to pay us back all of your salary, plus benefits and payroll tax"
He's not saying "don't find a good programmer." He's saying that the questions they ask get them no closer to finding out whether he is a good programmer.
A lot of the time they're not meant to. They're meant to figure out whether he's a bad programmer (or bad cultural fit, or something else bad).
The cost of hiring someone bad is way higher than most people would guess. I've come to believe that in many cases the questions asked in an interview almost don't matter - they're just there to give you an opportunity to fail, or to say something incredibly dumb or ignorant or obnoxious so that the interviewer can quickly reject you and avoid an expensive mistake.
To cherry pick one example: "What color has the middle wire feeding into the distributer cap?" implies interviewers ask ridiculously specific questions that you could "look up if and when you needed to know."
The problem is for some applicants that question could be "how would you implement Google's PageRank" and for other applicants it can be something as simple as "what's the difference between an interface and an abstract class." Think what you want but if you don't think you need to be able to answer the latter, it's probably not going to work out between us.
To be honest, of the few interviews where I've been the applicant, the questions have always been fair and I've never been treated with the level of disrespect that was demonstrated in this scenario. That said, I'm completely willing to believe I've just been lucky so far.
http://mavweb.mnsu.edu/howard/Schmidt%20and%20Hunter%201998%...
sums up, current to 1998, a meta-analysis of much of the HUGE peer-reviewed professional literature on the industrial and organizational psychology devoted to business hiring procedures. There are many kinds of hiring criteria, such as in-person interviews, telephone interviews, resume reviews for job experience, checks for academic credentials, personality tests, and so on. There is much published study research on how job applicants perform after they are hired in a wide variety of occupations.
http://www.siop.org/workplace/employment%20testing/testtypes...
EXECUTIVE SUMMARY: If you are hiring for any kind of job in the United States, prefer a work-sample test as your hiring procedure. If you are hiring in most other parts of the world, use a work-sample test in combination with a general mental ability test.
The overall summary of the industrial psychology research in reliable secondary sources is that two kinds of job screening procedures work reasonably well. One is a general mental ability (GMA) test (an IQ-like test, such as the Wonderlic personnel screening test). Another is a work-sample test, where the applicant does an actual task or group of tasks like what the applicant will do on the job if hired. (But the calculated validity of each of the two best kinds of procedures, standing alone, is only 0.54 for work sample tests and 0.51 for general mental ability tests.) Each of these kinds of tests has about the same validity in screening applicants for jobs, with the general mental ability test better predicting success for applicants who will be trained into a new job. Neither is perfect (both miss some good performers on the job, and select some bad performers on the job), but both are better than any other single-factor hiring procedure that has been tested in rigorous research, across a wide variety of occupations. So if you are hiring for your company, it's a good idea to think about how to build a work-sample test into all of your hiring processes.
Because of a Supreme Court decision in the United States (the decision does not apply in other countries, which have different statutes about employment), it is legally risky to give job applicants general mental ability tests such as a straight-up IQ test (as was commonplace in my parents' generation) as a routine part of hiring procedures. The Griggs v. Duke Power, 401 U.S. 424 (1971) case
http://scholar.google.com/scholar_case?case=8655598674229196...
interpreted a federal statute about employment discrimination and held that a general intelligence test used in hiring that could have a "disparate impact" on applicants of some protected classes must "bear a demonstrable relationship to successful performance of the jobs for which it was used." In other words, a company that wants to use a test like the Wonderlic, or like the SAT, or like the current WAIS or Stanford-Binet IQ tests, in a hiring procedure had best conduct a specific validation study of the test related to performance on the job in question. Some companies do the validation study, and use IQ-like tests in hiring. Other companies use IQ-like tests in hiring and hope that no one sues (which is not what I would advise any company). Note that a brain-teaser-type test used in a hiring procedure could be challenged as illegal if it can be shown to have disparate impact on some job applicants. A company defending a brain-teaser test for hiring would have to defend it by showing it is supported by a validation study demonstrating that the test is related to successful performance on the job. Such validation studies can be quite expensive. (Companies outside the United States are regulated by different laws. One other big difference between the United States and other countries is the relative ease with which workers may be fired in the United States, allowing companies to correct hiring mistakes by terminating the employment of the workers they hired mistakenly. The more legal protections a worker has from being fired, the more reluctant companies will be about hiring in the first place.)
The social background to the legal environment in the United States is explained in many books about hiring procedures
http://books.google.com/books?hl=en&lr=&id=SRv-GZkw6...
http://books.google.com/books?hl=en&lr=&id=SRv-GZkw6...
Some of the social background appears to be changing in the most recent few decades, with the prospect for further changes.
http://intl-pss.sagepub.com/content/17/10/913.full
http://www.economics.harvard.edu/faculty/fryer/files/Fryer_R...
http://books.google.com/books?hl=en&lr=&id=frfUB3GWl...
Previous discussion on HN pointed out that the Schmidt & Hunter (1998) article showed that multi-factor procedures work better than single-factor procedures, a summary of that article we can find in the current professional literature, for example "Reasons for being selective when choosing personnel selection procedures" (2010) by Cornelius J. König, Ute-Christine Klehe, Matthias Berchtold, and Martin Kleinmann:
"Choosing personnel selection procedures could be so simple: Grab your copy of Schmidt and Hunter (1998) and read their Table 1 (again). This should remind you to use a general mental ability (GMA) test in combination with an integrity test, a structured interview, a work sample test, and/or a conscientiousness measure."
http://geb.uni-giessen.de/geb/volltexte/2012/8532/pdf/prepri...
But the 2010 article notes, looking at actual practice of companies around the world, "However, this idea does not seem to capture what is actually happening in organizations, as practitioners worldwide often use procedures with low predictive validity and regularly ignore procedures that are more valid (e.g., Di Milia, 2004; Lievens & De Paepe, 2004; Ryan, McFarland, Baron, & Page, 1999; Scholarios & Lockyer, 1999; Schuler, Hell, Trapmann, Schaar, & Boramir, 2007; Taylor, Keelty, & McDonnell, 2002). For example, the highly valid work sample tests are hardly used in the US, and the potentially rather useless procedure of graphology (Dean, 1992; Neter & Ben-Shakhar, 1989) is applied somewhere between occasionally and often in France (Ryan et al., 1999). In Germany, the use of GMA tests is reported to be low and to be decreasing (i.e., only 30% of the companies surveyed by Schuler et al., 2007, now use them)."
Integrity tests have limited validity standing alone, but appear to have significant incremental validity when added to a general mental ability test or work-sample test.
http://en.wikipedia.org/wiki/Employment_integrity_testing
http://apps.opm.gov/ADT/Content.aspx?page=3-06&JScript=1
http://www.princeton.edu/~ota/disk2/1990/9042/9042.PDF
http://www.hotelschool.cornell.edu/research/chr/pubs/reports...
However, most companies are smaller than Google and Amazon and have different practices. Sometimes, stupid practices, because the interviewers don't really know how to do it, just want to get it over with, or really care about things which aren't important.
But since they are in the hiring position and assume they and their company are awesome, they are not so likely to question their own technical or interviewing abilities and certainly don't want to hear what interviewees have to say about it.
You need additional insights beyond just doing the job to understand what makes someone else useful in that job. And if you don't even have that much, you are guaranteed to ask stupid questions and end up with people selected for how good they are at selling and how much you think they're cool.
I think in the end its a balance of basic filtering vs. HR requirements. The process has to be objective and quantifiable so they're covered in the event of anyone calling foul play. Everyone gets the same treatment and there is a paper trail of reasons for why they turned you down.
I don't think every Java Coder would be able to tell how the internal mechanics of Java work. They aren't Java mechanics, they're just driving Java.
If you were using the photoshop analogy, then I think to interview someone, you need to ask them how different features of Photoshop work, not how Photoshop was built but also not how they draw in general, IMO. You may be a great artist, but if you can't understand Photoshop features and what they mean you will fail to create a great digital painting.
If didn't really crush people when they didn't get called back it would make it funny. Sort of like the Monty Python sketch http://www.youtube.com/watch?v=zP0sqRMzkwo
I think it's funny when the recruiters try and lie at the beginning by saying a later interviewer may or may not be out sick and there is the possibility for some interviews to be cancelled and the day cut short. We all know they want to send you home if you screw up in the beginning. It's not a secret.
In general, the interview questions I've gotten are designed to test general CS knowledge and the ability to translate an algorithm into code. This is important, and as an interviewer myself, a lot of candidates fail at the translating to code step.
Design questions are (at a high level) maybe even closer to "how would you do your job?" than coding questions.
I have yet to see a company ask for specific experience with VB.net 2012 edition and exclude candidates like myself who are only familiar with C/Python/Java. If they do, I'd recommend straight out lying (for languages). You can pick languages up really quickly. For platforms, maybe you really should know it and it is actually relevant to your potential job.
I've absolutely seen it, but I've stopped looking at it as an injustice that must be mocked, but rather a useful indicator of an organization that isn't a good fit for what I have to bring. If the economy were worse, I may have a different perspective.
I wouldn't exclude someone unfamiliar with a specific framework, but as an employer you understand that ramping them up to speed is going to take a significant amount of time.
The point I'm trying to make is that some requirements are very, very wide/broad. And then they'll take one piece of that broad pie and decide to go very, very deep.
And then there's the death knell...you spent time developing deep expertise in something no longer actively used. This applies more to frameworks than languages (i.e. Struts, Prototype, Dojo, etc.)
It's a no-win situation all around.
Granted, if they ask a few of those and then jump right in with more specific questions I would just count that as the qualifier/anti-BS filter.
If I was only given general softball 100 series CS course questions I'd probably end up trying to wrestle more info about the position out of the interviewer unless I was really hard up for a job and was willing to put up with potentially unfulfilling work for a while.
Edit: Grammar
I think you kind of answered the question yourself. ;)
This is all fairly basic stuff that should be a core competency for every software developer, and the fact that it isn't is the reason why so many Flash- and JavaScript-intensive websites are such resource hogs. The kind of things that Google, Amazon and Twitter are into that you'll never EVER need in a small 20 person run of the mill software shop are things such as machine learning, compiler theory, Bayesian statistics, image recognition, and so on.
It's also that it's incredibly short-sighted to seek such specific skills in the technology industry with the rate of change in tech.
Further, maybe the guy who can fix distributor caps came from an agency that coached him on writing his resume to emphasize this and what to prep for in the interview. I've experienced that first-hand.
If you're hiring a mechanic, yes. However, the analogy was pointing out that the person being asked the question was a potential car renter. That specific knowledge is not relevant as a car renter.
Tech start-ups and good engineering teams ask a different question: "What value this talented engineer can provide to our team or product?" Their job is not to stop people getting hired. Their job is to convert the available Human Resource to economic value as much as they can.
As far as I know hiring decisions made only by HR departments don't perform any better than randomly hiring one of those 100 candidates. Actually random is better if you really need the absolute best candidates because HR process has a high risk of filtering them out at the initial stage carried out by a clueless junior HR staff. But it's OK for the HR's sake since their actual purpose is to stop people getting hired.
If you have only position to fill and 100 people applied for that position, yes, your position makes sense. But if you have 100 positions to fill, will you still insist that you must interview 10000 people to fill those positions?
If I'm desperate to hire 100 people and I can't get 100 qualified applicants, that's when I start looking to people who could be the right people in very quick order. I've done that and ended up with some true super stars. But that was a three month investment that could have failed. I'd rather hire someone who already has the skills I need.
Whether you're hiring 1 person or 100, you're still looking for reasons to cull them.
Second, the gist I got from the "color of the wire" question was it was an analogy for asking someone to write code for a linked list. It's banal and been done before, so it seems ludicrous to ask, but many places use it as a FizzBuzz filter. I can think of very few places that would actually pay someone to "fix the wiring distributor cap" (write linked lists).
Agree with you on the second point. This comes into us not explaining ourselves very well. Questions like this ARE banal and ludicrous. But FizzBuzz filters are a great first screening. People lie (shock! horror!) on their resumes all the time. So asking them to write something banal in front of you is annoying for the people who can do it, but quickly finds the pretenders and lets me cut an interview short.
(Oh, and before anyone calls out 'interview pressure', I'll work through the problem with people who struggle. The difference between nerves and talent is blatantly obvious)
And more often than not there is absolutely no relationship between the color of the middle wire and knowning how to fix the distributor cap.
So then, by definition, you have perfect employees. Congrats. I'm sure this extends to the perfect sales team, perfect product team, etc. That is impressive.
Perhaps this is the queue for someone to suggest "that's why we try so hard to prevent bad people from getting hired". :-)
I hate those interviews and interviewees that have that attitude too. Especially since the opposite is actually the case. It's so incredibly easy to find work as a developer right now, you need to tell me why I should come work for you. Remind me why I'm sitting here talking to you instead of somewhere else that could be more exciting.
At the companies where I've worked and have interviewed people, the hiring manager would of course have veto power, but would never hire someone without the agreement of the team.
At my current company (Twilio), even the first phone screen (after a possible initial recruiter call) is done by a team lead or member of the team. But often the candidate doesn't end up on the same team as the phone screener, since we don't always know what team would be the best fit until after the screen.
I think of hiring as everyone's job, as it's right up at the top of the list of things that will determine the course of company culture over time.
(Shameless plug: having said all that, if you're an Android developer who enjoys building frameworks and APIs, email me at my HN username at twilio.com.)
That's what bothers me so much about it. The team and the culture is hugely important. I appreciate that the interviewer has determined culture fit, and that's fine I guess, but I want to know that I'll like the team I'll be working with too.
When I'm interviewed, I take it as a bad sign if I'm not allowed to meet other members of the team. Typically they're included in interviews, in which case it's a non-issue. In other cases, I make a friendly request to meet 2-3 members of the team for a short conversation. I've only had to do that once though.
It's just surprising that this is consistently a problem. I shouldn't have to make the extra effort, it should be part of the process.
but it's good information, well referenced, and I don't have the background or time to refute anything you've said.
In face of all the time and effort you've voluntarily put into this research, I hereby thank you.
Easy. Isn't it?
Edit: Also, tokenadult has a very interesting profile. Scroll down to "METAINFORMATION". Great work!
There's a whole paragraph duplicated in the profile, starting with "I'm founding director". If nobody has ever noticed that, the info is probably not in the best place to be read.
I like how American employers think everyone in the US is sane, smart, and educated, unlike the rest of the world.
If Carpenters Were Hired Like Programmers
The real world problem is that too many interviews follow the model because that's what they know from past experience themselves. They may not know why they ask such baseless questions, all they know is the answer they want and damn you if you don't give it to them.
The programmer equivalent of the middle wire color question is something like, "Is the 3-phase power supply on XYZ mainframe wired in a delta or wye configuration? As a followup, what is the input frequency tolerance?" A sysadmin might need to know that, and an electrician certainly would, but it is far, far outside the purview of a programmer. [Edit: I'm assuming the programmer to be someone writing software running on the mainframe, not the firmware for a microcontroller in the power supply]
Maybe you're just a very good interviewer and haven't had to deal with the 90% that are crap? :+)
So they just don't care if you are good at what you do, if you can learn fast, etc -- all they care if whether you are not shit and can certainly fulfill the specific requirements for the job they were instructed to fulfill.
How to change this? Well, one way would be to get people interested in the applicant's abilities and long term capacity and commitment. It's good to find this kind of people inside a company which are not in the higher ups. Another alternative would be to attach the long term success of the applicant to the ones responsible for hiring somehow. Those are all very difficult problems, but ones that can be managed with good will and commitment from the guys inside the company.
We absolutely cannot bring in someone crap. Our job is to hire, so if we're hiring crap people, we're crap at our job.
See my comments elsewhere in this thread regarding learning fast, but basically I'm going to hire someone who can learn fast. But primarily I'm going to hire someone who doesn't need to learn the 'right now' skill.
I'd love to see a system that tied each of my hire's success to my success. It happens for the first three months: "Hey lessnonymous: this guy is brilliant! Good job!".
But I want to see a system where each pay-rise or promotion the engineer ever gets is recorded against my success too.
"We see your hires got a salary increase of 10% on average. Here's your 10% increase." (It would need to be waaaay more complex than that to look at churn, promotions, firings etc.)
On a link stream + discussion style site (which HN appears to be), though, you don't really have any idea who's participating at any given moment, or who's seen/absorbed material from previous discussions. I've been reading HN on/off for about 3 years, I can only recall having seen this once before, and seeing it again is an interesting reminder.
Apparently others have seen it a few times and are tired of it, but by and large, I'd think the scoring system could handle the general opinion of the community pretty sell: if enough readers still find it to be new/interesting information, it'll stay highly visible. If readers are tired of seeing it, presumably it'll sink to the bottom.
This analogy is proving more accurate as I read thru the comments.
We all seem to consider this as true about being a Good Programmer ("Sure, I can learn $language_that_you_use"), but are frustrated by HR departments who don't realize it.
This analogy can hold together for half a sentence at most. The concerns involved in hiring a programmer and selecting a customer to rent cars to have almost nothing in common.
And if you want to use an analogy in an argument, you first have to argue that the analogy is valid.
Articles like this contribute nothing to my understanding of hiring.
(This being an example of course)
You don't want people to learn on your time? That's incredibly short sighted. Real engineering is about learning all the time, whether it's taking a formal training session or just reading a long post on StackOverflow. If you don't want to pay your engineer to learn things then you simply don't care about the engineering quality of your company and all you care about is short term payroll bottom-line.
I feel sorry for the engineers who work under you.
But I don't want people learning the "right now" skill on my time.
If I need a PHP developer right now, then I'm going to hire someone who knows it right now. I'll preference someone with C skills and I'll preference someone who participates in an open source project. And I'll preference someone who reads Hacker News. And I'll preference someone who has a great profile on Stack Overflow. And I'll preference someone who attends or presents at conferences.
But if they don't know PHP, they're not going to be learning it on my time as I need someone who knows it right now.
There's no need to feel sorry for my team. The things you read on a Hacker News comment reply aren't the entirety of working for me. Maybe you'll be sitting across the desk from me one day and you'll get to work with an awesome team of talented engineers. Carefully selected.
And any good engineer can work blind on a new technology and still produce decent results. If a great engineer with no knowledge of PHP is required to build a PHP website they can sit down with a PHP book open on their desk and crank it out. They fact that they're mentally superior to other engineers (whose expertise on a narrow subject might be better) and know programming inherently better means there's a good chance their output on something they don't know could be comparable to the PHP coder.
The best managers always build skills in teams. It's part of compensation. Every engineer views bullet points on resumes as a form of income. "If they don't know PHP, they're not going to be learning it on my time" means that you're going to be paying higher salaries with higher turnover and much higher recruiting costs. And if that's not true then something scarier is true: you're actually hiring low-quality engineers who don't realize you're a bad manager with a bad team (or who have no other options than to pimp out their 8 years of SharePoint 2003 experience).
Maybe you wouldn't have such an urgent need to hire experts in narrow subjects if you had staffed your team with intelligent quick learners in the first place! Tip: next time you need an expert in subject X try telling your best engineer: hey I have a project coming up for an X project and I'd like you to play a key part, so can you study up on that as it'd really impress me.
What an arrogant prick.
That's what you employers do: you filter out everybody, so there are left like 3 people in the same continent who fit your arbitrary criteria. Then all of you get into a bidding war over those 3, and most of you find that you can't afford to hire.
Finally, you start whinging about a "talent crisis" and blaming the universities for not producing people with the right skills.
Well you made your beds, now lie in them.
At a guess you're projecting other managers complaints on to me. I'm not in the U.S. and don't have these problems.
So you've got actual words from actual me:
* Those three people are worth the bidding war. They're worth 10 times the next rung down.
* I need to fill the position with the best possible person. It doesn't matter that Google et al have take the top people, I still need a new engineer.
* Universities generally suck time and deliver little. Spend the three or four years getting a ton of experience and participating in the community and you'll jump ahead of someone who's passed university, but doesn't have their own project.
So you will pay 10 times more salary, rather than waiting a couple of months for a new engineer to get up to speed? You must be in a hurry. What about all those other employers doing enterprise CRUD apps, are they in a similar hurry?
"I need to fill the position with the best possible person"
I assume then you are not working on enterprise CRUD or dinky mobile apps like everybody else. Are you competing with Unreal's next game engine? Or working on a rocket to Mars? Because your peer employers are NOT.
Yeah, those guys who complain about not finding candidates.
And someone else getting up to speed wont make them the best person for the job. It will make them adequate.