7 ms·

The Qualified Manifesto on Hiring Software Developers

65 points by geoffroberts 7y ago

sportanova 7y ago
Multiple hour coding assessments will work for people who are motivated for a new job. But every company wants "passive" candidates that are already working somewhere. If they're already (moderately) happy somewhere, they're not going to spend 3+ hours on your pre-process. Companies that can identify talent without wasting the talent's time will be at a huge advantage
- deleted 7y ago
  [deleted]
digb 7y ago
My key point every time my team discusses hiring: If you think your take-home project takes N hours, add 1-1.5. You already know the context, and are underestimating the difficulty even if you've run through it before.
- jagged-chisel 7y ago
  > ... especially if you've run through it before [edits mine] We're doing a hackathon-style interview session this Friday, and I've already had to remind the team that one of our coding challenges is "easy" because we know the answer. You need to think back to the first time you saw it. Also, we're not actually interested in the solution, but how you arrived at it. Once you grok the problem, most software people hit on the solution pretty soon, and can begin coding - we want to see how you come to the realization, and then how you work to create the solution.
  - realthing 7y ago
    This sounds silly
- dver 7y ago
  This can be added to the bigger pile that is software project estimation.
  - commandlinefan 7y ago
    Hofstatder’s law: it always takes longer than you expect, even after accounting for Hofstatder’s law.
- Ididntdothis 7y ago
  And you never know what the company wants. Fully tested, nicely formatted code or just a proof of concept? Agnonizing over this also costs time.
  - chris11 7y ago
    A lot of this is dependent on how reasonable the take home project is. But I've always assumed that my work needs to be professional. That means it needs to be readable, well-designed, and nicely formatted. Of course take-home projects should be short, and are basically a POC. But shortcuts should probably be discussed with the interviewer and should be well documented.
unlinked_dll 7y ago
Something else that should be mentioned Don't send technical pre-screens to candidates before you talk to them. You're not Google. I'm not going to waste my time on something before I know anything about the company, the team, or the job itself. I haven't really seen this interviewing for jobs on the west coast, but there's a lot of shops in Chicago (fintech) that seem to be under the impression that anyone applying for an engineering job is desperate.
- deleted 7y ago
  [deleted]
- Aperocky 7y ago
  tbh, there’s a disconnect. Large number of recent grads are flooding the application channels. Half of them have skill level that probably shouldn’t be accepted anywhere. At the same time established veterans are highly sought after and never really needed to ‘apply’. As a result a massive proportion of application pipeline is filled with noise. And most of them are somewhat desperate for a job. Giving the illusion that qualified people are also desperate.
  - shados 7y ago
    That's the key. It's very much two bubbles. Because some parts of the job is almost factory like, anyone with a bit of practice can do it, and the other part is extremely difficult, requires ton of experience, might need a computer science degree or more, etc. Both groups barely understand the other. One is like "Lol I can write my email address on toilet paper and have a 500k/year job by Monday!", the other is "Ive applied at 150 companies and 149 of them didn't even reply back, the last 1 did to tell me there was a typo in my resume!". But both groups have the same title (plus or minus seniority levels), work on the same projects in the same teams and follow the same career track. I wonder how long until software engineering becomes more like other fields. The nurse, the general practitioner and the brain surgeon are not applying at the same job or even have the same backgrounds. The hvac technician and the engineer aren't either. Maybe the person who builds forms and the person who engineers a distributed system being on the same career track is the wrong model. It sets the wrong expectations. It can stunt career growth.
z3t4 7y ago
I would love a coding assignment. But make sure you have an style guide and tell me what paradigms to use and what patterns, and have an auto linter and style formatter. I would hate to be rejected just because I used tabs and you prefer tabs or vice versa. A could adapt to anything, even write the damn app in brainfuck if thats what you want. Instead you dismiss me after 5 minutes of soft talk with a group of people i never met.
malvosenior 7y ago
This is a pretty good manifesto. Something that I rarely (never) see mentioned is that the ability to quickly evaluate a technical hire is a skill managers can and should cultivate. I never give coding tests. I sit down with a candidate and within 20 minutes of verbally discussing their prior projects I know if I want to hire them or not. This does mean that the manager has to be technical and have the ability to deep dive in these conversations. It's by far the most efficient and candidate friendly (and interviewer friendly!) method I've seen. I've never had a bad hire doing this and I've hired dozens of people
- 52-6F-62 7y ago
  I was hired with a very similar process. I was asked several technical questions that applied to the role and about my own history, etc. Three years later I'm still here and have survived several rounds of layoffs and a sale of the division of the company I work for. I still work with that manager. Most interviews with tech screens that I've done have been fine, though. A couple of them have been bad where I've recognized the engineer testing me has been wrong but that never fares well for the person being interviewed. Most calls I take are often an introduction before we even go to a tech screen, though, and I appreciate that chance usually. It's saved interviewers and myself a lot of time in the past.
  - mucle6 7y ago
    Your story about surviving layoffs implies that you survived because the interview thoroughly vetted you. Wouldn't that be true of people that were laid off?
    - 52-6F-62 7y ago
      It doesn't imply anything except that I'm still working with that manager and we've worked well together. At the time I was the only technical hire under a technical manager. Much of the business isn't technical and weren't part of the same interview process. I understand what you're trying to ask, but no—it doesn't apply in this case.
- 7y ago
TulliusCicero 7y ago
How do you verify no cheating with work samples? > Create a project based coding assessment that directly reflects the work the developer would be expected to deliver if hired, making sure to provide some open-ended flexibility that allows candidates to showcase their strengths. This might require the developer to digest an existing code base, gather requirements, communicate to your team a push request they’d like to make, or provide a detailed description of code that they’ve submitted before merging into production. These activities move your assessment process beyond the code, revealing insights into what a candidate would actually be like to work with. That sounds like it'd take more than 3 hours, unless it's based on a very small project.
- twblalock 7y ago
  > How do you verify no cheating with work samples? You can't really, and that's the main reason most of the teams I know avoid them, or supplement them with onsite whiteboarding.
  - TulliusCicero 7y ago
    Yeah, I know some teams say that they discuss the project after, which would work if the candidate couldn't code at all. But if they're just a mediocre programmer who's been coached, it may be harder to detect, especially if they have a talent for BS'ing.

65 points by geoffroberts 7y ago

Multiple hour coding assessments will work for people who are motivated for a new job. But every company wants "passive" candidates that are already working somewhere. If they're already (moderately) happy somewhere, they're not going to spend 3+ hours on your pre-process. Companies that can identify talent without wasting the talent's time will be at a huge advantage

deleted 7y ago
[deleted]

digb 7y ago

My key point every time my team discusses hiring: If you think your take-home project takes N hours, add 1-1.5. You already know the context, and are underestimating the difficulty even if you've run through it before.

jagged-chisel 7y ago
> ... especially if you've run through it before [edits mine] We're doing a hackathon-style interview session this Friday, and I've already had to remind the team that one of our coding challenges is "easy" because we know the answer. You need to think back to the first time you saw it. Also, we're not actually interested in the solution, but how you arrived at it. Once you grok the problem, most software people hit on the solution pretty soon, and can begin coding - we want to see how you come to the realization, and then how you work to create the solution.
- realthing 7y ago
  This sounds silly
dver 7y ago
This can be added to the bigger pile that is software project estimation.
- commandlinefan 7y ago
  Hofstatder’s law: it always takes longer than you expect, even after accounting for Hofstatder’s law.
Ididntdothis 7y ago
And you never know what the company wants. Fully tested, nicely formatted code or just a proof of concept? Agnonizing over this also costs time.
- chris11 7y ago
  A lot of this is dependent on how reasonable the take home project is. But I've always assumed that my work needs to be professional. That means it needs to be readable, well-designed, and nicely formatted. Of course take-home projects should be short, and are basically a POC. But shortcuts should probably be discussed with the interviewer and should be well documented.

unlinked_dll 7y ago

Something else that should be mentioned Don't send technical pre-screens to candidates before you talk to them. You're not Google. I'm not going to waste my time on something before I know anything about the company, the team, or the job itself. I haven't really seen this interviewing for jobs on the west coast, but there's a lot of shops in Chicago (fintech) that seem to be under the impression that anyone applying for an engineering job is desperate.

deleted 7y ago
[deleted]
Aperocky 7y ago
tbh, there’s a disconnect. Large number of recent grads are flooding the application channels. Half of them have skill level that probably shouldn’t be accepted anywhere. At the same time established veterans are highly sought after and never really needed to ‘apply’. As a result a massive proportion of application pipeline is filled with noise. And most of them are somewhat desperate for a job. Giving the illusion that qualified people are also desperate.
- shados 7y ago
  That's the key. It's very much two bubbles. Because some parts of the job is almost factory like, anyone with a bit of practice can do it, and the other part is extremely difficult, requires ton of experience, might need a computer science degree or more, etc. Both groups barely understand the other. One is like "Lol I can write my email address on toilet paper and have a 500k/year job by Monday!", the other is "Ive applied at 150 companies and 149 of them didn't even reply back, the last 1 did to tell me there was a typo in my resume!". But both groups have the same title (plus or minus seniority levels), work on the same projects in the same teams and follow the same career track. I wonder how long until software engineering becomes more like other fields. The nurse, the general practitioner and the brain surgeon are not applying at the same job or even have the same backgrounds. The hvac technician and the engineer aren't either. Maybe the person who builds forms and the person who engineers a distributed system being on the same career track is the wrong model. It sets the wrong expectations. It can stunt career growth.

z3t4 7y ago

I would love a coding assignment. But make sure you have an style guide and tell me what paradigms to use and what patterns, and have an auto linter and style formatter. I would hate to be rejected just because I used tabs and you prefer tabs or vice versa. A could adapt to anything, even write the damn app in brainfuck if thats what you want. Instead you dismiss me after 5 minutes of soft talk with a group of people i never met.

malvosenior 7y ago

This is a pretty good manifesto. Something that I rarely (never) see mentioned is that the ability to quickly evaluate a technical hire is a skill managers can and should cultivate. I never give coding tests. I sit down with a candidate and within 20 minutes of verbally discussing their prior projects I know if I want to hire them or not. This does mean that the manager has to be technical and have the ability to deep dive in these conversations. It's by far the most efficient and candidate friendly (and interviewer friendly!) method I've seen. I've never had a bad hire doing this and I've hired dozens of people

52-6F-62 7y ago
I was hired with a very similar process. I was asked several technical questions that applied to the role and about my own history, etc. Three years later I'm still here and have survived several rounds of layoffs and a sale of the division of the company I work for. I still work with that manager. Most interviews with tech screens that I've done have been fine, though. A couple of them have been bad where I've recognized the engineer testing me has been wrong but that never fares well for the person being interviewed. Most calls I take are often an introduction before we even go to a tech screen, though, and I appreciate that chance usually. It's saved interviewers and myself a lot of time in the past.
- mucle6 7y ago
  Your story about surviving layoffs implies that you survived because the interview thoroughly vetted you. Wouldn't that be true of people that were laid off?
  - 52-6F-62 7y ago
    It doesn't imply anything except that I'm still working with that manager and we've worked well together. At the time I was the only technical hire under a technical manager. Much of the business isn't technical and weren't part of the same interview process. I understand what you're trying to ask, but no—it doesn't apply in this case.
7y ago

TulliusCicero 7y ago

How do you verify no cheating with work samples? > Create a project based coding assessment that directly reflects the work the developer would be expected to deliver if hired, making sure to provide some open-ended flexibility that allows candidates to showcase their strengths. This might require the developer to digest an existing code base, gather requirements, communicate to your team a push request they’d like to make, or provide a detailed description of code that they’ve submitted before merging into production. These activities move your assessment process beyond the code, revealing insights into what a candidate would actually be like to work with. That sounds like it'd take more than 3 hours, unless it's based on a very small project.

twblalock 7y ago
> How do you verify no cheating with work samples? You can't really, and that's the main reason most of the teams I know avoid them, or supplement them with onsite whiteboarding.
- TulliusCicero 7y ago
  Yeah, I know some teams say that they discuss the project after, which would work if the candidate couldn't code at all. But if they're just a mediocre programmer who's been coached, it may be harder to detect, especially if they have a talent for BS'ing.