4 ms·
As a developer, I understand this perspective. But, from an employer's perspective, resumes tell you very little about a candidate and are essentially worthles
by rsyring 5y ago
As a developer, I understand this perspective.
But, from an employer's perspective, resumes tell you very little about a candidate and are essentially worthless. The sole usable metric we get from them is years of relevant experience.
We respond with a questionnaire that gets us more uniform answers about experience and technologies used.
Assuming the above doesn't filter the candidate out, we move on to a 90 min max "take home" exercise. In our case, it's not a coding exercise, but that's not that important for this discussion.
Only if all of the above hasn't filtered out the candidate, do we move to a Zoom meeting. In the Zoom meeting, after an initial introduction, we do a few easy coding exercises. Like, reverse a string or sum the integers in a file easy.
A few notable things from this experience:
1. The number of candidates who struggle with the Zoom interview coding exercise is surprising. It's a lot higher than expected and almost all of our candidates at that stage have 2+ years of professional development experience.
2. The number of candidates filtered out by the "take home" exercise is very high. 85+%
We literally don't have enough time to talk to every candidate that applies with the right amount of experience. And, even if we did, many/most candidates on the market aren't good developers. Our signal to noise ratio is already bad. In that case, it would be terrible.
As a developer, I sympathize with your perspective. But you may be passing on some good opportunities by not being willing to "play the game" a bit. Some employers are indeed bad actors and/or terrible at hiring. But given the current market, even those making a valiant effort to do it well, due to sheer volume, are usually going to have an exercise of some kind.
We post our salary ranges up-front, don't want to waste anyone's time that way. We also put a ton of effort into a very detailed job description and application process. The hope is that the candidate can see the effort we put in and will be willing to reciprocate. If that doesn't end up being the case, we assume, like you, it probably wouldn't have been a good for anyway.
FWIW.
- MathCodeLove 5y agoJust out of curiosity, what do you mean when you say many/most candidates on the market are poor developers? Seems crazy that a majority of people applying for any position lack the requisite ability to actually fufull the positions requirements.
- rsyring 5y agoI mean exactly what I said. :) And yes, I agree, it seems crazy. But it's our reality and seems validated by others I know in the industry and anecdotes here on HN. There is just so much demand, it pulls people into the industry that can't really perform as professional developers.
- MathCodeLove 5y agoWow! That's crazy. As a relatively Jr dev still early in my career, any recommendations for differentiating myself from those people on my resume/portfolio? I have a github, is that enough or are these people plagarizing github repos as well?
- rsyring 5y agoNot exactly what you asked for, but maybe helpful: https://www.level12.io/blog/advice-to-aspiring-developers/ https://www.level12.io/blog/advice-to-aspiring-developers/ I think the frustrating reality is that it's usually not possible to tell the good from the bad at the portfolio/resume level, some kind of skills/competency test must be given. I personally don't look at GitHub repos because I don't know how long it took to write that code. If it's great code, but took 4x to write than it should have, I wouldn't know. There are also a lot of applicants that just don't have much public in GH. Finally, to be clear, I'm not saying they are all bad actors. I'm sure some are and the same for employers. Mostly a result of the current world economics.
- MAGZine 5y agoIf you sent me a 90m(!) takehome non-coding test I would absolutely nope out of that process. You're not respecting your applicants time. At all. Your funnel is steep because it has bullshit steps. And the only people coming through it are probably desperate, which is why your signal/noise ratio is "already terrible".
- rsyring 5y agoAnd, given that perspective, you'd probably be a bad fit, so no time lost on either side. :) What kind of experience do you have hiring? If you have a better process, that has been proven over time to work, please share. I'm part of a small group of leaders/owners from other development shops. We meet monthly to collaborate and learn from each other. Hiring is a frequent topic and I assure you that our steep funnel and perspective on candidate ability is not a unique experience, despite divergent hiring processes. It is true that our process could be filtering out candidates who might otherwise apply. In that case, it's most likely working as intended.
- Cheezemansam 5y ago>In that case, it's most likely working as intended. You are very casual in claiming that there is such an intentional correlation between developers who are not willing to spend 90+ minutes on a non-technical prescreen with a 15% success rate and competent developers who can translate business needs into actionable steps. It's reasonable to say you are willing to accept that there are developers who are unwilling to go through this process, but to say you are filtering them out intentionally is needlessly contemptuous.
- rsyring 5y agoYour comments are needlessly contemptuous? :) But, seriously, it's intentional in the sense that if someone is a fantastic developer, but can't appreciate why a process like this is valuable to them and us, then it's a good thing they aren't applying. I need our developers to be competent at development but also reasonable in their perspective on the give and take between a business and their employees. It's deliberate that I don't want people with your perspective/attitude to apply. I don't want people who can't appreciate the others parties constraints. It's not going to be a good match in the long run. And that's true even if said person can code circles around our best developers.
- datavirtue 5y ago"...we move on to a 90 min max "take home" exercise. In our case, it's not a coding exercise, but that's not that important for this discussion." This is definitely the most important aspect of this discussion.
- rsyring 5y agoIn the past, we hired devs who could code well when given well defined problems, like you'd get in an interview process. But they struggled with the actual development work after we hired them. We put some effort into figuring out the disconnect. Turns out, one of the most important skills in our organization is being able to break down a business level description of the work to be done and turn it into discrete development steps. Also, need to have a good grasp of data modeling and how to change the model to support changes in the work requests. So, those are the first two things we test. We give the candidate a description of the work to be done and ask them to interact with it. What questions would you ask the client and how would you break this down into stories/issues? Then, we give the schema of the existing database and ask them to modify it so the new schema supports the work requested. Still very software development oriented, just not coding. We have more in-depth coding exercises later in the process. I realize in some orgs, there would be a project manager or product owner of some type who would break that work down. And we have team leads who do the majority of that work. But for our org, devs who couldn't do this struggled to perform well in the development work too. So it became a skill that correlated to being able to succeed after hire.
- ericbarrett 5y ago> [W]e do a few easy coding exercises. ... The number of candidates who struggle with the Zoom interview coding exercise is surprising. It's a lot higher than expected and almost all of our candidates at that stage have 2+ years of professional development experience. Indeed, this simple filter is the original purpose of FizzBuzz and other simple coding tests. Circa 2007: https://blog.codinghorror.com/why-cant-programmers-program/ https://blog.codinghorror.com/why-cant-programmers-program/
- Cheezewheel 5y ago>The number of candidates filtered out by the "take home" exercise is very high. 85+% For a 90 minute take home exercise that I have to complete before I am allowed to speak to a human being, that is on average about 10 hours of work your company is expecting me to do, for free. And then I have to do a coding assignment afterwords anyways. I will say that the fact that you post the salary range is good. This is the sort of time investment that would only be worth it for a top end salary.
- rsyring 5y agoHow did we go from 90 minutes to 10 hours? Also, I wouldn't say it's "not allowed", just not the standard process. We have, for specific reasons at the candidates request, done a Zoom meeting earlier in the process. Candidates are also encouraged to email us with questions and we put a lot of effort into being responsive and good communicators with the applicants.
- garyjlin 5y agoThis is exactly the problem we're trying to solve for. You have too many candidates, you want to be fair to all of them, but you don't have the resources to manually talk to every one of them one by one. You could give them a LeetCode-style auto-test question, but that's not much better than flipping a coin on every candidate. You could also use a service like Karat to do the interviews for you, but before you know it you'll be out $200K. Give them a Litebulb interview, let them do it on their own time, everyone that pushes up a solid solution gets scheduled for a call.