Yes, that's exactly what we should all be doing more of.
Hiring is always a risk, and the "accepted" risk-mitigation strategies (hiring by keyword, brainteasers, etc.) have been shown to be stubbornly non-predictive. At best they apply a misleading veneer of certainty on an inherently uncertain process, and if I'm going to take a risk I'd at least prefer that I not fool myself about it.
So yes, accept more risk in hiring. You're already taking risk, but by accepting the feeling of more risk you'll at least be more deliberate about it.
Thresholds seems to be a huge missing component to this stuff. Syntax, obscure trivia, brainteasers, etc are generally terrible predictors. However, if you ask someone to find say the average (mean) value in an array and they can't even get close that's a problem.
IMO, this comes from the mistaken assumption that you want to most technically competent person possible. Instead basic competence is a minimum barrier and everything else combined is more important.
Totally agreed. "Fizzbuzz" has become a bitter joke among good developers, but it tests something (sadly) important: can you write a basic loop and conditional statements? Or more cynically, are you a total fraud? You don't have to ask Fizzbuzz to test that, but you do have to ask something.
For me, if you pass the test of basic competence, and you can demonstrate evidence of accomplishment in any language, and you seem to pick things up quickly, then you're probably a risk worth taking.
(Actually, ignore everything I'm saying. I don't want the rest of the market to catch on. :)
> If you're hiring a HR manager, do you have them take a basic English skills test?
Yes, an interview in English is an English skills test.
Programming has the odd problem where you want someone that speaks code so you need to ask them to speak it in some form or other. Yet, if you ask someone to demonstrate even the most basic form of competence some people lock up.
IMO, the best option is to give programmers the same kind of fuzzy test your giving HR managers. You don't need someone that can decode for (int i = -6; i++ < ++j; k++) ... but they need to be able to understand how to use a loop to get something done.
Yep, that's exactly my point with the HR example. The interview itself should be the programming test, not some artificial, condescending introductory literal test.
If interviewers dealt with candidates from any other professional field in the same way that software professionals are commonly interviewed, there'd be a ton more people walking out of interviews.
The problem is the number of people that fail FizzBuzz or morally equivalent interview questions. It's so bad I think companies that don't ask candidates to code could skip interviewing about general background entirely, replace it with a 15 minute trivial coding exercise, hire anyone who passes, and be noticeably better off.
Maybe this isn't universal, but I'm used to most applicants being hopelessly unqualified.
Is this actually true? How many candidates have you failed for FizzBuzz specifically? Personally I've found it to be almost always passed. My previous company would ask for a simple implementation of pow() and strpos() and that had a decent filter rate.
I'm not sure about the point of your post, but to respond:
1) No - you screen those out with spelling mistakes in their resume
2) Maybe? I'm not sure - I'm not an electrical engineer. Then again, credentialing an EE is probably easier than a programmer.
3) This one's not even a good analogy - of course not.
What makes programming a little different is that it's turtles all the way down. While you might not need to find the average of an array, you will need the ability to reason about such things. You'll be reducing a collection of items, or mapping them or summing them.
You basically must deal with abstraction as a computer programmer. (And I'd argue that yes, assembly deals with abstraction)
1) But you don't use the resume to detect whether somebody is blowing BS about their software understanding?
3) It's a very apt analogy. Tons of especially lower level candidates are doing weird tricky CS problems at interview even if they're building yet more basic reporting systems.
Regarding abstraction, why don't you ask them to describe projects they did, instead of grilling them on concocted problems you know are beneath the level of person you wish to hire?
Google et al aren't asking to find the average value in an array. They're asking questions that boil down to "do you know the Boyer-Moore string search algorithm?" or "Can you correctly identify this problem as a rephrasing of the boolean satisfiability problem?" which, in the context of an interview, correlate only weakly with whether you're a good software engineer and instead correlate most strongly with how frequently you took or refreshed your Data Structures and Algorithms courses.
>>instead correlate most strongly with how frequently you took or refreshed your Data Structures and Algorithms courses.
It is well known that this companies test for this knowledge. They even tell you about it during their process so you will be ready for it. At the very least, it tests that you can learn this things from study. If you fail at them, you either did not prepare in the way they told you to, which is a failure to follow instructions, or you tried to study and it wasn't enough, which is a failure of ability to learn. There are probelm with this; the conext on which you are evaluated is vastly different than the environemnt wher eyou will ahve to apply it. But that doesn't mean the assesment is completely random. It tests for some qualities that will be important on the job.
This is complete BS. It's possible you got a bad interview, but this is not remotely the pattern. If it were, Google would struggle to be hiring hundreds of developers a week.
Given the number of developers I've seen who list SQL as "expert" and can't write a simple JOIN, or actually cannot complete the FizzBuzz challenge. As an example, I've been a pretty big fan of JS for a long time (since well before 'The Good Parts'), and after "AJAX" became the next big thing, wound up on an interview panel, and man, the number or developers putting "Expert" on their resumes who didn't even know some fundamentals were staggering.
Maybe it's just me, but when someone uses the term expert, I tend to be doubly suspicious. Especially if they use that for more than one or two skillsets.
To add to this, tasks risks in hiring but fire fast. Seriously as a hiring manager my best hires have been, on paper, the least qualified for the position. And when we've hired bad people, removing them within the span of 6months have been incredibly helpful. The corollary, not firing them fast enough has really hurt.
This is my concern with the fast-fire strategy. If you do a poor job with the interview process and hire someone who cannot do the job and have to fire them, you're messing up that person's life. They probably had a job before they accepted your offer. Now they're unemployed and it's your fault.
Firing people frequently is also expensive and it's demoralizing for the team. You also don't earn loyalty by showing that you have none yourself.
> It is not entirely your fault, unless you didn't effectively articulate what the job was. Otherwise, they took a job they knew was over their head.
It's mostly your fault. You know what the job is and what your expectations will be far better than the candidate. You should be hiring only when you are confident that they will be able to do the job.
> See point #1. Firing people frequently is a sign your interview process is broken.
Yes, that's exactly my point. "Fire fast" as a strategy should not replace "hire well". Your hiring process is entirely messed up if your strategy is "tasks risks in hiring but fire fast".
Sure, if you made a bad hiring decision, you may need to fire someone. But your hiring process should in general be filtering out poor candidates.
I'm pretty confident that the overwhelming consensus is that the tech hiring process IS broken.
Businesses either bias their individual hiring process towards false negatives or false positives, but no one has apparently figured out how to find the balance.
> Firing people frequently is a sign your interview process is broken.
Firing people frequently after a short term of employment is a sign that the hiring process (interviewing is part of that, but perhaps not the problem part) is broken.
Firing people frequently but long after they were hired may be a sign of hiring process problems, but is more likely a sign of post-hiring working environment problems.
(Well, actually, in both cases those assume that the firing decisions are, themselves, justified in the individual cases; obviously, either of the above could be a sign that the firing decision process is broken, instead of some other process.)
Absolutely right. I was sloppy in using "interview" to mean "hiring". I was implicitly only considering the short-term case, though. I agree that the long-term case implies more fundamental problems with the organization.
>>> If you do a poor job with the interview process and hire someone who cannot do the job and have to fire them
I think it largely depends on how do you fire people.
If you just decide 'fuck it, he's out' than yeah, that's awful. But if you give a chance to correct the issues, and actually give the chance rather than imposing some impossible requirements with your mind already set, that's different. Sometimes you just need a little push.
>>> Firing people frequently is also expensive and it's demoralizing for the team
Not sure about the expensive bit (it's better to fire sooner than later if you're going to fire anyway), but also concerned about the morale. Unless that's a very rare occurrence for quite obvious reasons, it will no doubt demoralize the team.
I suspect that a bad programming hire will usually be fairly obvious to co-workers. Like, "firing fast" will probably be after the point where other programmers will have thought "I don't want to work with this person any more"
I'm talking specifically about the "tasks risks in hiring but fire fast" strategy above. If your strategy is to hire without due diligence because you'll just fire later, that's extremely inconsiderate and also demoralizing.
Yes, sometimes you will need to fire people. But the strategy should be to hire the right people in the first place.
I think of it more as a continuum that either full due diligence or hire most anyone who seems decent.
I agree that the latter version is wrong, but there is room to adjust how much you work on predicting future performance. How much of a jerk people are is one of the harder things to predict in interviews.
I get the feeling we're both speaking with previous unfortunate experiences in mind :)
The only thing that makes this hard, is when you spend a month looking for a viable candidate, and need work done, and have to pick someone... The person isn't your ideal choice, but the best of those available. It'll work out, or it won't.
In general, I tend to prefer people who are able/motivated to learn, as opposed to X years of experience in keyword Y.
One of the few times I've outright quit a job without another on the table was because of conflict with a "jerk" (overt arrogance irks me) that had too much political clout in the company to overcome. Of course broken process in a larger company is almost as irritating.
Since high school I have been under the impression that was how all businesses work. It wasn't until I got into the working world that I realized some organizations are so imbued with CYA that it can take literally years to fire a shitty worker.
I am very clear with how things progress. You have to be: 3mth evaluation, 6mnth evaluation if 3mnth wasn't going well. A clear onboarding process and written docs to get people up to speed. A pairing with another developer. Several story tickets which aren't designed to produce results fast but rather to educate.
That said, you also have to have an understanding of your interview process: no brain teasers, no language lawyer questions, etc. A peer reviewed collection of interview questions and a rigid methodology to make sure time pressure/stress/etc. are not part of the interview.
But is this legal in all countries and states? Because in some places, you can definitely take risks in hiring and fire fast, because employment is basically 'at will'. In certain other areas, there are all kinds of restrictions on how/when/why you can fire someone.
This might be why a lot of companies use these tests. Because in some places, you need to filter out 'bad' hires before it becomes difficult to dismiss them.
Obviously can't speak to everywhere, but the statutes around here (right to work) specifically allow for an initial probationary period.
Within the first few months of employment (or less/longer, as set out in a contract), the employee can be easily fired. They want similar reasons to a normal firing (underperforming, inappropriate behaviour, etc) but the information I can find says that the bar is set much lower and they're more just worried about you "acting in good faith".
I've rarely (if ever) seen it used. Usually people want to take the time to try and develop the employee, but they end up shooting themselves in the foot. If you hire someone that's not working out you can let them go pretty quickly. Once their probation is up you're stuck with them. So fire fast, don't dick around.
Yup. Or if not firing, then some other action like redesigning the job around the skills the employee actually has or transferring them to something they can actually do.
I've seen this from the other side, when I accepted a job that turned out to require skills I didn't have. It was an unbelievably crappy experience. Prompt action -- within the first six months, maybe -- would have saved a lot of grief.
Yes, that's exactly what we should all be doing more of.
Hiring is always a risk, and the "accepted" risk-mitigation strategies (hiring by keyword, brainteasers, etc.) have been shown to be stubbornly non-predictive. At best they apply a misleading veneer of certainty on an inherently uncertain process, and if I'm going to take a risk I'd at least prefer that I not fool myself about it.
So yes, accept more risk in hiring. You're already taking risk, but by accepting the feeling of more risk you'll at least be more deliberate about it.