The title is a little click-baitey, because it suggests full on assault on homework. The actual post is more measured in its criticisms, but basically the idea is: don't use homework as a cop-out for not having a good interview process, and thereby likely wasting everyones time.
Personally I like homework, because it allows me to show my strengths (actually writing code that is solid) without being "under the gun" in terms of interview pressures. I love being able to discuss the code I wrote and talk about areas it can be expanded and improved, and why certain decisions were made. In my mind, that process is closer to the job I'm often interviewing for than questions like "explain why Bellman-Ford uses v-1 relaxations"
Ya I agree, I was all ready to blast it but then realized it had a couple good pointers in the case that you are gonna offer homework.
I do disagree with the premise though. As someone who's worked in the tech field for 15+ years and has been on plenty of interviews, I for one would much rather do a short homework assignment than have to stand in front of a few people and white board shit in real-time.
Here are reasons why it's a solid idea:
1. Way more closely simulates a real work environment. I've never had a job where I get the assignment moments before I have to code it, use a whiteboard to write code, am severely time-boxed and have a group of people watch me work.
2. More inclusive. Your work stands out more when someone isn't making judgements based on looks, age, gender, etc.
3. If you complain about having to spend a couple hours outside the interview on work, maybe you don't really want the job that bad enough. People will spend weeks on an unpaid open-source project but then complain about 2 hours for something that might get them a great job.
Having said that, I agree with you also that the interview can be a great time to go over the homework and ask questions, talk about why a particular strategy was chosen, etc.
I would personally love to see more interviews go away from whiteboards and more towards homework.
Spot on daenz. As with everything, as long as people (if we can call those who work in HR people - see: 'note' below) allow consideration and thoughtfulness to guide their policies and practices, things will usually be agreeable for all involved.
Speaking from experience, shooting 1~2 very detailed hypothetical situations (i.e. 'homework') to a candidate 1 hour prior to their interview and asking them to think of responses to a few 'hard questions' that they will be asked to 1) answer and 2) explain their reasoning during the interview tends to work well. This usually reduces candidate anxiety, helps the evaluating committee get a better look at the candidate's approach to problem solving and validates (or not) their previous experiences, and improves the flow and time management of interview itself.
Note: I'm a senior recruitment manager within the corporate HR Team of a Korean Engineering & Construction firm
Totally agree with you! I prefer "homework" too. It's a bit crazy trying to solve an Interaction design problem on the spot, while people sit there and watch. On the job, designers never do this unless they're working in a group .
P.S. I really suck at writing on whiteboards, it feels like my handwriting transforms into one of an 8 year old.
The article is clear: homework is the best approach from the perspective of company time. That this practice is widespread should be interpreted as a lopsided labor market with a glut of supply (workers) and limited demand (companies).
>Candidates spend many hours completing homework assignments for companies which are not sufficiently interested in them. This is abusing candidates. Knock it off.
Given a choice of spending 2-3 hours on a take home assignment vs. 1 hour of writing code on a whiteboard in front of 3 or more developers, I'd choose the former any day. It's not even close.
The author is taking one end of the spectrum and painting it as an endemic problem. It's not that.
edit: my strong preference for homework vs whiteboarding is because that's how I've solved problems and accomplished tasks for years. Whiteboarding to "see how I think" is not at all how I would think if I were work for them.
The problem is effort asymmetry. For in-person interviews, company must spend as much time as candidate is spending in evaluation. If homework thing becomes standard, I'm afraid that will become first line of filtering because it doesn't cost much to company. So you will still get in-person interview and may be even bit of whiteboarding (to make sure your friend didn't took test for you or somehow you cheated out by getting questions before hand).
You can look at the test process in terms of game theory where one player deals with several players who are not all equally qualified and have incentive to get the prize. So the adversarial mechanics will eventually ensue and folks will try to "game" the system. If you invent whiteboarding as defence, folks will try to invent leetcode as counter measure. If you invent homework as defence, you can bet sites pop all over that allows you to search problem and frameworks and download the common solutions with a click.
I completely agree with that. However, at least in my experience, the take home assignment was used to replace one or all the phone screens. So it was always an elimination round until getting to the whiteboarding sessions.
I would especially like to call out Uber on that as a couple of years ago they wanted me to write some local public transportation service endpoint integrated with Google maps in order to get to the onsite interview. Told them I don't have time for that with my full time job and they just shrugged and were like 'ok, no worries, we look forward to seeing you on X'. So I guess it was also a sucker elimination round.
If there really is a developer shortage that we're always hearing about, then why don't more developers say "f. you" and walk away from homework assignments, 5-round interviews, cubicle farms instead of offices, etc. It would be a self-correcting problem -- companies that wanted good candidates would stop doing this shit. The only explanation I can come up with is that the developer shortage doesn't exist. Maybe it's a developer glut but we don't realize it yet?
I think it's because the average developer is the not the most socially dominant or forward person. They probably tend towards the introvert side of life, and so they want people to like them.
Excellent observation. We should all be asking ourselves why the laws of supply and demand aren't asserting themselves in the software development space. From what I see, companies are aggressively forcing rates lower and doubling down on insanely obtuse hazing rituals.
If demand were truly inelastic (what a "shortage" would imply) then rates/salaries would be rising and the on-boarding processes would streamline.
Their behavior appears to telegraph that there is no actual shortage.
> why don't more developers say "f. you" and walk away from homework assignments, 5-round interviews, cubicle farms instead of offices, etc
Some of us do and some of us don't find it all that terrible. I've declined interviews with homework and told the company I didn't think their interview process was reasonable. Companies are looking for leaders in addition to code monkeys - having a stance on what's reasonable that you can support and explain in a professional manner might lose you a few job opportunities, but it might also win you some respect and serve as a signal that you're mature enough to evaluate the landscape and make judgement calls about what actually is reasonable, which is something managers (people leaders) and architects (technical leaders) do on a day to day basis.
On the other hand, I find whiteboarding to be fairly reasonable for most candidates. I recognize that are a few candidates with social anxiety problems who might only be able to perform ubder an alternate process but in these cases, I think it's reasonable for the candidate to ask and then for the company to accommodate.
This is a complex issue, but one key component is this the relative bargaining powers of the parties [1].
Supply and demand in the job market is only one component of the bargaining power. Social norms and many other factors play in.
The field of Organizational Ecology [2] also can offer some metaphors about what is happening. Both herd behavior and organizational inertia are significant factors that explain how companies interview.
Because ultimately the number of people who get really upset by interview process is small. Developers largely care about being paid large sums of money. Issues like open office design and take home work are tolerable when you are paid 300k.
As a candidate, I kind of like the homework thing. It's a lot closer to what you'd actually be doing on the job compared to white board tests, and interviewing is a pretty big time commitment on both sides so I don't feel taken advantage of if it's not crazy (the interviewer has to spend a lot of time on it too)
Also, I think it's really a stretch to call it abusive. If you feel like the test is too much of a time commitment or you don't think the company is serious, you can just not do it you know?
As someone who sat in interviews on the hiring side (or in the office with a colleague they hired) I must say that there homework was the best predictor for a candidates performance. CV, resume, does often not say much about a candidates programming skill and style.
I think for some candidates it really was a way to get hired when we wouldn't bothered to invite them for an interview (across the country).
I do think homework shouldn't be send out as a default by the recruiter. And the hiring party should make clear about the intention.
A homework should not be done on company product code, and it should be in some way standardized, i.e. we had a pool of 4 homework exercises that we send out depending on profile.
As a candidate I like these exercises if they are not too big. I have applied somewhere once and they asked me to read a 16 pages journal article within 4 days, to present. (It was not a job in academia but industry). In the end I think I was rejected because coming from a different field than the interviewer I emphasized the wrong aspects for him. They were not aware of some aspects I presented and would have expected from a candidate. So there is a danger in vetting candidates this way. Just because you have them time, they don't need to be a copy of you .
Something that takes an evening (whether code, writing, etc.) seems generally reasonable assuming that it serves as a reasonably effective screener. After all, some homework for an interview such as researching the company and their market space is typical. Something that takes 40 hours? Not so much.
My company, a fully remote consulting firm, uses test projects for some candidates whose skills we cannot fully evaluate using the code samples they have submitted. We only use test projects under conditions designed to skirt the clear pitfalls mentioned in this article.
- We pay all candidates for the test project, whether they pass or fail. The original article did not mention paying for homework, which we concluded was the only fair way to treat the excess time candidates spend helping us make a decision.
- Passing the test project means you move on in the process; we don't knowingly pit two candidates against each other.
- The project and a corresponding scoring rubric are predefined by position.
I also think paying for the time is the only way it can be fair, in particular for more experienced candidates who will resent the time wasted as opposed to junior candidates who could see it as being given an opportunity.
This lines up with what I finally concluded (and blogged about) as well - find some small, somewhat isolated project and pay them for it. My preference would be for it to be a project you actually intend to use, especially if they also need to interact with your team in some small way. This way you get to actually seem them in action - how do they communicate, what questions do they ask, how do they approach the project. You see the candidate in the context in which you intend for them work.
It'd be interesting to see paying candidates for there time during an interview process to be used as a form of money laundering...
"So please explain to me what you did to attract 121,498 applications for this job, the reasoning behind paying $500 to each & every applicant for the the time they spent interviewing, and why each applicant has a name like John Doe1, John Doe2, John DoeN, etc."
I recently did a homework assignment as the first step in an application process, and I didn't find it inappropriate or untoward at all. It's certainly not abusive, I don't understand why the author used this term. It got me through to the second step, a video conference interview with a couple developers and a chance to go over my code, explain my reasoning, answer some challenge questions, etc, in other words, tech screening. I didn't end up getting the position, but at no point did I feel my time was being wasted or that I was being disrespected.
You received a response. What if you hadn't? How many hours did you invest? How many of these would you be willing to attempt if you never got a response of any kind? When the author speaks of abuse, I believe -- in part -- this is what they're trying to highlight. For every submissions, like yours, that gets a response, there are probably hundreds that hear absolutely nothing.
I'm OK, within reason, with these homework assignments if they come after some kind of initial screening where the company has shown at least the minimum level of interest.
However, as the very first step, it feels off to me.
I've been burned in too many interviews for this kind of homework garbage. I simply won't do it, if someone wants to waste 1-4 hours on something, go for it. My apps/etc I build should be enough to see my work.
I don't want to waste 1-4 hours for every job I apply to, especially when I'm not one of the final candidates. I'm often blown off for not being caucasian enough or liking whatever sportsball team or brand of music the rest of the crew is into. To often I feel I'm thrown into interviews because they need to interview 7-10 people. Same with interviews without phone screening, there are lots of questions I can ask that can save both me and the employer time and money by doing a phone screen first instead of driving to their place (mostly talking about 30+ minute or hour long drives). I've been burned too many times with things they forget to mention that make it a job not even worth my time (required 60hr work week, mandatory overtime, etc) things I can find out with a screening.
Let’s compare this to a recent experience I had with a recruiter from Square. Among other things, I was told that in a 1 hour phone screen, I was to write code as if it were production code, and not “just interview hacking.” She also suggested I read Cracking the Coding Interview ! For a phone screen!
I think this is frankly ridiculous. What do you think the rest of the interview process is like? At best, it’s cargo culting. At worst, it’s abuse.
Edit: I should add that no guidance was given as to what the standards for “production code” in this phone screen were.
The Facebook recruiter told me that "successful candidates spend an average of 10-15 hours preparing"...for a 45 minute phone screen. For the onsite you're expected to spend a few weeks reading CtCI and working through the practice problems.
At Sourcegraph we faced the same decision and decided to go with an option for paid “homework” projects. It’s working very well so far. The payment is an important element of respect. More info at https://about.sourcegraph.com/blog/our-project-based-intervi....
Paying shows you have skin in the game, value the candidates time, and you are not just handing out a ton of take home projects to every one who applied. I am sure some companies have the money to do so, but generally I think that is not the norm.
Off topic/curious: Is the take home project expected to be honor system 'closed book/closed internet'?
I had a friend that did an interview homework assignment, was declined for the job, then found out that they used his assignment's code in production through a friend that already worked at the company.
While I'll admit that this is atypical, it seems like something a more nefarious company could abuse.
I can't help but think that candidate should feel lucky to have escaped that car crash. Think about how hard up your company would have to be to ship code that someone else has written with no warranty, no support and not even the knowledge that their code would go into production. Just yuck!
I've only interviewed with one company that did a homework assignment "right" - it was time constrained, it was after an initial phonescreen, I was still more on the junior side, and the onsite interview included a follow up on the homework assignment to extend it in some way.
But generally, I agree. There are enough other ways to screen people for basic competency (20 min tech conversation, looking at StackOverflow profiles, etc.) that it seems unnecessary for anyone except junior developers.
I'd rather have a weekend homework assignment than a loop of coding interviews. Much more reasonable assessment of skills & potential, in my opinion. Happy to do whatever algorithm madness thrown my way in that case. It's a real tough gig to solve some ambiguous algorithm problem in 40 minutes on a whiteboard, analyse it, and then discuss optimality. Gets worse if the loop is serial algorithms interviews.
I have had great success giving out a very simple homework assignment before in-person interviews. I ask you to write me a class which will score a bowling game. Just hard enough to show me that you know how to code, but not so difficult that you will spend hours working on it. Gives us something to talk about while I figure out if your personality will be a good fit with the rest of our team (because really, that's number one on my priority list).
I'm biased, I suppose, because I loathe algorithm questions in interviews or whiteboard coding. Neither does a good job of letting me show you I'm not an idiot.
Or as an alternative -- give them something legitimately beneficial to your company to work on, pay them standard consulting rates. This puts the impetus on the company to have fairly high certainty the candidate is qualified before the take-home, and the candidate gets compensated for their time even if a hire isn't made.
We only do homework as a final screening test for candidates. If it's any more than a simple project, we pay them standard rates. That way no one feels taken advantage of. Plus, if they bomb it and they're getting paid for it then you KNOW they're not the right candidate, even if every other test was aced, so it really is an excellent tool for us. But again, ONLY at the end of the process when we're making a final decision between, most likely, two candidates.
This is really not that hard to do right in my opinion. This is what we did for a "homework assignment" after a 30 minute phone and 30 minute team screen were already done:
1. Supervisor had candidate sign mutual-NDA, work for hire at $X/hr rate & IP assignment agreement on docusign.
2. Potential future supervisor gave the candidate access to a repo and assigned a production task that should take less than 10 hours to complete.
3. Candidate does the assignment, communicates with supervisor via email/repo where necessary and a check gets cut for the hours worked.
A lot of the commenters here are saying they like homework assignments because it’s a test that’s similar to the job, more so than solving a problem on a white board with no resources and a group of people watching you. I agree with all of that. Here’s where homework assignments are abusive- when they reject you with no critique of your work whatsoever. That’s been my experience, and it’s total, disrespectful bullshit.
If I spend time on your made up assignment, you owe me a detailed response that shows that you actually looked at my work and can critique it credibly.
The article has a bit of a weird structure. The premise is that homework is abusive. And the final bullet points elide the exceptions to this rule... which seem broad enough to make the premise weak.
Using homework as a first-pass screen in your interview process, unchecked, is definitely a smell that you're not using this tool appropriately.
However I use it in the process I've set up successfully as a way to give me something to code-review with a candidate when we do a final interview. It's a small, limited scope project. We give plenty of time to finish it. And the chances are good if you complete it we'll give you a final interview.
I find it helpful because I don't have to make assumptions about the candidates knowledge and skill level from a cold-start. I can ask them questions based on their code. How did you interpret this requirement?What trade-offs did you consider when you chose this data-structure? Etc. If their code shows an aptitude for computer science fundamentals I can ask them questions about algorithmic complexity in Big-O notation or I can scale it back and see if they understand the same concept using more descriptive means. Conducting an interview is hard if you don't have a starting point for a conversation.
For more experienced candidates with a history of open-source work do consider allowing them to present their own code in place of your standard homework assignment. It has the same effect and shows that you respect them enough to review their work. I think that's rather nice.
I probably won't ever do a homework assignment again, unless I feel like I absolutely have to. It's not just the time involved, it's the time involved plus the apparent necessity for me to ask what the results were.
It seems obvious to me that if a company asks an applicant to do a homework project, then when the applicant submits the project, the evaluation and feedback (positive or negative) should happen automatically and quickly.
Last time I went around interviewing, companies that passed out homework basically front-loaded the candidate time commitment so that they only had to put in their own time if the candidate looked promising.
The homework was not bad in itself, but was a symptom of a larger problem. Namely, the company was unwilling to invest equal energy into the interviewing process as their candidates. So my first impression of the company was that it was full of brusque assholes that valued their time more than mine. It seemed patronizing.
This was certainly also possible without homework, as in the case of the companies that wanted me to disclose my salary expectations up front, without disclosing what they expected to pay the median candidate. They wanted to reject quickly, so they could reject more candidates, and finally get to the good one that they'd want to hire. As the article author might put it, don't use an evaluation tool as a screening tool.
Link is (2013). As a further note, the writer is Gayle Laakmann McDowell, author of CTCI (Cracking the Coding Interview), which might explain its covertly pro-whiteboard interview stance. Though I agree with the comments saying that her actual criticisms aren't as clickbait or absolutist as the title makes it sound.
[+] [-] daenz|7 years ago|reply
Personally I like homework, because it allows me to show my strengths (actually writing code that is solid) without being "under the gun" in terms of interview pressures. I love being able to discuss the code I wrote and talk about areas it can be expanded and improved, and why certain decisions were made. In my mind, that process is closer to the job I'm often interviewing for than questions like "explain why Bellman-Ford uses v-1 relaxations"
[+] [-] chaddattilio|7 years ago|reply
I do disagree with the premise though. As someone who's worked in the tech field for 15+ years and has been on plenty of interviews, I for one would much rather do a short homework assignment than have to stand in front of a few people and white board shit in real-time.
Here are reasons why it's a solid idea:
1. Way more closely simulates a real work environment. I've never had a job where I get the assignment moments before I have to code it, use a whiteboard to write code, am severely time-boxed and have a group of people watch me work.
2. More inclusive. Your work stands out more when someone isn't making judgements based on looks, age, gender, etc.
3. If you complain about having to spend a couple hours outside the interview on work, maybe you don't really want the job that bad enough. People will spend weeks on an unpaid open-source project but then complain about 2 hours for something that might get them a great job.
Having said that, I agree with you also that the interview can be a great time to go over the homework and ask questions, talk about why a particular strategy was chosen, etc.
I would personally love to see more interviews go away from whiteboards and more towards homework.
[+] [-] EduardoBautista|7 years ago|reply
[+] [-] JustMatthew|7 years ago|reply
Speaking from experience, shooting 1~2 very detailed hypothetical situations (i.e. 'homework') to a candidate 1 hour prior to their interview and asking them to think of responses to a few 'hard questions' that they will be asked to 1) answer and 2) explain their reasoning during the interview tends to work well. This usually reduces candidate anxiety, helps the evaluating committee get a better look at the candidate's approach to problem solving and validates (or not) their previous experiences, and improves the flow and time management of interview itself.
Note: I'm a senior recruitment manager within the corporate HR Team of a Korean Engineering & Construction firm
[+] [-] sxp62000|7 years ago|reply
P.S. I really suck at writing on whiteboards, it feels like my handwriting transforms into one of an 8 year old.
[+] [-] TAForObvReasons|7 years ago|reply
[+] [-] strict9|7 years ago|reply
Given a choice of spending 2-3 hours on a take home assignment vs. 1 hour of writing code on a whiteboard in front of 3 or more developers, I'd choose the former any day. It's not even close.
The author is taking one end of the spectrum and painting it as an endemic problem. It's not that.
edit: my strong preference for homework vs whiteboarding is because that's how I've solved problems and accomplished tasks for years. Whiteboarding to "see how I think" is not at all how I would think if I were work for them.
[+] [-] sytelus|7 years ago|reply
You can look at the test process in terms of game theory where one player deals with several players who are not all equally qualified and have incentive to get the prize. So the adversarial mechanics will eventually ensue and folks will try to "game" the system. If you invent whiteboarding as defence, folks will try to invent leetcode as counter measure. If you invent homework as defence, you can bet sites pop all over that allows you to search problem and frameworks and download the common solutions with a click.
[+] [-] decebalus1|7 years ago|reply
I would especially like to call out Uber on that as a couple of years ago they wanted me to write some local public transportation service endpoint integrated with Google maps in order to get to the onsite interview. Told them I don't have time for that with my full time job and they just shrugged and were like 'ok, no worries, we look forward to seeing you on X'. So I guess it was also a sucker elimination round.
[+] [-] murukesh_s|7 years ago|reply
Someone nailed it finally
[+] [-] wilsonnb3|7 years ago|reply
As long as the interviewer isn't a stickler for correct syntax when I'm writing stuff on the whiteboard.
[+] [-] mysterypie|7 years ago|reply
[+] [-] grecy|7 years ago|reply
That means they're easy to push around.
[+] [-] nybblesio|7 years ago|reply
If demand were truly inelastic (what a "shortage" would imply) then rates/salaries would be rising and the on-boarding processes would streamline.
Their behavior appears to telegraph that there is no actual shortage.
[+] [-] will4274|7 years ago|reply
Some of us do and some of us don't find it all that terrible. I've declined interviews with homework and told the company I didn't think their interview process was reasonable. Companies are looking for leaders in addition to code monkeys - having a stance on what's reasonable that you can support and explain in a professional manner might lose you a few job opportunities, but it might also win you some respect and serve as a signal that you're mature enough to evaluate the landscape and make judgement calls about what actually is reasonable, which is something managers (people leaders) and architects (technical leaders) do on a day to day basis.
On the other hand, I find whiteboarding to be fairly reasonable for most candidates. I recognize that are a few candidates with social anxiety problems who might only be able to perform ubder an alternate process but in these cases, I think it's reasonable for the candidate to ask and then for the company to accommodate.
[+] [-] dj-wonk|7 years ago|reply
Supply and demand in the job market is only one component of the bargaining power. Social norms and many other factors play in.
The field of Organizational Ecology [2] also can offer some metaphors about what is happening. Both herd behavior and organizational inertia are significant factors that explain how companies interview.
[1] https://en.wikipedia.org/wiki/Inequality_of_bargaining_power
[2] https://en.wikipedia.org/wiki/Organizational_ecology
[+] [-] UncleMeat|7 years ago|reply
[+] [-] overgard|7 years ago|reply
Also, I think it's really a stretch to call it abusive. If you feel like the test is too much of a time commitment or you don't think the company is serious, you can just not do it you know?
[+] [-] wirrbel|7 years ago|reply
I think for some candidates it really was a way to get hired when we wouldn't bothered to invite them for an interview (across the country).
I do think homework shouldn't be send out as a default by the recruiter. And the hiring party should make clear about the intention.
A homework should not be done on company product code, and it should be in some way standardized, i.e. we had a pool of 4 homework exercises that we send out depending on profile.
As a candidate I like these exercises if they are not too big. I have applied somewhere once and they asked me to read a 16 pages journal article within 4 days, to present. (It was not a job in academia but industry). In the end I think I was rejected because coming from a different field than the interviewer I emphasized the wrong aspects for him. They were not aware of some aspects I presented and would have expected from a candidate. So there is a danger in vetting candidates this way. Just because you have them time, they don't need to be a copy of you .
[+] [-] ghaff|7 years ago|reply
[+] [-] netaustin|7 years ago|reply
- We pay all candidates for the test project, whether they pass or fail. The original article did not mention paying for homework, which we concluded was the only fair way to treat the excess time candidates spend helping us make a decision.
- Passing the test project means you move on in the process; we don't knowingly pit two candidates against each other.
- The project and a corresponding scoring rubric are predefined by position.
[+] [-] kokey|7 years ago|reply
[+] [-] poulsbohemian|7 years ago|reply
[+] [-] PopeDotNinja|7 years ago|reply
"So please explain to me what you did to attract 121,498 applications for this job, the reasoning behind paying $500 to each & every applicant for the the time they spent interviewing, and why each applicant has a name like John Doe1, John Doe2, John DoeN, etc."
[+] [-] jasonincanada|7 years ago|reply
[+] [-] nybblesio|7 years ago|reply
I'm OK, within reason, with these homework assignments if they come after some kind of initial screening where the company has shown at least the minimum level of interest.
However, as the very first step, it feels off to me.
[+] [-] fartbucket|7 years ago|reply
I don't want to waste 1-4 hours for every job I apply to, especially when I'm not one of the final candidates. I'm often blown off for not being caucasian enough or liking whatever sportsball team or brand of music the rest of the crew is into. To often I feel I'm thrown into interviews because they need to interview 7-10 people. Same with interviews without phone screening, there are lots of questions I can ask that can save both me and the employer time and money by doing a phone screen first instead of driving to their place (mostly talking about 30+ minute or hour long drives). I've been burned too many times with things they forget to mention that make it a job not even worth my time (required 60hr work week, mandatory overtime, etc) things I can find out with a screening.
[+] [-] pmiller2|7 years ago|reply
I think this is frankly ridiculous. What do you think the rest of the interview process is like? At best, it’s cargo culting. At worst, it’s abuse.
Edit: I should add that no guidance was given as to what the standards for “production code” in this phone screen were.
[+] [-] rabidrat|7 years ago|reply
[+] [-] sqs|7 years ago|reply
[+] [-] deskamess|7 years ago|reply
Off topic/curious: Is the take home project expected to be honor system 'closed book/closed internet'?
[+] [-] mplewis|7 years ago|reply
[+] [-] tombert|7 years ago|reply
While I'll admit that this is atypical, it seems like something a more nefarious company could abuse.
[+] [-] slivym|7 years ago|reply
[+] [-] phyzome|7 years ago|reply
[+] [-] FlipperBucket|7 years ago|reply
[+] [-] jkingsbery|7 years ago|reply
But generally, I agree. There are enough other ways to screen people for basic competency (20 min tech conversation, looking at StackOverflow profiles, etc.) that it seems unnecessary for anyone except junior developers.
[+] [-] pnathan|7 years ago|reply
[+] [-] rootusrootus|7 years ago|reply
I'm biased, I suppose, because I loathe algorithm questions in interviews or whiteboard coding. Neither does a good job of letting me show you I'm not an idiot.
[+] [-] madisonmay|7 years ago|reply
[+] [-] heyyyouu|7 years ago|reply
[+] [-] AndrewKemendo|7 years ago|reply
1. Supervisor had candidate sign mutual-NDA, work for hire at $X/hr rate & IP assignment agreement on docusign.
2. Potential future supervisor gave the candidate access to a repo and assigned a production task that should take less than 10 hours to complete.
3. Candidate does the assignment, communicates with supervisor via email/repo where necessary and a check gets cut for the hours worked.
4. Hire/No Hire decision made
Should take less than a week in total.
[+] [-] ghaff|7 years ago|reply
This would be a violation of the candidate's employment contract at many companies.
[+] [-] teh_infallible|7 years ago|reply
If I spend time on your made up assignment, you owe me a detailed response that shows that you actually looked at my work and can critique it credibly.
[+] [-] agentultra|7 years ago|reply
Using homework as a first-pass screen in your interview process, unchecked, is definitely a smell that you're not using this tool appropriately.
However I use it in the process I've set up successfully as a way to give me something to code-review with a candidate when we do a final interview. It's a small, limited scope project. We give plenty of time to finish it. And the chances are good if you complete it we'll give you a final interview.
I find it helpful because I don't have to make assumptions about the candidates knowledge and skill level from a cold-start. I can ask them questions based on their code. How did you interpret this requirement? What trade-offs did you consider when you chose this data-structure? Etc. If their code shows an aptitude for computer science fundamentals I can ask them questions about algorithmic complexity in Big-O notation or I can scale it back and see if they understand the same concept using more descriptive means. Conducting an interview is hard if you don't have a starting point for a conversation.
For more experienced candidates with a history of open-source work do consider allowing them to present their own code in place of your standard homework assignment. It has the same effect and shows that you respect them enough to review their work. I think that's rather nice.
[+] [-] curtis|7 years ago|reply
It seems obvious to me that if a company asks an applicant to do a homework project, then when the applicant submits the project, the evaluation and feedback (positive or negative) should happen automatically and quickly.
[+] [-] logfromblammo|7 years ago|reply
The homework was not bad in itself, but was a symptom of a larger problem. Namely, the company was unwilling to invest equal energy into the interviewing process as their candidates. So my first impression of the company was that it was full of brusque assholes that valued their time more than mine. It seemed patronizing.
This was certainly also possible without homework, as in the case of the companies that wanted me to disclose my salary expectations up front, without disclosing what they expected to pay the median candidate. They wanted to reject quickly, so they could reject more candidates, and finally get to the good one that they'd want to hire. As the article author might put it, don't use an evaluation tool as a screening tool.
[+] [-] Apocryphon|7 years ago|reply