I liked the part about internal recruiter's incentive structure. It's basically the old standby that nobody ever gets fired for buying IBM. This implies to me that there's a huge amount of value for companies that can change their hiring metrics and find undervalued engineers.
One thing that I disagree with is the idea that filtering processes can't make candidates better. A properly created process should leave both sides of the equation happy, an engineer can learn new skills and a hiring manager can have a shot at making an offer to an engineer if s/he has the requisite skills. If the candidate doesn't have the skills then give them the tools to learn the skills and see if they come back showing mastery. Work ethic and being ready/willing/able to learn new things is the number one signal that an employee is going to work out well, at least on the teams that I have run.
Author here. What I meant was that right now there isn't much of a feedback loop when it comes to interviewing. If you get rejected, you often don't know why. And that sucks.
I'm half joking, but yes, it's a serious problem. What sucks more, is that even if you clear the interview, you don't know what things you're doing well, because there is no feedback.
Perhaps the author's point about filtering wasn't so clearly made. The idea is that if the best candidate that enters the funnel is a 6.2 on a 10 point scale, no amount of filtering will produce an 8.3 out of 10 candidate. To get 8.3 candidates to the filter you have to source candidates above 6.2.
Ah, I think I was not terribly clear when making my point. I don't think that candidate scores are static and, even if they are, there's a significant amount of measurement error no matter the interview process.
Ideally I want a hiring "fun"-nel where a 6.2 can learn the skills necessary to become an 8.3 (or show that they've been an 8.3 all along) through exercises or reading assignments. Sort of an external training/hiring funnel. If nothing else it may also help as a way to build internal training processes and advertise the to the world some of the neat stuff you are working on. I think this is how Matasano recruits and it makes a lot of sense to me.
Pretty much no matter what there is a learning curve associate d with bringing on a new hire. Finding candidates that will attack those curves with gusto is key to building good teams, I think at least. Technical skills can be taught and refined, gumption is a bit harder to instill.
It's difficult to know when to invest the time in giving candidates feedback. While I would love to do it every time, giving any feedback during the hiring process is a legal minefield and not every candidate appreciates it. In my humble opinion, any engineer who has top-tier potential will be able to derive from the questions asked during the interview process what they need to learn in able to get a job (note, I did say "get a job", not "be a great engineer" - thinking that those are the same skillset seems to be the first mistake many job-hunters make).
I am speaking in terms of accurate measurements...an 8.3 is actually 8.3. Precision is a different issue, but if there are no actual 8.3's in the funnel, then while filtering may improve precision there will never be an actual 8.3 at the narrow end.
I found that interesting as well. If that's true - and I assume it is, if the author says so - it's completely bonkers. I wonder what the purpose of those in-house recruiters really is, if all they do is source candidates with pedigree? That's something linkedin can do for you.
@leeny, Q. for you, how should startups tackle the problem of re-qualifying "experienced programmers" outlined in this quote:
"There are good arguments for allowing experienced programmers to skip screening steps, and not have to continually re-prove themselves." [0]
How do you solve this problem? Surgeons, pilots, Infantry soldiers, classical musician have extensive and verified training that equips them for high levels of technical execution in each field. Each of these professions have some form of continual re-testing and evaluation. What makes technical candidates in software a special case?
I did five year of engineering school, like a lot of other people. Let's see how I could have used this time in other fields.
In five years, an infantry soldier can go to bootcamp (BCT, 10 weeks), advanced infantry combat school (4 weeks). Then he'll go on to a combat unit, and train with them to prepare for a combat deployment. With a week or two of visits home, this will take up the first year. He could use the remaining four years to conduct up to two 18 months combat tours (with about six month back in country after each one), deployed in a warzone. At the end of his five years, providing everything went well, he will be considered ready to try joining the special forces, if his IQ and fitness are good enough. He could go to NCO school or officer school even sooner, after his first combat tour.
At the end of his five years, a just graduated engineer is considered too green to touch a production server, much less try joining the 'special forces' of our profession. The difference in autonomy in various professions after five years is striking. A surgeon would just start his internship, and assist senior surgeons, but a pilot would already be flying for several years!
That kind of skirts what the grandparent is asking, in the army for example everyone has to annually qualify with their firearm, and each mos has set of tasks they have to demonstrate competency in. All enlisted have to do this with the difference being more senior are also responsible for training. I think that's what the g
p was referring to.
Also five years in the military you aren't in school, you are doing your job. So if an engineering grad did five years of work study or coop, I think they could be trusted with prod servers as you say.
Programming teaching sucks. This is not too surprising considering how unstable programming is. Heck, people who were excellent programmers 10 years ago can suck, I've worked with some of them.
Credentialing of some kind needs to exist for software engineering. Clearly traditional means like college degree aren't cutting it, and more and more people are going outside the system to learn to code, so I expect degrees are going to become even more noisy over the next few years.
Whatever this credentialing looks like, I hope it's based on ability rather than proxies.
The difficulty with credentials in software development is that you need some sort of objective standard for the knowledge and/or skills required to merit a certain credential.
No-one really knows yet how to consistently build good software with a normal workforce within commercially realistic timescales and budgets. For that matter, even what constitutes "good software" probably depends on the context; in the real world, it is usually a question of "good enough" rather than any absolute standard that applies to all projects. Therefore, I'm not sure there is anyone in the world who could write those objective standards yet.
Even if there were, there is a significant risk that they would be shouted down by the kind of consultants who don't actually make a lot of software and don't actually have a good track record of success in their own projects, yet have no problem writing books, blogging, speaking at conferences, or otherwise telling the rest of the industry how it should be doing its job.
That could lead to the worst possible outcome: an industry with de facto or even de jure regulation of who may practise, similar to other engineering disciplines for example, but where the regulation actively favours people who are buzzword compliant and up on the latest fads, rather than people who are actually good at building useful software.
What makes someone a good engineer? Who would have thought that Larry Page or Sergey Brin were simply magical engineers BEFORE they devised Google Search and created nearly half a trillion dollars in value? In my impression, you will only know when it is too late already, because at that point they no longer need you.
"Engineering hiring isn’t a filtering problem. It’s a sourcing problem." Yes and all hiring is a sourcing problem, when it comes down to it.
There are so many recruitment companies are out there on the horizon, especially in London right now.
It's a big space to dive into and a lot of people assume that they can tech their way out of it, but it takes a lot more than a fancy algorithm and a joint dislike of shitty recruiters to be useful.
Perhaps this is a good time to float the idea that developers should have a transfer market, like footballers, with the associated talent development process.
It would then be worthwhile to train and improve your employees, as they become a tradeable capital-like asset rather than a form of labour.
(The downside might be greater difficulty in quitting toxic employers; perhaps another job for the standards body / union.)
or really just accept the fact that the recruiting business is sketchy and most people, talent and hiring managers no longer trust most outside recruiters.
I'm really sorry, but I stopped reading when it was implied that the "good" engineers are the ones at Facebook/Google that went to MIT. If that's your idea of a necessary condition for "good" engineers, I think you deserve what you get.
The old "I stopped reading at ..." routine is pretty annoying even in the best of circumstances, but particularly so when the basis of the complaint is misinterpreting the article. There is no implication made in the article about only Facebook/Google engineers being "good". There is however exactly the opposite implication being made about both the definition of "good", and how this kind of credentialism is a structural issue. Too bad you stopped reading before getting there.
In an article claiming that finding candidates is harder than filtering candidates, her first point ends by saying "hey, you could just crawl all the job sites for people who work for Google/Facebook and went to MIT". How no one gets the implication there is beyond me, but reading further just reinforces it.
Secondly, if it's a structural issue, creating a new startup based around technical-recruiting is absurdly pointless. If it's structural, your startup is going to accomplish _absolutely nothing_, because it's just going to keep sending in safe candidates, in favor of qualified candidates.
Author here. I get why you parsed it the way you did. I guess what I was going for is that conventional wisdom dictates that those candidates are the good ones, and I was using that as kind of a hyperbolized thought experiment. I do NOT agree that pedigree is a good predictor of aptitude. I even did a bunch of research around this. Check out http://blog.alinelerner.com/lessons-from-a-years-worth-of-hi...
Message board nerd pro-tip: You can always --- like, in every single case --- make your comment better by changing "I stopped reading" to "I almost stopped reading". It conveys exactly the same sentiment without broadcasting the notion that you haven't actually read the thing you're criticizing.
If the poster actually stopped reading I don't think adding "almost" is good advice. I'd rather read the truth than a lie. However if I read a post that says "I stopped reading" I expect a good reasoning why to see if it makes sense. Unfortunately usually it's "i stopped reading because it sucks".
I went back and read the whole thing, still could have stopped after the first point, everything else is just a supporting argument.
However I've read posts where you disagree with the same exact sentiment: credentials don't tell even the majority of the story of whether someone is qualified.
You stopped reading too soon. If you'd read through, in Example 1 you'll find an explanation of why companies have an incentive to focus on credentialed engineers, and a footnote indicating that her willingness to source other kinds of candidates has caused problems for her with internal recruiting.
By no means does she think that the only good engineers are credentialed.
You need to keep reading, they explain the mis-aligned incentives of an internal recruiter later:
1. Bring in 10 StanFaceGoogMIT candidates, one gets an offer they don't accept - keep up the good work.
2. Bring in 10 ugly on paper candidates, two get an offer, and one accepts - expect a stern talking to about your performance.
Someone from a no-name school, no relevant/interesting companies, technologies that aren't considered cool at the moment, and from somewhere you consider backwards. Think South Carolina at the moment.
Imagine you're a Stanford alum (even dropout) working at Google. If someone from University of [current bad state] comes across your desk with their main work experience being enterprise consulting in Java, odds are you're going to pass and look at the next person.
Quickly filtering by these "important" things seems to make some sense except for the fact that none of these factors tend to be indicators of success or failure. You may be saving yourself some time but you're missing some good candidates too.
But they wont turn them away, and that's my problem with the article.
I went to an absolute shit school (like, bottom 150 of world ranked schools) an I had interviews that lead to offers with Google, Facebook, Microsoft, Intel, among others, when I graduated. People from my graduating class are working at many of these companies, i.e. with the same background as me.
So clearly it can't be a horrible problem if they seem happy to employ people from my no-name, considered harmful, school.
Who knows, maybe every single one of us got extremely lucky, or some engineering managers just happen to know it doesn't take a M.S. from MIT to know how to write good software.
When you say I stopped reading when then you make a judgment you also have to accept your idea is based on incomplete information.
Edit: Btw I upvoted because I believe we should all try to refrain from making judgments based on incomplete information, WHEN we have the data in front of us but decide not to go through it all. I do this a lot.
I read enough to know what the author was asserting (that finding candidates is harder than filtering candidates), and I stopped when I realized her supporting claims were ignorant.
But people do this all the time. When people argue in person, they spend most of their time not listening to the other side, but trying to formulate a reason the other side is wrong.
It's not the right thing to do, and I know that, and it's why I put "I'm really sorry" at the start.
Ok, why do people keep down-voting movak. They just stated his opinion, rectify them if wrong, but down-voting is not very helpful. Also we should up-vote comments we truly disagree with to give others an opportunity to learn what may be wrong.
He missed my favorite sleazy tactic. One of these technical recruiting companies is advertising a job ... and you have to sign up for it with their alpha system. It usually is so buggy that I can't complete the process.
One thing that I disagree with is the idea that filtering processes can't make candidates better. A properly created process should leave both sides of the equation happy, an engineer can learn new skills and a hiring manager can have a shot at making an offer to an engineer if s/he has the requisite skills. If the candidate doesn't have the skills then give them the tools to learn the skills and see if they come back showing mastery. Work ethic and being ready/willing/able to learn new things is the number one signal that an employee is going to work out well, at least on the teams that I have run.