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.

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.

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 hire an electrical engineer, do you test them on understanding Ohm's law?

If you hire a window washer, do you test them on cable strength integrity questions?

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.

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.

Maybe this isn't universal, but I'm used to most applicants being hopelessly unqualified.

2. Damn right (more specifically I'd ask some kind of basic problem about circuits)

3. Of course not - don't be ridiculous. I'd test them on their knowledge of chemistry, fluid dynamics and celestial mechanics (duh).

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)

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?

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.

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.

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.

That should be an impetus to improve your hiring process, assuming it isn't a rare occurence.

> They probably had a job before they accepted your offer. Now they're unemployed and it's your fault.

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.

> Firing people frequently is also expensive and it's demoralizing for the team.

See point #1. Firing people frequently is a sign your interview process is broken.

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.

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 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.)

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.

There are few things more demoralizing for a team than keeping jerks around.

Unfortunately, jerks are an overrepresented demographic in programming.

Yes, sometimes you will need to fire people. But the strategy should be to hire the right people in the first place.

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 :)

In general, I tend to prefer people who are able/motivated to learn, as opposed to X years of experience in keyword Y.

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.

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.

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.

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.

EDIT: Side note, we also generally build the interview questions, then write the ad. Since we already know the answers we want, the ad comes fairly naturally from that.

> I think in any field it's important to decide on the desired answer (from what traits and skills you need), then build the question.

My previous job liked to hire by committee that was created by randomly selecting employees to participate with hiring. (already a mistake) Even though these included the department head actually hiring, we'd often find that most of the time in meetings was spent asking or telling each other what was "really" necessary for the job, since even if we had a solid job description and list of wants, the committee members would squable since the jobs were allowed to be too flexible. When it came time to design questions, we would run into the same problem each time: We were more focused on "good questions" than deciding what we really wanted the answer to be and designing questions around it. This often resulted in really poor interviews where we let applicants just talk their way through any of our concerns because there was no concrete idea of what we were looking for.

I think in general this tends to be an issue with employers who have difficulty with hiring - they are not good at articulating their wants beyond "we need a web developer" or "database admin" - undoubtedly it's managers who were told "don't get too specific with your wishlist", the idea being to prevent job postings with absurd requirements, but it's swung too far in the opposite direction in many cases with employers relying exclusively on keywords as indicators of success. ("They know X language and have worked with Y hardware - they're perfect")

The hard truth is that even though hiring sucks and can take forever if you're not careful, it's worth taking the extra prep time to ensure you have a clear idea of the type of hire you want. Anything less is a disservice to your company, your employees, your customers, and your new hire. The HR hatchets are generally not useful either, as they're too broad sweeping and the same tools that weed out the absolutely unqualified also end up weeding out those who haven't jammed the right keywords into their resume. Neither ends up getting you what you want; while it's shitty to have to read potentially dozens or hundreds of resumes, if you're struggling to fill positions with good people, it's a necessity.

Generally, good people are always willing to learn, and challenge themselves, and listen to others, and doubt themselves sometimes, but not too much, and act according to their values, and have a vision and enjoy life.

Find as many of these traits in someone, ane you would have found a great partner.

Admittedly, judging ability is very subjective and hard to do, but it's worth pointing out that judging someone's ability is fundamentally different from keyword matching.

With keywords, the only possible answer is a yes/no. Do you have Java experience? Yes/No. Do you have VP-Sales experience? Yes/No. Do you have 10 years of work experience? Yes/No.

Keywords provide no judgement on how good a performer someone is. They only tell you what that person has done in the past. Anyone can spend 5 years programming Java. But does that mean he's going to be a good Java programmer during his spell at your company? The keyword provides no way of answering that question.

Judging someone's ability on the other hand, even if it's imperfect, even if it's flawed, at least makes an effort to understand the person's potential capabilities. And that alone, makes it superior to keyword-based recruiting.

(or at least that's the argument the article seems to be making)

Asking brain teasers is fine as long as that's what your technical people actually do all day -- sit around and ask each other wacky logic problems they half-remember reading about on the internet somewhere, continually trying to one-up another (and if you don't answer with 90 seconds or so, you get fired, on the spot).

But for most software engineering roles, not so much.

What's really cool about it as well is that he expects both the candidate and interviewer to read the same book. Pretty powerful.

Other than a brief flash of insight that you can do something like: 37^2 = (30 + 7)(30 + 7) = 900 + 210 + 210 + 49, I'm not sure what this was supposed to test. It was a fairly small company, but I'm sure they could afford a calculator or two....