6 ms·

As a developer who has recently been through the hiring process, I think the problem is not a shortage of talent, but rather that companies are awful at hiring.

As a developer who has recently been through the hiring process, I think the problem is not a shortage of talent, but rather that companies are awful at hiring. Here are a few of the main issues: 1. Don't limit your potential talent pool to the miserable and the unemployed. In theory, any developer who is currently employed might be interested in leaving their job to work for you. Perhaps you will offer them more money, or perhaps a better quality of (work) life. However, most developers won't bother to talk to you if they already have a job. Why is that? Simple, if they do talk to you, you're going to offer them a homework assignment. You're going to tell them that it shouldn't take more than an hour, but it will actually take two full days to do right. Giving someone a homework assignment isn't a way to woo them away from their current job. So you are left with a candidate pool that consists mostly of people who are desperate enough that they have to agree to jump through your hoops (i.e. unemployed, miserable in their current job, etc.) 2. Don't discard capable people. The average interview begins with a remote code challenge whereby the candidate, who is probably nervous, has to pair program a completely contrived problem with a complete stranger watching them over a webcam. There are tons of developers who are good at coding solutions to real world problems in real world situations but simply don't perform well in this type of situation. This type of scenario is not really assessing a candidate's skills. It's assessing their familiarity with specific contrived interview problems and their ability to perform under duress. Of course, the points you raised are fair as well. Recruiters are not technical people, they are sales people. You will have to find a good recruiter. They are out there, you just have to find the right ones. But my point is, once you find the good recruiter(s) don't waste the human capital they can being to you by having a terrible interview process. Here is my advice. Once your recruiter has a handful of resumes you like, carve out half a days worth of 30-minute sessions to meet with them at the recruiter's office. Ask them about projects they've worked on. You'll find out much more about what they know and what they're like to work with than you would with the typical remote code challenge. One you narrow the pool down a bit bring them in for on-sites. Best of luck!

isaacaderogba 8y ago
This seems to align with my experience, particularly your first point. For context, I’m working as an Associate Product Manager (so not quite a Product Engineer) but I had applied for a job at a Start-up company that I found extremely interesting. Had an initial interview but didn’t hear back from the company for about a month. I had also sent follow up e-mails about this. When I eventually did hear back from them, they apologised for their delay but then spun me with a homework assignment that would have taken at least 2 days. Safe to say, I kindly declined. So yeah, really focus on how you’re recruiting for talent.
blizkreeg 8y ago
I'd like to talk more about (1). We do a homework assignment that in fact does takes a few hours, but only for candidates who don't have experience developing in our core stack. If you can code in the languages and frameworks we use, it's a step we bypass. It tells us if they can solve a problem well using the tools and setup of their choice. If we clearly see they did well at this, the on-site can then focus on the more non-coding aspect. Our on-site interviews are highly contextual and rooted in the real-world where candidates work directly in our codebase. They are reasonable in the things we ask candidates to do (re-factor something, review PRs, implement a small enhancement). If someone can't code in one of our core languages, it's a tougher assessment since we would have to resort to hypothetical/whiteboard crap (which we hate). How do you assess someone then? We recently had a candidate do a take-home where they didn't do well, and it did save 5-6h of everyone's time and their effort of coming in and being subject to the pressure of the interview. I'd love to hear counter-opinions on this.
- wool_gather 8y ago
  > If you can code in the languages and frameworks we use, it's a step we bypass. Curious; can you say more about how you judge this? Isn't that sort of the point of the homework in the first place?
  - blizkreeg 8y ago
    Judge if they can code in our core stack? Well, if they're working with it in their current job, or in side projects. Assessing if they are good, we can do it in the on-site. Like I said, our on-site is based on knowing our stack, so we have to make sure they can work with it before we bring them in.
    - karmakaze 8y ago
      What is this 'core stack' you speak of, is it special in some way? I once did an all day on-site pairing interview with Pivotal. The morning was Swift/iOS and afternoon was Java back-end. I didn't have experience in either except some Java desktop GUI from a while back. It was all fine, they wanted to see how I think, what code paths I think of, what tests I choose for coverage. The actual syntax of what's being written wasn't the main point. That translates quickly on the job from experience doing similar tasks in other environments. If on the other hand, you've never written a test, or discussed code with a colleague those are not as easy to pick up from somewhere else.
DelightOne 8y ago
> There are tons of developers who are good at coding solutions to real world problems in real world situations but simply don't perform well in this type of situation. What do you propose instead to see whether one can do real world problems in real world situations?
- 01100011 8y ago
  I think he's saying that normally a person isn't coding while someone is watching you. I have no problem implementing a data structure on my own but if you ask me to do it in 15 minutes while you're watching every typo I'll probably freeze up.
  - itronitron 8y ago
    Has anyone ever flipped the script in an interview, asking the interviewer if they can watch them write code at their workstation for an hour so they can get a sense of what it is like to work at the company?
- edhowzerblack 8y ago
  You can learn a lot about what a developer knows and is capable of by talking to them about the projects they worked on. Ask them detailed questions about the particular problems they dealt with on projects and how they were solved. Ask them to explain core concepts that are intrinsic to the technologies they've worked with. You can also get a feel for their personality this way. Remember, we're talking about a screening process. Once they come onsite for the real deal you can throw all sorts of stuff at them.
ebiester 8y ago
I got it! We will hire anyone who sounds good, and fire them within a month if it turns out they're not up to our standards. Then, we will ensure we never get anyone who isn't already employed and anyone just looking for a paycheck or three. If you heard that even 20% of people were fired within the first month, how likely would you be to take that job? Note: It's usually called contract to hire. And it just takes the interview stress and pushes it out to 1-6 months.
- akvadrako 8y ago
  So what? If you are used to freelancing, it's the same thing. I would prefer that 80% of people are fired in the first month.
  - abakker 8y ago
    Sure, but, most employees would not prefer that...its a Market for labor. You are buying, Labor is selling. If what you are buying is an employment contract with a penalty-free terminate-for-convenience clause, expect that you are buying that piece of insurance from the employee at a high cost.
    - ebiester 8y ago
      To be fair, we already have a penalty-free terminate for convenience in the US in most states, it is really social convention that prevents it.
- pllbnk 8y ago
  I don't have sufficient sample data from my personal experience, however, I conduct job interviews the same way I got interviewed and hired for my last job and my last three hires were and are really good teammates. I don't ask for coding problems and don't have a strict interview structure. Instead, I try to make a conversation about the candidate and tailor interview around their experience. I also try find similar problems they face that we have and talk about solutions that we apply which helps me see how flexible they are or do they outright reject different viewpoints. Ultimately, the main goal is finding the people that I would like working with because it trumps pure technical skills in importance. It might not work well where some highly specific and rare skills are required, however it works in average enterprise environment. The interviewer should be a pretty good conversationalist, though.
xemdetia 8y ago
In the US most of the recruiters I've been getting are more at least technically aware but still struggle because they are external. The only true people I have felt like I have had a useful conversation with are companies who have an in-house talent lead as they can generally describe what is going on and can fit you across teams. In my current role I was cross matched successfully and probably would not have pulled the trigger without the company based talent person involved in the process. The outside recruiting firms I have tried to work with have just been misery by comparison. They either don't know enough about what's going on or clearly don't even understand the position they are offering and it takes like 3 or 4 back and forths to get the real job description and it doesn't even make sense. From the other side once my current role started resourcing from an outside firm the matches were worse and worse and I wonder if it just was because the rep on the other side couldn't talk about our actual company in any meaningful way.
commandlinefan 8y ago
I'd estimate (without bothering to sit down and crunch the numbers) I've had a 30% success rate interviewing for programming jobs. I usually get about 2 rejections before I get an acceptance (and, of course, when I get accepted, I stop interviewing). Based on that, I'd be led to conclude that I was a _dismal_ programmer, probably not fit for the industry at all. If there was as tight a tech shortage as they keep insisting there is, I'd expect it would be pretty near impossible to be rejected for a programming job. Yet I find it happens to me with alarming regularity and based on what I read here, I'm not alone. It's almost as if the "talent shortage" is imaginary...
- fucking_tragedy 8y ago
  > It's almost as if the "talent shortage" is imaginary... Talent shortage means that employers can't find workers with the skills the claim they need at the price they want to pay.
- mikerah13 8y ago
  it is
- edhowzerblack 8y ago
  The talent shortage is absolutely imaginary. The hiring process is run by incompetent internal recruiters and competitive developers with Aspergers whose goal is to reject as many people as possible in order to prove that no one is as smart as they are.
- lordnacho 8y ago
  > (and, of course, when I get accepted, I stop interviewing) Then you only ever have a sequence of rejections ending with a job offer. Of course you will feel terrible if this is your strategy. Do a few more interviews and you'll find that sometimes you get two or three offers in a row.
misterkgb 8y ago
If (1) coding homework sucks, and (2) coding live sucks, how do you propose assessing a candidate's coding ability? Take their word for it? Absent a large open-source repository or other public corpus of work, you generally have to rely on one or the other.

isaacaderogba 8y ago

This seems to align with my experience, particularly your first point. For context, I’m working as an Associate Product Manager (so not quite a Product Engineer) but I had applied for a job at a Start-up company that I found extremely interesting. Had an initial interview but didn’t hear back from the company for about a month. I had also sent follow up e-mails about this. When I eventually did hear back from them, they apologised for their delay but then spun me with a homework assignment that would have taken at least 2 days. Safe to say, I kindly declined. So yeah, really focus on how you’re recruiting for talent.

blizkreeg 8y ago

I'd like to talk more about (1). We do a homework assignment that in fact does takes a few hours, but only for candidates who don't have experience developing in our core stack. If you can code in the languages and frameworks we use, it's a step we bypass. It tells us if they can solve a problem well using the tools and setup of their choice. If we clearly see they did well at this, the on-site can then focus on the more non-coding aspect. Our on-site interviews are highly contextual and rooted in the real-world where candidates work directly in our codebase. They are reasonable in the things we ask candidates to do (re-factor something, review PRs, implement a small enhancement). If someone can't code in one of our core languages, it's a tougher assessment since we would have to resort to hypothetical/whiteboard crap (which we hate). How do you assess someone then? We recently had a candidate do a take-home where they didn't do well, and it did save 5-6h of everyone's time and their effort of coming in and being subject to the pressure of the interview. I'd love to hear counter-opinions on this.

wool_gather 8y ago
> If you can code in the languages and frameworks we use, it's a step we bypass. Curious; can you say more about how you judge this? Isn't that sort of the point of the homework in the first place?
- blizkreeg 8y ago
  Judge if they can code in our core stack? Well, if they're working with it in their current job, or in side projects. Assessing if they are good, we can do it in the on-site. Like I said, our on-site is based on knowing our stack, so we have to make sure they can work with it before we bring them in.
  - karmakaze 8y ago
    What is this 'core stack' you speak of, is it special in some way? I once did an all day on-site pairing interview with Pivotal. The morning was Swift/iOS and afternoon was Java back-end. I didn't have experience in either except some Java desktop GUI from a while back. It was all fine, they wanted to see how I think, what code paths I think of, what tests I choose for coverage. The actual syntax of what's being written wasn't the main point. That translates quickly on the job from experience doing similar tasks in other environments. If on the other hand, you've never written a test, or discussed code with a colleague those are not as easy to pick up from somewhere else.

DelightOne 8y ago

> There are tons of developers who are good at coding solutions to real world problems in real world situations but simply don't perform well in this type of situation. What do you propose instead to see whether one can do real world problems in real world situations?

01100011 8y ago
I think he's saying that normally a person isn't coding while someone is watching you. I have no problem implementing a data structure on my own but if you ask me to do it in 15 minutes while you're watching every typo I'll probably freeze up.
- itronitron 8y ago
  Has anyone ever flipped the script in an interview, asking the interviewer if they can watch them write code at their workstation for an hour so they can get a sense of what it is like to work at the company?
edhowzerblack 8y ago
You can learn a lot about what a developer knows and is capable of by talking to them about the projects they worked on. Ask them detailed questions about the particular problems they dealt with on projects and how they were solved. Ask them to explain core concepts that are intrinsic to the technologies they've worked with. You can also get a feel for their personality this way. Remember, we're talking about a screening process. Once they come onsite for the real deal you can throw all sorts of stuff at them.

ebiester 8y ago

I got it! We will hire anyone who sounds good, and fire them within a month if it turns out they're not up to our standards. Then, we will ensure we never get anyone who isn't already employed and anyone just looking for a paycheck or three. If you heard that even 20% of people were fired within the first month, how likely would you be to take that job? Note: It's usually called contract to hire. And it just takes the interview stress and pushes it out to 1-6 months.

akvadrako 8y ago
So what? If you are used to freelancing, it's the same thing. I would prefer that 80% of people are fired in the first month.
- abakker 8y ago
  Sure, but, most employees would not prefer that...its a Market for labor. You are buying, Labor is selling. If what you are buying is an employment contract with a penalty-free terminate-for-convenience clause, expect that you are buying that piece of insurance from the employee at a high cost.
  - ebiester 8y ago
    To be fair, we already have a penalty-free terminate for convenience in the US in most states, it is really social convention that prevents it.
pllbnk 8y ago
I don't have sufficient sample data from my personal experience, however, I conduct job interviews the same way I got interviewed and hired for my last job and my last three hires were and are really good teammates. I don't ask for coding problems and don't have a strict interview structure. Instead, I try to make a conversation about the candidate and tailor interview around their experience. I also try find similar problems they face that we have and talk about solutions that we apply which helps me see how flexible they are or do they outright reject different viewpoints. Ultimately, the main goal is finding the people that I would like working with because it trumps pure technical skills in importance. It might not work well where some highly specific and rare skills are required, however it works in average enterprise environment. The interviewer should be a pretty good conversationalist, though.

xemdetia 8y ago

In the US most of the recruiters I've been getting are more at least technically aware but still struggle because they are external. The only true people I have felt like I have had a useful conversation with are companies who have an in-house talent lead as they can generally describe what is going on and can fit you across teams. In my current role I was cross matched successfully and probably would not have pulled the trigger without the company based talent person involved in the process. The outside recruiting firms I have tried to work with have just been misery by comparison. They either don't know enough about what's going on or clearly don't even understand the position they are offering and it takes like 3 or 4 back and forths to get the real job description and it doesn't even make sense. From the other side once my current role started resourcing from an outside firm the matches were worse and worse and I wonder if it just was because the rep on the other side couldn't talk about our actual company in any meaningful way.

commandlinefan 8y ago

I'd estimate (without bothering to sit down and crunch the numbers) I've had a 30% success rate interviewing for programming jobs. I usually get about 2 rejections before I get an acceptance (and, of course, when I get accepted, I stop interviewing). Based on that, I'd be led to conclude that I was a _dismal_ programmer, probably not fit for the industry at all. If there was as tight a tech shortage as they keep insisting there is, I'd expect it would be pretty near impossible to be rejected for a programming job. Yet I find it happens to me with alarming regularity and based on what I read here, I'm not alone. It's almost as if the "talent shortage" is imaginary...

fucking_tragedy 8y ago
> It's almost as if the "talent shortage" is imaginary... Talent shortage means that employers can't find workers with the skills the claim they need at the price they want to pay.
mikerah13 8y ago
it is
edhowzerblack 8y ago
The talent shortage is absolutely imaginary. The hiring process is run by incompetent internal recruiters and competitive developers with Aspergers whose goal is to reject as many people as possible in order to prove that no one is as smart as they are.
lordnacho 8y ago
> (and, of course, when I get accepted, I stop interviewing) Then you only ever have a sequence of rejections ending with a job offer. Of course you will feel terrible if this is your strategy. Do a few more interviews and you'll find that sometimes you get two or three offers in a row.

misterkgb 8y ago

If (1) coding homework sucks, and (2) coding live sucks, how do you propose assessing a candidate's coding ability? Take their word for it? Absent a large open-source repository or other public corpus of work, you generally have to rely on one or the other.