Why do you think the time is wasted? Why do you think no-one will use the application? How else is a hiring manager supposed to judge your skill (apart from resume & your word)?
As a point of reference, I give juniors two technical questions during a Skype call. One is "fix the bugs" (spoiler, there's a missing semi-colon) and the other is "fix the bugs & optimise the solution."
That last question is a little evil really, because it's deliberately designed so that it's impossible. Test #1 proves you know the language, Test #2 tells me what you do when you don't understand how to improve something.
My senior test, is a list of maybe 7 requirements, and they're given a week before interview. People already employed that have tried the test can do it in a little over an hour & give a passable solution. Some candidates I've talked to have taken around a day (7 hours), mostly because of the "showing off" during an interview factor.
Why do you think the time is wasted? Why do you think no-one will use the application? How else is a hiring manager supposed to judge your skill (apart from resume & your word)?
(EDIT: This goes mostly for over the weekend homework type tasks described in the article, not the smaller things you described in your comments that happen during an interview.)
By not being a complete dick and compensating the possible future employee for their work?
How about just having someone work for a day or two? They get paid, you get some extra help around and, if you end up hiring them, the'll already have those days of experience in the new environment and will be as productive on day 1 as they would otherwise have been on day 3. Everybody wins.
And even if you're not going to pay for that short time, at least it's a two-way thing and the applicant also gets a better impression of the company, so they still benefit more than with the one-sided interrogation mirror of a weekend homework.
Conclusion: Stop treating software engineers like schoolkids.
Lets keep this both civil, and to the point shall we.
All applicants have to send their resume. From there, I make a decision about seniority.
Applicants for a Junior position on my team get ONE Skype call (set at an hour, but we can be a little flexible). During that call, we cover everything, including a two question technical test. After said call, we make a decision and either hire them or reject them.
Applicants for a Senior position on my team have a take-home test to do. A passable solution can be done in an hour and change. We allow a week for the turn around time, and it's a simple "Create a CRUD application that has 3 entities, use your own judgement for test coverage and documentation." After that, they get an interview, and in some cases, that is set at 4 hours.
Neither of those are "work" and neither of them are paid. Nor will they ever be.
So, kindly explain (and I've censored for you) how you think I'm being a d*ck? The compensation is the feedback I give (I've lost count of the times that Senior applicants have replied to the feedback with "thanks, I've learnt some things I can take with me").
Re "just having them work for a day or two" - lets skip the domain specifics, having someone new in the office means onboarding them. It means other people on the team have to invest time & energy into that candidate, and as a result, they're not working on the projects we get paid for. If we're talking about a junior candidate, I wouldn't expect them to be productive for at least a week. If we're having them work in the office, it means the desk, the laptop, the network all need to be setup in advance, for someone we may not hire.
Now lets factor in the legalities... lets say I've hired you. I have a fresh laptop sitting on your desk, fully setup with relevant permissions on the network, and I've even installed your favourite IDE into your user profile. You cannot access the building without signing security paperwork, and you cannot (legally) access the floor where your laptop is until you've signed even more paperwork. Allowing time for you to read that paperwork before signing, it's after lunch time on your first day before you even get to touch your laptop.
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"
I completely understand that other employers might not act the way I do, but lets not tar everyone with the same brush, shall we? (My style is actually modelled on an interview I went through as a candidate, where I had a 45min chat, some whiteboard drawing, and a 50min paired programming exercise)
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).
I'm currently hiring for a team (not front end).
Why do you think the time is wasted? Why do you think no-one will use the application? How else is a hiring manager supposed to judge your skill (apart from resume & your word)?
As a point of reference, I give juniors two technical questions during a Skype call. One is "fix the bugs" (spoiler, there's a missing semi-colon) and the other is "fix the bugs & optimise the solution."
That last question is a little evil really, because it's deliberately designed so that it's impossible. Test #1 proves you know the language, Test #2 tells me what you do when you don't understand how to improve something.
My senior test, is a list of maybe 7 requirements, and they're given a week before interview. People already employed that have tried the test can do it in a little over an hour & give a passable solution. Some candidates I've talked to have taken around a day (7 hours), mostly because of the "showing off" during an interview factor.
(EDIT: This goes mostly for over the weekend homework type tasks described in the article, not the smaller things you described in your comments that happen during an interview.)
By not being a complete dick and compensating the possible future employee for their work?
How about just having someone work for a day or two? They get paid, you get some extra help around and, if you end up hiring them, the'll already have those days of experience in the new environment and will be as productive on day 1 as they would otherwise have been on day 3. Everybody wins.
And even if you're not going to pay for that short time, at least it's a two-way thing and the applicant also gets a better impression of the company, so they still benefit more than with the one-sided interrogation mirror of a weekend homework.
Conclusion: Stop treating software engineers like schoolkids.
Lets keep this both civil, and to the point shall we.
All applicants have to send their resume. From there, I make a decision about seniority.
Applicants for a Junior position on my team get ONE Skype call (set at an hour, but we can be a little flexible). During that call, we cover everything, including a two question technical test. After said call, we make a decision and either hire them or reject them.
Applicants for a Senior position on my team have a take-home test to do. A passable solution can be done in an hour and change. We allow a week for the turn around time, and it's a simple "Create a CRUD application that has 3 entities, use your own judgement for test coverage and documentation." After that, they get an interview, and in some cases, that is set at 4 hours.
Neither of those are "work" and neither of them are paid. Nor will they ever be.
So, kindly explain (and I've censored for you) how you think I'm being a d*ck? The compensation is the feedback I give (I've lost count of the times that Senior applicants have replied to the feedback with "thanks, I've learnt some things I can take with me").
Re "just having them work for a day or two" - lets skip the domain specifics, having someone new in the office means onboarding them. It means other people on the team have to invest time & energy into that candidate, and as a result, they're not working on the projects we get paid for. If we're talking about a junior candidate, I wouldn't expect them to be productive for at least a week. If we're having them work in the office, it means the desk, the laptop, the network all need to be setup in advance, for someone we may not hire.
Now lets factor in the legalities... lets say I've hired you. I have a fresh laptop sitting on your desk, fully setup with relevant permissions on the network, and I've even installed your favourite IDE into your user profile. You cannot access the building without signing security paperwork, and you cannot (legally) access the floor where your laptop is until you've signed even more paperwork. Allowing time for you to read that paperwork before signing, it's after lunch time on your first day before you even get to touch your laptop.
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"
I completely understand that other employers might not act the way I do, but lets not tar everyone with the same brush, shall we? (My style is actually modelled on an interview I went through as a candidate, where I had a 45min chat, some whiteboard drawing, and a 50min paired programming exercise)
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).
Glad to see the hiring process moving away from writing algorithms about prime numbers or fibonacci series (using a terrible online IDE).
Thanks. I changed it because I also hate those online IDEs.
Though I'll hold my hand up, the junior test still talks about perfect primes. But that's in test #2.