13 ms·

> "I’m writing this as an interviewee, having never been on the other side of the interview table ..." > ... > "Most candidates will have side-projects or wor

> "I’m writing this as an interviewee, having never been on the other side of the interview table ..." > ... > "Most candidates will have side-projects or work they’ve done for previous employers." As someone who has actually done a lot of interviewing, I can say with great confidence that this is simply wrong. At my current employer, we have a "homework assignment" as part of the interview process. We tell candidates that they can point us at an existing project of theirs instead of doing the homework. Few people take us up on this because few applicants have any substantial public side projects or FOSS work they can share. And sharing "work they've done for previous employers" is a great way to court legal trouble. They shouldn't share it and as an interviewer I don't want to see it!

deleted 6y ago
[deleted]
nogabebop23 6y ago
We use a coding challenge as well but I like your addition of "auditing" the coding part and using existing open source or side project work. Bonus points if it uses some of the target technologies too! The author doesn't appear to understand the economics of the hiring company; it's about time & effort to filter and the cost of making a bad hire. I cannot give every application 1-2 hours of review if I get 100+ resumes. I can't give every interviewee a half-day assessment to get the very poor signal/noise ratio answers to questioning methods suggested. I can't hire easy and then fire easy. I can't invest weeks of work from myself and other mentors on non-ideal potentials. I know this means I pass over great candidates and that really sucks and is totally unfair. I'm sure that's happended to me as well. The problem is nothing presented here is a better alternative.
- _qulr 6y ago
  > I cannot give every application 1-2 hours of review if I get 100+ resumes. This is perhaps the biggest misconception of hiring, that out of some misguided notion of "fairness" or "objectivity" you have to treat every candidate exactly the same. In theory it seems like a good principle, but the road to hell is paved in good intentions. In practice, this results in arbitrarily designed standard tests which are only superficially fair, and systematically weed out people who aren't good at test taking or auditions. Go through all the resumes quickly, pick out the top candidates, and start from the top! Focus most of your time on researching your few top candidates, and if one of them seems good, then hire them, and end your hiring process. You may only have to interview 1, 2, maybe 3 people at most. This saves everyone time: your own time, and the time of the 100+ people who would otherwise be interviewed and rejected, because there's only 1 job opening. Obviously if you interview your top candidates, and you find them lacking, then keep working your way down the stack. But going through the entire stack of candidates is a huge waste of time, a pointless exercise, totally counterproductive. Don't do "screening" interviews. Only do "hiring" interviews.
  - salt-licker 6y ago
    Generally you don’t get all the resumes at once, this is literally the secretary problem. Unfortunately you need some objective standard of measurement across candidates that is static over at least months, and ideally takes a minimum of you and your candidates’ time. Though imperfect, real-time technical questions are a pretty good solution to this problem, especially since a lot of the best engineers prefer them to take-homes. Also, anecdotally after interviewing hundreds of candidates, I’ve found resumes to have a relatively high false positive rate. Surprising numbers of engineers look great on paper but can’t write working code for semi-complex problems when tested, even accounting for interview anxiety.
    - _qulr 6y ago
      > Surprising numbers of engineers look great on paper but can’t write working code when tested, even accounting for interview anxiety. How have you accounted for interview anxiety?
      - salt-licker 6y ago
        It’s definitely not an exact science. 1. I try to make the parameters of the interview as friendly as possible — language of their choice, don’t have to worry about code style or computational complexity, or talk while they’re coding, just write working code that solves the problem. They can use google freely. I’m there as a resource to talk through their solution, answer questions, and help them get unstuck if needed. 2. The algorithm to solve the question doesn’t require a trick and there are many viable solutions so most candidates can verbally explain to me a working algorithm quickly, +- a couple edge cases. 3. Candidates often get visibly flustered or hung up on irrelevant details, or unsure what exactly I want for them, and I focus on noticing this. I try to guide them down a correct path if they’re close and tell them not to over-architect if they start doing that. Despite all this, too manly candidates do not have a dependable metaprocess for writing working code - a common scenario is they write code, it gives the wrong result, they drop some print statements to debug, but can’t effectively trace the program to figure out why they’re getting the debug output and so they guess and try to fix the wrong thing, causing further problems. I know that some of this is nerves but it can’t account for all of it.
- pavel_lishin 6y ago
  The commenter doesn't appear to understand the economics of the job-seeking candidate; it's about time & effort to keep your current job and the cost of getting hired at a bad company. I cannot give every company I apply at hours of coding if I apply to dozens of jobs. I can't give every company a half-day assessment. I can't get hired easily and then get fired easily. I can't invest weeks of work from myself on non-ideal potentials. I know this means I pass on great jobs and that really sucks and is totally unfair. I'm sure that's happened to me as well. The problem is that nothing presented here is a better alternative.
  - 1123581321 6y ago
    This is a snarky parody, but put together you are both just saying that you can only afford to spend any time on job matches likely to be especially good, but that you’ll spend a lot of time on the good ones. Which just means you both are in an illiquid or conservative hiring market that is out of your control and their control to change.
- Clubber 6y ago
  >I can't hire easy and then fire easy. Why not? Maybe you should address that problem. It would certainly make things a lot easier.
- jjav 6y ago
  > I cannot give every application 1-2 hours of review if I get 100+ resumes. Your process has already failed if you're considering 100+ people! First, you should never be getting 100+ resumes for a role. If you are, you need to write better job descriptions and/or get a better recruiter who knows how to match to the job description. With that in place, you (I) are getting about 10-20 resumes at most. Then what I do is read them and rank them. Takes less than two hours. I'll only interview the top five from this stack. I'm happy to give each of these five people however many hours of attention it takes, they and I deserve it. This way the people who didn't get to the interview round have not wasted any of their time which is the most respectful way to handle it.
  - _qulr 6y ago
    > you need to write better job descriptions Tech job postings are the absolute worst. Anyone who's having trouble with hiring in any way needs to start there. Everyone in tech knows that job postings are a joke, which is why you're told to apply to jobs even if you're not qualified, and then companies complain about the applicant pool. It's their own fault! The "excuse" is almost always "HR". But this just tells the applicant your company is a bureaucratic nightmare that few sane applicants would want to join.
    - _qulr 6y ago
      There's a lot of worry in tech hiring about the "faker", the engineer who lies or exaggerates on their résumé. The irony is that the tech hiring process, especially the job postings, encourage the fakers to apply. You're practically beginning fakers to apply. The most honest, scrupulous people tend to only apply for jobs where they're 100% qualified according to the job posting. So the system, which hires people who don't actually meet the listed qualifications, is systematically selecting against the honest applicants. Honest people can even be driven out of tech in virtue of being honest.
  - autarch 6y ago
    > Your process has already failed if you're considering 100+ people! Remote roles get a _lot_ more applications than on site. In my experience getting 100 applications is quite common for such a role.
- goatinaboat 6y ago
  The author doesn't appear to understand the economics of the hiring company; it's about time & effort to filter and the cost of making a bad hire. I cannot give every application 1-2 hours of review if I get 100+ resumes. This is an entirely self-created problem, not for you personally, I mean for the industry. We are against "credentialling" so signals like personal recommendations, alma mater, or work history at prestigious firms are overlooked. My employer tried Hackerrank for a while, we abandoned it when we realised that the candidates we really wanted (e.g. based on personal recommendations from existing employees) were dropping out of the pipeline as soon as the Hackerrank link was sent to them. And the ones we were getting were good at Hackerrank and not much else.
lhorie 6y ago
I'd say "work they've done for previous employers" is something that nearly every candidate with industry experience has. The problem is that when I ask about it, candidates often are terrible at communicating what the work consisted of: often they focus on microscopic minutiae that appears disconnected from the big picture (e.g. gloating about gluing some trivial library as if that's a big accomplishment, when the position is for a senior engineer) or they demonstrate apathy/lack of proactiveness (e.g. some variation of "I just did what I was told") or they ramble incoherently, etc. And this is supposed to be one of those bog-standard question that interviewees are always told by job interview guides to be prepared for! I agree that people that have OSS work to show are much rarer to come by, and FWIW, they tend to do better in interviews IME. My theory is that it's not that the OSS resume bullet point itself sets them apart, but rather that they polished their skills more through the hard work they put into their OSS projects.
- autarch 6y ago
  Just to clarify, I thought the author of the linked piece was suggesting that people could share actual code from previous employers somehow. Of course it's reasonable to ask people about their past work in an interview and to expect them to speak about it coherently.
  - lhorie 6y ago
    I think OP did suggest sharing actual work, which would make sense if said work consists of e.g. semantic html that can be looked at in a publicly accessible site. Obviously sharing backend trade secrets would be a big no-no. I've had people say they can't talk about their work due to NDAs, and that's completely fine in my books. We just move on to another topic. FWIW, even when a candidate mentions having an OSS project, I refrain from looking at the actual code, and especially doing code review. I don't consider an interview setting the appropriate place to be grilling people on why they used a while loop instead of a for loop or whatever, since a) nearly everyone writes "bad" code occasionally and b) often things are done in certain ways for some good reason that isn't really relevant to my goal of evaluating the candidate. At the end of the day, the interviewer's goal IMHO should be to get as many signals they can from the conversation and make a determination about whether the candidate meets/exceeds a minimum threshold of competence
johnfn 6y ago
Them: "We've got a coding challenge for you..." Me: "I've got this repo on Github with millions of downloads and 10k stars. It's at least 20k lines of my own code. Would that be good to demonstrate my coding ability?" Them: "Haha, no, that'd be too much work for us. Please do the test instead." Me: "Fine." Then they rejected me because I used GET instead of POST. Clearly that shows I have no idea how to code. That was a large (1000+ employee) YC company, by the way.
- dmitryminkovsky 6y ago
  Truly absurd. Followed the link in your profile. You wrote VSCodeVim! 49,674++/14,291--. And because you used the "wrong" HTTP verb. Did they also say you should have used tabs instead of spaces?? Outrageous. By the way, thanks for VCCodeVim!
  - johnfn 6y ago
    Hah! Thanks :-)
- deleted 6y ago
  [deleted]
- golergka 6y ago
  > Then they rejected me because I used GET instead of POST. OK, I'm honestly curious here. What was the request, and why did you make such a decision? Do you think it is the right approach in this case, or that it's an insignificant mistake that does not represent a person's understanding of HTTP protocol? I remember hearing about at least one story where using GET instead of POST lead to disastrous consequences, as some robot crawled all over the "delete" links - but I have to admit, I can't imagine how it would happen without other significant design flaws happening as well (as "delete" links being public or robot being able to crawl under authenticated user's identity). This sounds like an error that can cause irrational irritation by the reviewer, but I can't imagine it being the sole reason to decide that the author can't code.
  - hysan 6y ago
zapt02 6y ago
This is on-point! I've been involved in the recruitment process at my current employer for years and 95% of people that make it past the initial recruiter meet-and-greet have absolutely nothing to show in terms of open-source contributions or personal projects. Most of them just do the homework assignment so that you can at least talk about something during the interview. You can always say it's because the company doesn't attract good enough candidates, but good luck with that in a competitive dev market in a large european capital. I appreciate the authors honesty in his obliviousness of being on "the other side of the table" and I think it's clear that the author is living in a bubble that doesn't correspond to reality for people recruiting.
- itsdrewmiller 6y ago
  fyi the author is female - https://css-irl.info/about/ https://css-irl.info/about/.
chrisfosterelli 6y ago
We've done something similar and found even candidates that do have public side projects may not feel those projects fully represent the code they'd write today and preferred the takehome.
- autarch 6y ago
  Good point. I'm sure some of the candidates who do our assignment have stuff on GitHub or elsewhere, but thought they could do better work with the assignment.
adamvalve 6y ago
Came here to share the same exact points. He’s making a lot of assumptions never being on the other side and actually interviewing lots of candidates. Most of the time I get half assed projects with bugs that are obvious and they haven’t ever made contributions to open source software as an alternative to the take home project. I think the at home project is the most lenient way to test someone because they aren’t pressured to solve a problem on the spot, instead they are in the comfort of their own home and can reference whatever documentation they would need, just like they would in a real position.

deleted 6y ago

[deleted]

nogabebop23 6y ago

We use a coding challenge as well but I like your addition of "auditing" the coding part and using existing open source or side project work. Bonus points if it uses some of the target technologies too! The author doesn't appear to understand the economics of the hiring company; it's about time & effort to filter and the cost of making a bad hire. I cannot give every application 1-2 hours of review if I get 100+ resumes. I can't give every interviewee a half-day assessment to get the very poor signal/noise ratio answers to questioning methods suggested. I can't hire easy and then fire easy. I can't invest weeks of work from myself and other mentors on non-ideal potentials. I know this means I pass over great candidates and that really sucks and is totally unfair. I'm sure that's happended to me as well. The problem is nothing presented here is a better alternative.

_qulr 6y ago
> I cannot give every application 1-2 hours of review if I get 100+ resumes. This is perhaps the biggest misconception of hiring, that out of some misguided notion of "fairness" or "objectivity" you have to treat every candidate exactly the same. In theory it seems like a good principle, but the road to hell is paved in good intentions. In practice, this results in arbitrarily designed standard tests which are only superficially fair, and systematically weed out people who aren't good at test taking or auditions. Go through all the resumes quickly, pick out the top candidates, and start from the top! Focus most of your time on researching your few top candidates, and if one of them seems good, then hire them, and end your hiring process. You may only have to interview 1, 2, maybe 3 people at most. This saves everyone time: your own time, and the time of the 100+ people who would otherwise be interviewed and rejected, because there's only 1 job opening. Obviously if you interview your top candidates, and you find them lacking, then keep working your way down the stack. But going through the entire stack of candidates is a huge waste of time, a pointless exercise, totally counterproductive. Don't do "screening" interviews. Only do "hiring" interviews.
- salt-licker 6y ago
  Generally you don’t get all the resumes at once, this is literally the secretary problem. Unfortunately you need some objective standard of measurement across candidates that is static over at least months, and ideally takes a minimum of you and your candidates’ time. Though imperfect, real-time technical questions are a pretty good solution to this problem, especially since a lot of the best engineers prefer them to take-homes. Also, anecdotally after interviewing hundreds of candidates, I’ve found resumes to have a relatively high false positive rate. Surprising numbers of engineers look great on paper but can’t write working code for semi-complex problems when tested, even accounting for interview anxiety.
  - _qulr 6y ago
    > Surprising numbers of engineers look great on paper but can’t write working code when tested, even accounting for interview anxiety. How have you accounted for interview anxiety?
    - salt-licker 6y ago
      It’s definitely not an exact science. 1. I try to make the parameters of the interview as friendly as possible — language of their choice, don’t have to worry about code style or computational complexity, or talk while they’re coding, just write working code that solves the problem. They can use google freely. I’m there as a resource to talk through their solution, answer questions, and help them get unstuck if needed. 2. The algorithm to solve the question doesn’t require a trick and there are many viable solutions so most candidates can verbally explain to me a working algorithm quickly, +- a couple edge cases. 3. Candidates often get visibly flustered or hung up on irrelevant details, or unsure what exactly I want for them, and I focus on noticing this. I try to guide them down a correct path if they’re close and tell them not to over-architect if they start doing that. Despite all this, too manly candidates do not have a dependable metaprocess for writing working code - a common scenario is they write code, it gives the wrong result, they drop some print statements to debug, but can’t effectively trace the program to figure out why they’re getting the debug output and so they guess and try to fix the wrong thing, causing further problems. I know that some of this is nerves but it can’t account for all of it.
pavel_lishin 6y ago
The commenter doesn't appear to understand the economics of the job-seeking candidate; it's about time & effort to keep your current job and the cost of getting hired at a bad company. I cannot give every company I apply at hours of coding if I apply to dozens of jobs. I can't give every company a half-day assessment. I can't get hired easily and then get fired easily. I can't invest weeks of work from myself on non-ideal potentials. I know this means I pass on great jobs and that really sucks and is totally unfair. I'm sure that's happened to me as well. The problem is that nothing presented here is a better alternative.
- 1123581321 6y ago
  This is a snarky parody, but put together you are both just saying that you can only afford to spend any time on job matches likely to be especially good, but that you’ll spend a lot of time on the good ones. Which just means you both are in an illiquid or conservative hiring market that is out of your control and their control to change.
Clubber 6y ago
>I can't hire easy and then fire easy. Why not? Maybe you should address that problem. It would certainly make things a lot easier.
jjav 6y ago
> I cannot give every application 1-2 hours of review if I get 100+ resumes. Your process has already failed if you're considering 100+ people! First, you should never be getting 100+ resumes for a role. If you are, you need to write better job descriptions and/or get a better recruiter who knows how to match to the job description. With that in place, you (I) are getting about 10-20 resumes at most. Then what I do is read them and rank them. Takes less than two hours. I'll only interview the top five from this stack. I'm happy to give each of these five people however many hours of attention it takes, they and I deserve it. This way the people who didn't get to the interview round have not wasted any of their time which is the most respectful way to handle it.
- _qulr 6y ago
  > you need to write better job descriptions Tech job postings are the absolute worst. Anyone who's having trouble with hiring in any way needs to start there. Everyone in tech knows that job postings are a joke, which is why you're told to apply to jobs even if you're not qualified, and then companies complain about the applicant pool. It's their own fault! The "excuse" is almost always "HR". But this just tells the applicant your company is a bureaucratic nightmare that few sane applicants would want to join.
  - _qulr 6y ago
    There's a lot of worry in tech hiring about the "faker", the engineer who lies or exaggerates on their résumé. The irony is that the tech hiring process, especially the job postings, encourage the fakers to apply. You're practically beginning fakers to apply. The most honest, scrupulous people tend to only apply for jobs where they're 100% qualified according to the job posting. So the system, which hires people who don't actually meet the listed qualifications, is systematically selecting against the honest applicants. Honest people can even be driven out of tech in virtue of being honest.
- autarch 6y ago
  > Your process has already failed if you're considering 100+ people! Remote roles get a _lot_ more applications than on site. In my experience getting 100 applications is quite common for such a role.
goatinaboat 6y ago
The author doesn't appear to understand the economics of the hiring company; it's about time & effort to filter and the cost of making a bad hire. I cannot give every application 1-2 hours of review if I get 100+ resumes. This is an entirely self-created problem, not for you personally, I mean for the industry. We are against "credentialling" so signals like personal recommendations, alma mater, or work history at prestigious firms are overlooked. My employer tried Hackerrank for a while, we abandoned it when we realised that the candidates we really wanted (e.g. based on personal recommendations from existing employees) were dropping out of the pipeline as soon as the Hackerrank link was sent to them. And the ones we were getting were good at Hackerrank and not much else.

lhorie 6y ago

I'd say "work they've done for previous employers" is something that nearly every candidate with industry experience has. The problem is that when I ask about it, candidates often are terrible at communicating what the work consisted of: often they focus on microscopic minutiae that appears disconnected from the big picture (e.g. gloating about gluing some trivial library as if that's a big accomplishment, when the position is for a senior engineer) or they demonstrate apathy/lack of proactiveness (e.g. some variation of "I just did what I was told") or they ramble incoherently, etc. And this is supposed to be one of those bog-standard question that interviewees are always told by job interview guides to be prepared for! I agree that people that have OSS work to show are much rarer to come by, and FWIW, they tend to do better in interviews IME. My theory is that it's not that the OSS resume bullet point itself sets them apart, but rather that they polished their skills more through the hard work they put into their OSS projects.

autarch 6y ago
Just to clarify, I thought the author of the linked piece was suggesting that people could share actual code from previous employers somehow. Of course it's reasonable to ask people about their past work in an interview and to expect them to speak about it coherently.
- lhorie 6y ago
  I think OP did suggest sharing actual work, which would make sense if said work consists of e.g. semantic html that can be looked at in a publicly accessible site. Obviously sharing backend trade secrets would be a big no-no. I've had people say they can't talk about their work due to NDAs, and that's completely fine in my books. We just move on to another topic. FWIW, even when a candidate mentions having an OSS project, I refrain from looking at the actual code, and especially doing code review. I don't consider an interview setting the appropriate place to be grilling people on why they used a while loop instead of a for loop or whatever, since a) nearly everyone writes "bad" code occasionally and b) often things are done in certain ways for some good reason that isn't really relevant to my goal of evaluating the candidate. At the end of the day, the interviewer's goal IMHO should be to get as many signals they can from the conversation and make a determination about whether the candidate meets/exceeds a minimum threshold of competence

johnfn 6y ago

Them: "We've got a coding challenge for you..." Me: "I've got this repo on Github with millions of downloads and 10k stars. It's at least 20k lines of my own code. Would that be good to demonstrate my coding ability?" Them: "Haha, no, that'd be too much work for us. Please do the test instead." Me: "Fine." Then they rejected me because I used GET instead of POST. Clearly that shows I have no idea how to code. That was a large (1000+ employee) YC company, by the way.

dmitryminkovsky 6y ago
Truly absurd. Followed the link in your profile. You wrote VSCodeVim! 49,674++/14,291--. And because you used the "wrong" HTTP verb. Did they also say you should have used tabs instead of spaces?? Outrageous. By the way, thanks for VCCodeVim!
- johnfn 6y ago
  Hah! Thanks :-)
deleted 6y ago
[deleted]
golergka 6y ago
> Then they rejected me because I used GET instead of POST. OK, I'm honestly curious here. What was the request, and why did you make such a decision? Do you think it is the right approach in this case, or that it's an insignificant mistake that does not represent a person's understanding of HTTP protocol? I remember hearing about at least one story where using GET instead of POST lead to disastrous consequences, as some robot crawled all over the "delete" links - but I have to admit, I can't imagine how it would happen without other significant design flaws happening as well (as "delete" links being public or robot being able to crawl under authenticated user's identity). This sounds like an error that can cause irrational irritation by the reviewer, but I can't imagine it being the sole reason to decide that the author can't code.
- hysan 6y ago

zapt02 6y ago

This is on-point! I've been involved in the recruitment process at my current employer for years and 95% of people that make it past the initial recruiter meet-and-greet have absolutely nothing to show in terms of open-source contributions or personal projects. Most of them just do the homework assignment so that you can at least talk about something during the interview. You can always say it's because the company doesn't attract good enough candidates, but good luck with that in a competitive dev market in a large european capital. I appreciate the authors honesty in his obliviousness of being on "the other side of the table" and I think it's clear that the author is living in a bubble that doesn't correspond to reality for people recruiting.

itsdrewmiller 6y ago
fyi the author is female - https://css-irl.info/about/ https://css-irl.info/about/.

chrisfosterelli 6y ago

We've done something similar and found even candidates that do have public side projects may not feel those projects fully represent the code they'd write today and preferred the takehome.

autarch 6y ago
Good point. I'm sure some of the candidates who do our assignment have stuff on GitHub or elsewhere, but thought they could do better work with the assignment.

adamvalve 6y ago

Came here to share the same exact points. He’s making a lot of assumptions never being on the other side and actually interviewing lots of candidates. Most of the time I get half assed projects with bugs that are obvious and they haven’t ever made contributions to open source software as an alternative to the take home project. I think the at home project is the most lenient way to test someone because they aren’t pressured to solve a problem on the spot, instead they are in the comfort of their own home and can reference whatever documentation they would need, just like they would in a real position.