Ask HN: Is it reasonable to have job applicants complete a test before applying?
16 comments
That's more the type of question I'd hang out as a programming puzzle on the web and then encourage people who solve it (guide them to a solved screen) to apply with a link to a gist or similar. I've applied to companies before just because I like solving programming puzzles, and once you're at that point, why not?
FWIW, speaking as an SDET lead, I'll do something like that voluntarily, time allowing.
But I A) don't submit applications, I send resumes, so let's start there; and B) wouldn't do something like you describe as a formal prescreen. Before I've talked to you, you have maybe half an hour of my time if I've heard of you, maybe five minutes of my time if I haven't.
After you've convinced me I'd like to work for you, then I'd give you an hour or two on a project, interest depending. Any more than that, and you need to pay me. You'd also probably have to be on my short list of final employer candidates. I'm interviewing y'all too, you know. I'm more inclined to do homework after a successful round of interviews than beforehand, mostly because there'll probably be a job out there I'm equally interested in that doesn't require this. I do pay attention to how much of a pain in the ass a company is to apply to, and it does weigh into my decisions to accept (or even continue).
I realize this comes across maybe a touch arrogant, but it's honestly accurate. Ask yourself this: Do you want the type of developer desperate enough for a job to jump through hoops?
SDET is an extremely competitive niche for good developers, since the QA path tends to filter people out into other disciplines before they hit a good amount of SDET skill. A good SDET can afford to be choosy. This is more friction than I'd put on a process to hire for my team.
FWIW, speaking as an SDET lead, I'll do something like that voluntarily, time allowing.
But I A) don't submit applications, I send resumes, so let's start there; and B) wouldn't do something like you describe as a formal prescreen. Before I've talked to you, you have maybe half an hour of my time if I've heard of you, maybe five minutes of my time if I haven't.
After you've convinced me I'd like to work for you, then I'd give you an hour or two on a project, interest depending. Any more than that, and you need to pay me. You'd also probably have to be on my short list of final employer candidates. I'm interviewing y'all too, you know. I'm more inclined to do homework after a successful round of interviews than beforehand, mostly because there'll probably be a job out there I'm equally interested in that doesn't require this. I do pay attention to how much of a pain in the ass a company is to apply to, and it does weigh into my decisions to accept (or even continue).
I realize this comes across maybe a touch arrogant, but it's honestly accurate. Ask yourself this: Do you want the type of developer desperate enough for a job to jump through hoops?
SDET is an extremely competitive niche for good developers, since the QA path tends to filter people out into other disciplines before they hit a good amount of SDET skill. A good SDET can afford to be choosy. This is more friction than I'd put on a process to hire for my team.
This is a great perspective, I tend to think an affinity for puzzles is a good indicator of the SDET mentality I'm looking for; I was trying to attract people who'd be interested by that challenge.
However, the universally negative response to having the challenge this early has made me rethink a bit. I think I may make it much more optional and/or apply it later. Maybe look for places to hang it out on the web...
However, the universally negative response to having the challenge this early has made me rethink a bit. I think I may make it much more optional and/or apply it later. Maybe look for places to hang it out on the web...
If you came up with a testing challenge in particular, I'd be interested to see it!
I wouldn't use this as your only feeder--as someone else mentioned, puzzle affinity isn't going to be a 100% crossover with the people you want to track. I'd see a puzzle as one of a few tactics to all try simultaneously.
That's probably another argument against making something like this mandatory--it essentially becomes your only feeder/filter if everyone goes through it.
I wouldn't use this as your only feeder--as someone else mentioned, puzzle affinity isn't going to be a 100% crossover with the people you want to track. I'd see a puzzle as one of a few tactics to all try simultaneously.
That's probably another argument against making something like this mandatory--it essentially becomes your only feeder/filter if everyone goes through it.
People who have an affinity for puzzles or interested in a challenge won't necessarily have any interest in YOUR challenge.
Forget about the social expectation for a bit - I don't think it's a good idea in terms of attracting the best talent that you can get. There are people who have better things to do with their time than spend an hour or more on a programming puzzle for a company they've never talked to. You want to hire these people.
In terms of economic efficiency, it's much better overall to do resume-screening before the coding challenge. Both you and the candidate spend something less than 5 minutes each checking if it might be a good fit before committing to spending much more time on the process. With the challenge that early, you either make people waste time when you could have found out more cheaply, or you convince people that it's too expensive to find out more about your compatibility.
In terms of economic efficiency, it's much better overall to do resume-screening before the coding challenge. Both you and the candidate spend something less than 5 minutes each checking if it might be a good fit before committing to spending much more time on the process. With the challenge that early, you either make people waste time when you could have found out more cheaply, or you convince people that it's too expensive to find out more about your compatibility.
> My question is; is this too much to expect people to do before I even look at their application?
I can understand your desire to pre-filter somehow. But: I would skip this job ad as it is.
You need to have a real good selling point for your company/product/project that makes the applicant really crave the job. (You left that one out to anonymize your post, right?)
You might deny yourself a pool of smart people who either dislike jumping through hoops or have easier access to jobs they deem equally (or more) attractive.
You might attract folks who are more desperate than skilled but nonetheless able to solve your task.
On the other hand: I am not a lawyer and i don't know under which jurisdiction you are operating. Some countries have laws requiring you to consider all incoming applications. So please consult a lawyer, too.
I can understand your desire to pre-filter somehow. But: I would skip this job ad as it is.
You need to have a real good selling point for your company/product/project that makes the applicant really crave the job. (You left that one out to anonymize your post, right?)
You might deny yourself a pool of smart people who either dislike jumping through hoops or have easier access to jobs they deem equally (or more) attractive.
You might attract folks who are more desperate than skilled but nonetheless able to solve your task.
On the other hand: I am not a lawyer and i don't know under which jurisdiction you are operating. Some countries have laws requiring you to consider all incoming applications. So please consult a lawyer, too.
When I'm hiring I break off some small slice of my project. Its something like 4-12 hours of work. We negotiate what there wage would be if hourly and I pay that, with a cap. Then I eval their work, code review (if necessary), pay for the work. The process tells me much more than any interview ever would and costs the same (or less). For the final 4|5 candidates it works well for me
Your job post has two main functions.
1. sell the opportunity 2. have candidates self-select out
Every job pipeline is going to follow traditional funnel math and you are starving your funnel.
The test you've proposed is more appropriate for later in the funnel when they are more willing to trade their time for the potential opportunity.
1. sell the opportunity 2. have candidates self-select out
Every job pipeline is going to follow traditional funnel math and you are starving your funnel.
The test you've proposed is more appropriate for later in the funnel when they are more willing to trade their time for the potential opportunity.
It depends on the type of candidate you hope to attract.
If someone is applying for a lot of positions at once, an up front homework problem can be seen as unreasonable before even a basic semblance of role compatibility is established.
Why not offer it as a HW problem after a resume and phone screen?
If someone is applying for a lot of positions at once, an up front homework problem can be seen as unreasonable before even a basic semblance of role compatibility is established.
Why not offer it as a HW problem after a resume and phone screen?
Did you complete this exercise, or have a colleague complete this exercise? If it took more than an hour or you couldn't complete it then it is too hard/long.
If you haven't completed it or had someone complete it then you shouldn't be sending it out at all.
If you haven't completed it or had someone complete it then you shouldn't be sending it out at all.
I think having to submit the cover letter in this format is kind of cheesy - it's difficult enough to express oneself concisely. I wouldn't mind posting an application to some well documented endpoint, which included the code to do some task so you could run it. I have been wondering lately about the utility of asking people to do some puzzles on leetcode or whatever if they don't have a github.
I think it's reasonable to have candidates submit a solution to a problem prior to an interview, but if you require it in order to apply I think you'll find that you don't get very many applicants. In the first case, the candidate has entered the pipeline and has some confidence that the position is still open and that you aren't rejecting him out-of-hand (unqualified, etc).
I'd say it's too much to ask at the application stage. If you want to give a code test after a phone screen, that seems more reasonable. Both parties have more confidence that the position is a good fit, which makes the time required a fair request.
You should try to evaluate candidates based on their portfolio, resumes, etc. If after doing so you still don't know enough to evaluate them properly then sure, give them a take home test.
If they have a good resume, sound good on the phone, and pass the PI test, I usually give them a coding test when I bring them in for a formal interview.
I'd only do that sort of thing if I felt there was a decent chance I might get the job. The application stage isn't far enough along.
Yep there should be some indication of mutual interest before any reasonable candidate would expend energy on that.
Can you post a similar or simplified challenge here? It seems like a nice exercise
It all depends on how you sell it!
If you advertise a salary 50% over market I'll do it.
If you advertise a salary 50% over market I'll do it.
The test is something like this: I've described a fairly simple json specification in words and requested that applicants submit a cover letter that conforms to that spec. The spec has an optional value called challenge_checkvalue which can be derived by completing a challenge - querying a url with an id between 00 and 99 for json payloads that may or not conform to the same spec. The checkvalue is derived by combining the ids of all the ones that are not compliant.
So it's a decent amount of work. I've deliberately made the number of payloads to check high enough that no one is tempted to check them manually. Validating JSON, even making http requests like that is not something that every valid candidate will have ever done, but I think that these concepts should accessible with some research.
My question is; is this too much to expect people to do before I even look at their application?