8 ms·

> What’s the biggest challenge when hiring talent? "Hard to assess skills before onsite" -- That's funny, I've never had a hiring manager or interviewer look a

by dvt 9y ago

> What’s the biggest challenge when hiring talent? "Hard to assess skills before onsite" -- That's funny, I've never had a hiring manager or interviewer look at my literal hundreds of thousands of lines of code on GitHub or several of the OSS projects I've contributed to. Not to mention the actual book I co-wrote.

booleandilemma 9y ago
Recruiter: “How many hours a day would you say you use Meteor?”
- expertentipp 9y ago
  Doesn't matter because you probably have experience in the wrong version of it anyway.
onion2k 9y ago
I can think of a dozen reasons for that, but here are a few of the most salient ones; 1. Reading and evaluating code in an unfamiliar context is really £@#&ing hard, especially on a complex project. Understanding someone's commits requires knowledge of the project as a whole, the problem space, the environment, etc. That's not possible to do for a large number of candidates. It might not give you a very good insight in to an applicant. 2. Most people's public code is of roughly equal quality (eg 'not great'). You can't really differentiate between people well based on it. What people do in their spare time for fun is rarely commented/tested/documented/etc, so it's a bad way to evaluate their skill level. If you find someone with good public code that's a great sign, but a hiring manager who's looked at 100 Github profiles and found zero good ones might reasonably have given up looking. Also it could be seen as a discriminatory factor; if you think public code is important you're going to overlook people with little time to write any, eg those with families, care responsibilities, interests outside of coding. Building a great team is about hiring great people more that just great developers. 3. It's hard to trust someone's public code. It's trivial to clone a few open projects and take credit for the work, and a hiring manager doesn't have the time to dig in to everyone's projects to see if they've ripped the work off from somewhere. Also, you may have dealt with 50 hiring managers who have never looked at your public code in your career so far. That isn't very many really. I certainly wish there was a better way to evaluate developers skill, and as someone who has plenty of public work on Github I think it'd be great if that was a good starting point, but I don't think it's quite good enough yet. I can certainly see why hiring managers don't look there.
- dvt 9y ago
  > It might not give you a very good insight in to an applicant. I'd argue pointless whiteboard trivia doesn't give you good insight into an applicant, either. And yet, 90% of companies do it. > Most people's public code is of roughly equal quality (eg 'not great'). I disagree with this. Unless you're looking at a toy or unfinished project, most code that's released (on npm, maven, or something similar) is actually fairly high quality. Certainly higher quality than what I've had to work with in production systems that were making millions of dollars a month. > Building a great team is about hiring great people more that just great developers. I completely agree. So why do we dehumanize potential hires with standard practices that involve (for example) memorizing algorithms you'll never use? I mean, HackerRank is a testament to how awful our culture is. Is there a DoctorRank or SecurityGuardRank or WaiterRank? > It's hard to trust someone's public code. I think this is complete BS. There's people much smarter than me that are getting screwed by these terrible practices. Max Howell, Homebrew's author, was famously rejected by Google for not passing some stupid whiteboard exam, when just about everyone at Google actually uses the software he authored.
  - onion2k 9y ago
    I'd argue pointless whiteboard trivia doesn't give you good insight into an applicant, either. And yet, 90% of companies do it. The fact that some companies use bad practises for hiring doesn't change how hard it is to judge someone's code from their Github repo. I agree that whiteboard tests are horrible, but switching to a different bad idea wouldn't help. Unless you're looking at a toy or unfinished project, most code that's released (on npm, maven, or something similar) is actually fairly high quality. Certainly higher quality than what I've had to work with in production systems that were making millions of dollars a month. You're moving the goal posts from "Has code in public" to "Launched, contributed to, or otherwise involved with a successful open project." That's quite different, and arguably a lot of hiring managers do look at that sort of thing very favourably. I think this is complete BS. There's people much smarter than me that are getting screwed by these terrible practices. Max Howell, Homebrew's author, was famously rejected by Google for not passing some stupid whiteboard exam, when just about everyone at Google actually uses the software he authored. I'll defer to Max's own explanation for that: https://www.quora.com/Whats-the-logic-behind-Google-rejecting-Max-Howell-the-author-of-Homebrew-for-not-being-able-to-invert-a-binary-tree/answer/Max-Howell?share=100e0bb6&srid=x8w https://www.quora.com/Whats-the-logic-behind-Google-rejectin... As he says himself, Homebrew is a successful product but not necessarily great computer science. He 'failed' a computer science question. We can question whether or not Google needed to ask that in the interview, but they clearly thought it was important enough for the role Max was applying for to ask it. So maybe rejecting him for that role was the right decision. We don't really know. We do know that he wasn't applying to Google for the job of "Homebrew Maintainer" so his work on Homebrew, while really impressive, isn't really the whole story in hiring him. Surely you're not suggesting that the author of a successful project should be able to walk in to any developer role regardless of what's needed to do the job?
Sir_Cmpwn 9y ago
If I had a dollar for every time a recruiter has asked me to complete a code challenge within 5 minutes of my last push to GitHub, I wouldn't need to work anyway!
im_down_w_otp 9y ago
I have never understood the point of HackerRank. I even got into it with fairly high-up executives at my last job for refusing to fall in-line and use it as a tool. As far as I'm concerned all it does is exacerbate the already terrible hiring practices and hiring biases that plague the software industry. I'm now CTO of a company operating a space that's as challenging as it is esoteric. We make hardware for adding by-wire controls to some existing cars to do autonomous vehicle test/validation. We make high-fidelity, high-bandwidth data capture software for AV sensor mules. We're working on a SDLC that enforces cryptographic chain of custody and produces safety-certification evidence as a continuous delivery artifact, and we're working on a high-assurance runtime environment for AV applications. Hiring for this diversity of internal & external products would appear to be extremely challenging, but reforming/growing the existing teams and building new teams has proven fairly easy. Insofar as quality of new hires, productivity & growth of realigned staff, etc. is concerned. The challenge was in all the preparation it took to make it easy. 1. I never hire until I am absolutely certain I can identify and articulate a very specific need that aligns with a very specific set of goals. 2. I never hire until I am absolutely certain I understand the responsibilities and level of ownership required to meet those goals. 3. I never hire until I have a meaningful frontier set of models for the personality profiles (fallabilty acknowledged) that are likely to align with both those responsibilities and of the people they'll work most closely with. 4. I have candidates pair with someone or someones they'd actually work with on an actual problem being actively worked on by the team. Why contrive a pointless artifice like programmer-trivia---to guess at what the person would be like on the team---when I can make them an honorary member of their actual future team for a couple hours on-site or over video/screenshare? 5. I don't try to get a bargain on my hires. If I've managed to do all the above, then I know what I need, I know what it's worth, and I know how I need to manage my financial constraints. This is my problem with things like HackerRank. It's just a thing that hiring managers can hide behind as a kind of faux-rigor to produce a completely meaningless "score" as though such a complex thing can be distilled down into a single number and used as some common metric for comparison. Hiring is too important to the company, the team, and ultimately the candidate---whose livelihood you now partially hold in your hand---to be so fundamentally lazy about it.
- plinkplonk 9y ago
expertentipp 9y ago
> That's funny, I've never had a hiring manager or interviewer look at my literal hundreds of thousands of lines of code on GitHub or several of the OSS projects I've contributed to. I was thinking, since public repositories or open source contributions are the new "mandatory". If you want to see me coding, just request a new feature to one of my public repositories on github. These coding assignment you sent by email? I don't even bother to read them, in fact I store them scrupulously together with your email - once you might be looking for a job and I will be the one doing hiring.
akerro 9y ago
In the last two years I got more and more questions to describe my professional projects and provide links to opensource project - that was a requirement.
scarface74 9y ago
I've never written a line of publicly accessible code in my life, I've been working for 20+ years and I rarely fail at getting an offer for a job I apply for. Then again, I don't submit resumes blindly. I always go through recruiters, that has more to do with my hit rate than my skill set. Let me take that back. I got my first development job in college from another school about 100 miles away because he saw a HyperCard Eliza clone I wrote and posted on AOL back in 1993.
bryanrasmussen 9y ago
I have an anecdote somewhere here about a developer I recommended hiring on our startup while I was off doing consulting work who was competent and basically ruined the company and destroyed a couple years worth of work because he knew how stuff just had to be. I recommended hiring him based on a github profile.

by dvt 9y ago

booleandilemma 9y ago

Recruiter: “How many hours a day would you say you use Meteor?”

expertentipp 9y ago
Doesn't matter because you probably have experience in the wrong version of it anyway.

onion2k 9y ago

I can think of a dozen reasons for that, but here are a few of the most salient ones; 1. Reading and evaluating code in an unfamiliar context is really £@#&ing hard, especially on a complex project. Understanding someone's commits requires knowledge of the project as a whole, the problem space, the environment, etc. That's not possible to do for a large number of candidates. It might not give you a very good insight in to an applicant. 2. Most people's public code is of roughly equal quality (eg 'not great'). You can't really differentiate between people well based on it. What people do in their spare time for fun is rarely commented/tested/documented/etc, so it's a bad way to evaluate their skill level. If you find someone with good public code that's a great sign, but a hiring manager who's looked at 100 Github profiles and found zero good ones might reasonably have given up looking. Also it could be seen as a discriminatory factor; if you think public code is important you're going to overlook people with little time to write any, eg those with families, care responsibilities, interests outside of coding. Building a great team is about hiring great people more that just great developers. 3. It's hard to trust someone's public code. It's trivial to clone a few open projects and take credit for the work, and a hiring manager doesn't have the time to dig in to everyone's projects to see if they've ripped the work off from somewhere. Also, you may have dealt with 50 hiring managers who have never looked at your public code in your career so far. That isn't very many really. I certainly wish there was a better way to evaluate developers skill, and as someone who has plenty of public work on Github I think it'd be great if that was a good starting point, but I don't think it's quite good enough yet. I can certainly see why hiring managers don't look there.

dvt 9y ago
> It might not give you a very good insight in to an applicant. I'd argue pointless whiteboard trivia doesn't give you good insight into an applicant, either. And yet, 90% of companies do it. > Most people's public code is of roughly equal quality (eg 'not great'). I disagree with this. Unless you're looking at a toy or unfinished project, most code that's released (on npm, maven, or something similar) is actually fairly high quality. Certainly higher quality than what I've had to work with in production systems that were making millions of dollars a month. > Building a great team is about hiring great people more that just great developers. I completely agree. So why do we dehumanize potential hires with standard practices that involve (for example) memorizing algorithms you'll never use? I mean, HackerRank is a testament to how awful our culture is. Is there a DoctorRank or SecurityGuardRank or WaiterRank? > It's hard to trust someone's public code. I think this is complete BS. There's people much smarter than me that are getting screwed by these terrible practices. Max Howell, Homebrew's author, was famously rejected by Google for not passing some stupid whiteboard exam, when just about everyone at Google actually uses the software he authored.
- onion2k 9y ago
  I'd argue pointless whiteboard trivia doesn't give you good insight into an applicant, either. And yet, 90% of companies do it. The fact that some companies use bad practises for hiring doesn't change how hard it is to judge someone's code from their Github repo. I agree that whiteboard tests are horrible, but switching to a different bad idea wouldn't help. Unless you're looking at a toy or unfinished project, most code that's released (on npm, maven, or something similar) is actually fairly high quality. Certainly higher quality than what I've had to work with in production systems that were making millions of dollars a month. You're moving the goal posts from "Has code in public" to "Launched, contributed to, or otherwise involved with a successful open project." That's quite different, and arguably a lot of hiring managers do look at that sort of thing very favourably. I think this is complete BS. There's people much smarter than me that are getting screwed by these terrible practices. Max Howell, Homebrew's author, was famously rejected by Google for not passing some stupid whiteboard exam, when just about everyone at Google actually uses the software he authored. I'll defer to Max's own explanation for that: https://www.quora.com/Whats-the-logic-behind-Google-rejecting-Max-Howell-the-author-of-Homebrew-for-not-being-able-to-invert-a-binary-tree/answer/Max-Howell?share=100e0bb6&srid=x8w https://www.quora.com/Whats-the-logic-behind-Google-rejectin... As he says himself, Homebrew is a successful product but not necessarily great computer science. He 'failed' a computer science question. We can question whether or not Google needed to ask that in the interview, but they clearly thought it was important enough for the role Max was applying for to ask it. So maybe rejecting him for that role was the right decision. We don't really know. We do know that he wasn't applying to Google for the job of "Homebrew Maintainer" so his work on Homebrew, while really impressive, isn't really the whole story in hiring him. Surely you're not suggesting that the author of a successful project should be able to walk in to any developer role regardless of what's needed to do the job?

Sir_Cmpwn 9y ago

If I had a dollar for every time a recruiter has asked me to complete a code challenge within 5 minutes of my last push to GitHub, I wouldn't need to work anyway!

im_down_w_otp 9y ago

I have never understood the point of HackerRank. I even got into it with fairly high-up executives at my last job for refusing to fall in-line and use it as a tool. As far as I'm concerned all it does is exacerbate the already terrible hiring practices and hiring biases that plague the software industry. I'm now CTO of a company operating a space that's as challenging as it is esoteric. We make hardware for adding by-wire controls to some existing cars to do autonomous vehicle test/validation. We make high-fidelity, high-bandwidth data capture software for AV sensor mules. We're working on a SDLC that enforces cryptographic chain of custody and produces safety-certification evidence as a continuous delivery artifact, and we're working on a high-assurance runtime environment for AV applications. Hiring for this diversity of internal & external products would appear to be extremely challenging, but reforming/growing the existing teams and building new teams has proven fairly easy. Insofar as quality of new hires, productivity & growth of realigned staff, etc. is concerned. The challenge was in all the preparation it took to make it easy. 1. I never hire until I am absolutely certain I can identify and articulate a very specific need that aligns with a very specific set of goals. 2. I never hire until I am absolutely certain I understand the responsibilities and level of ownership required to meet those goals. 3. I never hire until I have a meaningful frontier set of models for the personality profiles (fallabilty acknowledged) that are likely to align with both those responsibilities and of the people they'll work most closely with. 4. I have candidates pair with someone or someones they'd actually work with on an actual problem being actively worked on by the team. Why contrive a pointless artifice like programmer-trivia---to guess at what the person would be like on the team---when I can make them an honorary member of their actual future team for a couple hours on-site or over video/screenshare? 5. I don't try to get a bargain on my hires. If I've managed to do all the above, then I know what I need, I know what it's worth, and I know how I need to manage my financial constraints. This is my problem with things like HackerRank. It's just a thing that hiring managers can hide behind as a kind of faux-rigor to produce a completely meaningless "score" as though such a complex thing can be distilled down into a single number and used as some common metric for comparison. Hiring is too important to the company, the team, and ultimately the candidate---whose livelihood you now partially hold in your hand---to be so fundamentally lazy about it.

plinkplonk 9y ago

expertentipp 9y ago

> That's funny, I've never had a hiring manager or interviewer look at my literal hundreds of thousands of lines of code on GitHub or several of the OSS projects I've contributed to. I was thinking, since public repositories or open source contributions are the new "mandatory". If you want to see me coding, just request a new feature to one of my public repositories on github. These coding assignment you sent by email? I don't even bother to read them, in fact I store them scrupulously together with your email - once you might be looking for a job and I will be the one doing hiring.

akerro 9y ago

In the last two years I got more and more questions to describe my professional projects and provide links to opensource project - that was a requirement.

scarface74 9y ago

I've never written a line of publicly accessible code in my life, I've been working for 20+ years and I rarely fail at getting an offer for a job I apply for. Then again, I don't submit resumes blindly. I always go through recruiters, that has more to do with my hit rate than my skill set. Let me take that back. I got my first development job in college from another school about 100 miles away because he saw a HyperCard Eliza clone I wrote and posted on AOL back in 1993.

bryanrasmussen 9y ago

I have an anecdote somewhere here about a developer I recommended hiring on our startup while I was off doing consulting work who was competent and basically ruined the company and destroyed a couple years worth of work because he knew how stuff just had to be. I recommended hiring him based on a github profile.