I should probably have made it clearer that I was talking mainly about cases as described in the post, which is what the top-level comment was talking about, which you replied to.
There's nothing wrong per se with having a job applicant solve some sort of challenge interactively, but I see a clear line being crossed when people are asked to build whole applications that may take them an entire afternoon.
Neither of those are "work"
You're not directly profiting from those tasks, but you're still telling the applicant to do them so one way or another they deserve to be compensated for it (ideally by gaining an equal amount of insight into the company).
You say you give them very detailed feedback on their projects, which does sound reasonable, but how common is that? And do you always give this feedback? Even if you already decided to not hire the person?
Re Re "just having them work for a day or two": What you describe sounds awfully restrictive. I will assume you work in a field where such an emphasis on secrecy is warranted, but for most cases so much paperwork just to give someone a computer to work on some simple task seems overkill.
My newest coworker just came here for one day, got my desk as I happened to not be working that day and got to work on some simple tasks. He spent an entire 8-hour work day here, and the company spent an entire 8-hour work day on him. That sounds fair, no? Sure, he wasn't being very productive, but again, on his first day, he was already one day ahead.
Lastly, considering my approach is always "I put in twice the amount of time that a candidate does" (to the extent that ~400 lines of code can warrant 2 pages of feedback)... I'd love to hear why this is a "one sided interrogation"
What does that feedback tell the applicant about the company? Do they get to know their coworkers? do they get an impression of real code as it is used in the company? Does it tell them anything about the work ethic? Does it show off a common workflow at the company?
Surely your feedback is valuable to the applicant, but it probably doesn't give them the same sort of insight than you get.
Overall what you've detailed sounds very reasonable. Roughly an hour is about the upper limit of what seems acceptable for homework, but here are two thoughts on that:
Are you sure most people don't spend way more than an hour on the task? I imagine most people would spend at least a few hours to make sure it's spotless.
Aside from direct feedback, do you also offer the applicant an insight into the company? A while ago someone (might have been here on dev) mentioned that in interviews they always ask to see one one example of good code and one of bad code written at the company, which seems like a very fair deal considering the applicant has to provide a code sample as well.
Thanks for the reply, taking your points in order:
You're not directly profiting from those tasks, but you're still telling the applicant to do them so one way or another they deserve to be compensated for it (ideally by gaining an equal amount of insight into the company).
Insight into the company is both tricky (for reasons I'll shed more light on in a moment) and of limited value to a candidate - especially if that candidate gets rejected during the hiring process. Granted, giving them exposure could improve our word of mouth, but we use recruiters for the PR type issues around recruitment.
So instead, I treat candidates with a "you're trading your time for my knowledge of the tech stack, if I can give you more knowledge about the stack, you can freely use that in your future, whomever that might benefit." Of course, I could meet a candidate that already knows more than I do about the tech stack... though unless they fail the "personality" side of the job, they'd be hired without having to worry about salary negotiations (we'd probably offer them higher than they came in the door requesting).
You say you give them very detailed feedback on their projects, which does sound reasonable, but how common is that? And do you always give this feedback? Even if you already decided to not hire the person?
Always? Yes. Especially if it's a rejection. I know what it's like to be a candidate & get no feedback other than "thanks, but no." Even for hires that we make, I've not only given them the feedback verbally during the interview process, but they then have access to the git repository where I store it (everyone has to attempt the same requirements, so I treat them as Merge Requests, and comment on them before the interview).
If I'm expecting to interview a Senior candidate for 4 hours, I've already put in around 6 hours dedicated to that one interview, between discussions with HR, my management, the team, reviewing the Resume & making notes on it, reviewing the take home test, etc etc. After an interview, I still probably have 2 hours of work to do around that one candidate. All of this is the same if I'm hiring them or rejecting them. In fact, it's more if I'm rejecting them because I then write up my notes to pass back to the candidate via the recruiter.
I will assume you work in a field where such an emphasis on secrecy is warranted, but for most cases so much paperwork just to give someone a computer to work on some simple task seems overkill.
Valid assumption - because of the work involved, there's legal restrictions around who can go where/when, and unless the paperwork is signed, I can't simply grant access to our code repositories. Oh how I wish...
As for demonstrating work ethic etc, candidates have two choices... either they can accept what I'm telling them, or I can hook them up with an OTR video call with someone else on the team (they all know the rules around what's a legal minefield to talk about... and things like how we run Agile or what the PMO folks are like to talk to is all perfectly fine to talk openly about). Of course, such OTR conversation adds more time that the candidate is spending on the application.
Roughly an hour is about the upper limit of what seems acceptable for homework...
I agree, though since we ask for it in a git repository (so I can see what commit strategy you default to, and I can see if you copy/pasta'd a solution or if you actually worked on it)... I know most candidates spend longer than an hour on it. I want to say that the average is "about a day" - and in most cases, during the interview, I'll be telling them how they could have written the same functional code, in less typing to save time. Unfortunately there's little I can do to control for that, but I do tell recruiters to "expect it to take an hour or so, but if they're sinking a whole weekend into it, that's a red flag, and they're free to get in touch to ask questions to clarify at any point."
If a candidate worked on it for an hour or two, and submitted a partially complete application, didn't fulfil the requirements etc... I'd still take the time to read what they wrote & make an informed decision about the next steps. If you were to write good code, but slowly, I'd still want to talk to you (maybe there's some personal reason like your new born baby that kept screaming in your ear). Half a submission still lets me see what I'm looking for, so it's always better than no submission at all.
A while ago someone (might have been here on dev) mentioned that in interviews they always ask to see one one example of good code and one of bad code...
I've honestly never been asked that... though if someone did, say, ahead of the take-home test for a Senior position... I have enough examples of good/bad that we could demo both sides of everything Uncle Bob talks about, for example. Despite our legal obligations, it wouldn't be hard to find some method to demonstrate that doesn't expose more information than needed, and worst case, I might have to lightly refactor some things for the purpose of sharing.
And this one is out of order on purpose:
I see a clear line being crossed when people are asked to build whole applications that may take them an entire afternoon.
I completely get your point, and one candidate I talked to recently felt the same way. Their response to the test was "I already have my own CRUD application using the same tech stack, hosted publicly on GitHub" - so they skipped the test & I reviewed the work they'd already done.
Some industries, yes, having someone sit at a desk, talk to the team, get paid and get given free coffee etc all day is do-able. Unfortunately, I still work in a "dino industry" (it was only in recent months that the development team were allowed to see logs from the Production system, owing largely to the InfoSec policy).
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I should probably have made it clearer that I was talking mainly about cases as described in the post, which is what the top-level comment was talking about, which you replied to.
There's nothing wrong per se with having a job applicant solve some sort of challenge interactively, but I see a clear line being crossed when people are asked to build whole applications that may take them an entire afternoon.
You're not directly profiting from those tasks, but you're still telling the applicant to do them so one way or another they deserve to be compensated for it (ideally by gaining an equal amount of insight into the company).
You say you give them very detailed feedback on their projects, which does sound reasonable, but how common is that? And do you always give this feedback? Even if you already decided to not hire the person?
Re Re "just having them work for a day or two": What you describe sounds awfully restrictive. I will assume you work in a field where such an emphasis on secrecy is warranted, but for most cases so much paperwork just to give someone a computer to work on some simple task seems overkill.
My newest coworker just came here for one day, got my desk as I happened to not be working that day and got to work on some simple tasks. He spent an entire 8-hour work day here, and the company spent an entire 8-hour work day on him. That sounds fair, no? Sure, he wasn't being very productive, but again, on his first day, he was already one day ahead.
What does that feedback tell the applicant about the company? Do they get to know their coworkers? do they get an impression of real code as it is used in the company? Does it tell them anything about the work ethic? Does it show off a common workflow at the company?
Surely your feedback is valuable to the applicant, but it probably doesn't give them the same sort of insight than you get.
Overall what you've detailed sounds very reasonable. Roughly an hour is about the upper limit of what seems acceptable for homework, but here are two thoughts on that:
Are you sure most people don't spend way more than an hour on the task? I imagine most people would spend at least a few hours to make sure it's spotless.
Aside from direct feedback, do you also offer the applicant an insight into the company? A while ago someone (might have been here on dev) mentioned that in interviews they always ask to see one one example of good code and one of bad code written at the company, which seems like a very fair deal considering the applicant has to provide a code sample as well.
Thanks for the reply, taking your points in order:
Insight into the company is both tricky (for reasons I'll shed more light on in a moment) and of limited value to a candidate - especially if that candidate gets rejected during the hiring process. Granted, giving them exposure could improve our word of mouth, but we use recruiters for the PR type issues around recruitment.
So instead, I treat candidates with a "you're trading your time for my knowledge of the tech stack, if I can give you more knowledge about the stack, you can freely use that in your future, whomever that might benefit." Of course, I could meet a candidate that already knows more than I do about the tech stack... though unless they fail the "personality" side of the job, they'd be hired without having to worry about salary negotiations (we'd probably offer them higher than they came in the door requesting).
Always? Yes. Especially if it's a rejection. I know what it's like to be a candidate & get no feedback other than "thanks, but no." Even for hires that we make, I've not only given them the feedback verbally during the interview process, but they then have access to the git repository where I store it (everyone has to attempt the same requirements, so I treat them as Merge Requests, and comment on them before the interview).
If I'm expecting to interview a Senior candidate for 4 hours, I've already put in around 6 hours dedicated to that one interview, between discussions with HR, my management, the team, reviewing the Resume & making notes on it, reviewing the take home test, etc etc. After an interview, I still probably have 2 hours of work to do around that one candidate. All of this is the same if I'm hiring them or rejecting them. In fact, it's more if I'm rejecting them because I then write up my notes to pass back to the candidate via the recruiter.
Valid assumption - because of the work involved, there's legal restrictions around who can go where/when, and unless the paperwork is signed, I can't simply grant access to our code repositories. Oh how I wish...
As for demonstrating work ethic etc, candidates have two choices... either they can accept what I'm telling them, or I can hook them up with an OTR video call with someone else on the team (they all know the rules around what's a legal minefield to talk about... and things like how we run Agile or what the PMO folks are like to talk to is all perfectly fine to talk openly about). Of course, such OTR conversation adds more time that the candidate is spending on the application.
I agree, though since we ask for it in a git repository (so I can see what commit strategy you default to, and I can see if you copy/pasta'd a solution or if you actually worked on it)... I know most candidates spend longer than an hour on it. I want to say that the average is "about a day" - and in most cases, during the interview, I'll be telling them how they could have written the same functional code, in less typing to save time. Unfortunately there's little I can do to control for that, but I do tell recruiters to "expect it to take an hour or so, but if they're sinking a whole weekend into it, that's a red flag, and they're free to get in touch to ask questions to clarify at any point."
If a candidate worked on it for an hour or two, and submitted a partially complete application, didn't fulfil the requirements etc... I'd still take the time to read what they wrote & make an informed decision about the next steps. If you were to write good code, but slowly, I'd still want to talk to you (maybe there's some personal reason like your new born baby that kept screaming in your ear). Half a submission still lets me see what I'm looking for, so it's always better than no submission at all.
I've honestly never been asked that... though if someone did, say, ahead of the take-home test for a Senior position... I have enough examples of good/bad that we could demo both sides of everything Uncle Bob talks about, for example. Despite our legal obligations, it wouldn't be hard to find some method to demonstrate that doesn't expose more information than needed, and worst case, I might have to lightly refactor some things for the purpose of sharing.
And this one is out of order on purpose:
I completely get your point, and one candidate I talked to recently felt the same way. Their response to the test was "I already have my own CRUD application using the same tech stack, hosted publicly on GitHub" - so they skipped the test & I reviewed the work they'd already done.
Some industries, yes, having someone sit at a desk, talk to the team, get paid and get given free coffee etc all day is do-able. Unfortunately, I still work in a "dino industry" (it was only in recent months that the development team were allowed to see logs from the Production system, owing largely to the InfoSec policy).