7 ms·

This is an example of an article that does a great job of identifying the problem (seriously -- I think it's great), but it has limited impact because it doesn'

This is an example of an article that does a great job of identifying the problem (seriously -- I think it's great), but it has limited impact because it doesn't offer concrete steps towards a solution. It is hard to interview for intangible keywords -- how does the choice of keyword change that? Is the advice here just to take risk in hiring? That's not going to be received well...it can be just as damaging to make a bad hire for non-technical factors as technical ones, and I suspect this is why so many companies rely on terrible technical interviews. The broken part of tech interviews isn't that they ask technical questions, it's that no one on the hiring side looks at their process and asks "what is it that this part of our process is measuring?" and "does that factor matter in making a hiring decision?" Asking brain teasers and CS "fundamental" questions is fine as long as there is a good answer to those two questions, but instead everyone does cargo-cult interviews because Medium says that's how Big Tech does hiring.

stinkytaco 10y ago
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. We use a scoring system (1-4) in our case and for each question the interviewer has several general bullet points the interviewee ought to be hitting on. For a simple example, if we're hiring for a desktop tech, we might ask what steps you take when troubleshooting an individual who claims their PC is slow. The desired answers might be: determine scope of problem (how often, how slow, is it affecting work duties), determine specific triggers, check PC for known issues (spyware, virus, etc), research, attempt resolution. We don't expect exact wording or even total coverage, but at least everyone is on the same page in terms of expectations. This has proven to be a very effective way of getting quality people into positions at a variety of levels. 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.
- csydas 10y ago
  Though I've been hiring for much smaller institutions, I can attest that this is a common problem for virtually all hiring processes: > 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.
peterbonney 10y ago
Is the advice here just to take risk in hiring? 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.
- wheaties 10y ago
  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.
  - underwater 10y ago
    Do the people you're hiring know that this is your playbook?
    - vonmoltke 10y ago
      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.
    - dpark 10y ago
      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.
LeanderK 10y ago
its hard enough to identify problems and i think you don't need a well thought out solution before you can start to explain the problem. Maybe the next post will be "Do Hire by Ability to multiply numbers in your head", because that worked out well in practice. Or not. I liked the article and i think these kind of question are harder than they look. Demanding solutions is too much.
- mattkrause 10y ago
  Once place actually did ask me to square a number in my head. 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....
whack 10y ago
I think the real lesson is that you should be hiring on the basis of ability, not keywords/checkboxes. 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)
zer0gravity 10y ago
Ford said : "I fired all the experts because they always told me why things cannot be done". I call this dead knowledge. 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.
apinstein 10y ago
We just jumped down this rabbit-hole for a few weeks as we go through a hiring sprint. There's a consultant in this space that makes this exact argument -- Lou Adler -- and he's got the entire process spelled out in one of his books: https://www.amazon.com/Essential-Guide-Hiring-Getting-Hired-ebook/dp/B00B9JZMKE https://www.amazon.com/Essential-Guide-Hiring-Getting-Hired-... What's really cool about it as well is that he expects both the candidate and interviewer to read the same book. Pretty powerful.
kafkaesq 10y ago
Asking brain teasers and CS "fundamental" questions is fine as long as there is a good answer to those two question 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.
- collyw 10y ago
  Yes this annoys me these days. I was relatively good at these straight out of university. Now after 13 years of writing software I find my ability to do them is hit and miss. I do however write far better, more maintainable, cleaner software than I wrote straight out of university.

stinkytaco 10y ago

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. We use a scoring system (1-4) in our case and for each question the interviewer has several general bullet points the interviewee ought to be hitting on. For a simple example, if we're hiring for a desktop tech, we might ask what steps you take when troubleshooting an individual who claims their PC is slow. The desired answers might be: determine scope of problem (how often, how slow, is it affecting work duties), determine specific triggers, check PC for known issues (spyware, virus, etc), research, attempt resolution. We don't expect exact wording or even total coverage, but at least everyone is on the same page in terms of expectations. This has proven to be a very effective way of getting quality people into positions at a variety of levels. 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.

csydas 10y ago
Though I've been hiring for much smaller institutions, I can attest that this is a common problem for virtually all hiring processes: > 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.

peterbonney 10y ago

Is the advice here just to take risk in hiring? 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.

wheaties 10y ago
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.
- underwater 10y ago
  Do the people you're hiring know that this is your playbook?
  - vonmoltke 10y ago
    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.
  - dpark 10y ago
    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.

LeanderK 10y ago

its hard enough to identify problems and i think you don't need a well thought out solution before you can start to explain the problem. Maybe the next post will be "Do Hire by Ability to multiply numbers in your head", because that worked out well in practice. Or not. I liked the article and i think these kind of question are harder than they look. Demanding solutions is too much.

mattkrause 10y ago
Once place actually did ask me to square a number in my head. 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....

whack 10y ago

I think the real lesson is that you should be hiring on the basis of ability, not keywords/checkboxes. 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)

zer0gravity 10y ago

Ford said : "I fired all the experts because they always told me why things cannot be done". I call this dead knowledge. 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.

apinstein 10y ago

We just jumped down this rabbit-hole for a few weeks as we go through a hiring sprint. There's a consultant in this space that makes this exact argument -- Lou Adler -- and he's got the entire process spelled out in one of his books: https://www.amazon.com/Essential-Guide-Hiring-Getting-Hired-ebook/dp/B00B9JZMKE https://www.amazon.com/Essential-Guide-Hiring-Getting-Hired-... What's really cool about it as well is that he expects both the candidate and interviewer to read the same book. Pretty powerful.

kafkaesq 10y ago

Asking brain teasers and CS "fundamental" questions is fine as long as there is a good answer to those two question 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.

collyw 10y ago
Yes this annoys me these days. I was relatively good at these straight out of university. Now after 13 years of writing software I find my ability to do them is hit and miss. I do however write far better, more maintainable, cleaner software than I wrote straight out of university.