I've been in that spot. Not quite 50 hours, but and not exactly ghosted, put a lot of real time and dedication into a lengthy project and questionnaire, to get back a 'no, sorry'.
I responded for some clarification: Where could I improve? What would make me a more attractive candidate? Nothing. We're a pretty close-knit tech community (Boulder) so it felt like a real slap in the face.
I manage dev hiring at my company, and when I give take-home assignments, I make sure to give them a timeline of no more than 2 hours. If you get to that point, it's okay to tell me what you would have done, as I should be able to tell by that point if you know what you're doing and could accomplish it.
"Busy" is not an excuse. If you've got the time to interview someone, you make the time to treat them respectfully and provide quality feedback.
I'll echo this issue with certain companies on the Frontrange. It's good to see that I'm not the only one that is disappointed at the behavior. I'll agree with others, that it's the 'litigious' nature of CO that prevents the feedback and fear of lawsuits. That said, if the company is that afraid, then the mangers must know that the good hires out there have been burnt a few times by now and know that the time they put in will be wasted. You may as well just throw out the tests at this point and focus on networking. You'll only garner fools and the desperate with these tests, with a 'lucky' few that will prove exceptions to the rule, not the other way around. Frontrange tech is small and very close knit (there are only so many good breweries around here yall!), word gets out fast.
I always hear warnings about how this opens you up to very scary legal liability, but I'm wondering how true it is. Has anyone ever gotten into trouble providing feedback?
I guess things like "you had no social acumen and your hygiene left too much to be desired to be hireable" wouldn't go over well.
In litigation happy countries, yes, it does open you up but less so if you focus on technical facts pertaining to the job and not any personal issues.
... and, yes, I know of a few cases where honesty was not the best policy. The circumstances were quite possibly valid where others would not have felt comfortable with the individual, and potentially cost the business money, but being honest at that stage was not doing anybody any favors.
In technology, if you believe someone lacks x, y or z, to round out their skill set and you can articulate it without making it personal, I think the recipient will appreciate it - maybe not the same day as they were rejected, but it's always nice to get a perspective from an outside party. If you can't articulate the short comings then maybe focus on the good aspects and then use the generic not today, maybe in the near future kind of response... but you shouldn't ghost them.
I have almost two decades of experience as a software developer, working for a number of big name companies.
First, I will never accept home assignment. There is lots of problems with this even if intentions are good.
I assume this kind of request tells me something about the organization and the manager making the request.
I will ask if it is company policy or local initiative. Sometimes managers just don't know any better.
I would politely explain why I won't comply. I will propose alternative solution which is session over Skype that lets me show how I work while I gather requirements, design, implement and verify the solution
Lastly, I will observe the manager dealing with the unexpected request and grade based on how she deals with it. Remember, they want to got to know you to get better deal, you should do the same.
I would totally do it if it's obviously not for profit. My previous employer asked me to investigate and try to fix a Firefox bug over the weekend; they had nothing to do with Mozilla, and I claimed no prior experience with Firefox (and had none). It was a test of how I would approach a huge codebase. Ended up being a great employer - I learned a lot there and, be all reasonable standards, I got rich doing it.
Why would you not do a paid take home assignment when it's the way your potential employer is approaching hiring? Or do people ask this unpaid? We do paid two hour assignments, I feel like it just helps people show their style. And it's a helpful preview of where to coach them too.
Because any work delivered in such circumstances has no value (it might be done by your friend for all I know). It creates incentive for candidates to waste time polishing the solution. Most importantly, if you are an employer, think you are probably turning away your best candidates as the only ones that will continue are the ones that are OK with this b*t. Maybe they don't know any better or don't have other concurrent offers to work on or they don't have current job or are not putting effort at the current one. In any case it is likely that they are not your best candidate unless you are best employer in the world that they will do anything to work for. Funny thing, best employers in the world don't ask candidates to do home assignments.
If I am on the market I want to find and chase some number of potential offers. Ideally, I will get all those offers at the same time to pick and choose the best of the pack. This all happens while I have other engagements with my current employer, while I am closing projects, etc. I don't have infinite amount of time. A request like that would drain all my available resources and prevent me from taking part in other processes.
It’s good to have folks like you who stand your ground. However, reality is different and unless the company really wants you specifically and the hiring manager has the political capital to change the hiring process like that, it won’t have much effect unfortunately.
Let's talk realistically. In software development world, if you are able to code your way out of a paper bag and are not living at the literal end of the world you are in high demand.
If you don't have lots of experience you don't want to work for crappy company. If you are experienced you already probably saw a lot of dysfunction and you are more likely to figure out how to work in less than ideal environment.
On the other hand, you don't have experience, you want to learn and it is most likely you are going to learn bad habits working at bad company or for bad manager.
Just stay away. There is enough companies to work for that you don't have to choose from the ones that have warning signs all over them.
But in my own reality, My tangible options were:
1. Pay upfront and study endless hours for a whiteboard interview + hours with phone screening + day spent onsite.
2. On-demand take home challenges (vary from 1-2 days, depending on the company)
3. 1-week payed project with presentation at the end
4. Some cocktail mix of the above
Unless you know the founder, senior managers, or have built rapport with most of the engs of a company, I never been able to push back, not even in markets where the demand was extremely high.
In software development world, if you are able to code your way out of a paper bag and are not living at the literal end of the world you are in high demand.
Only if you don't really care what you work on. A lot of people really want to work at specific companies (like Apple or Google) or in a specific field (like finance or games development). In these cases those companies can place a lot higher demands on their applicants and make them jump through a lot more hoops.
If these hoops actually lead to better quality candidates is of course a different question.
I mean do you by all means, but from a hiring perspective this would be behavior we would evaluate negatively in our process. YMMV of course, and you have the right to these choices.
And that's fine as I would not be interested to work for you anyway. For me the prerequisite is mutual ability to work out differences with my future boss. If we can't agree on a detail so fine as the exact process he uses to learn I can program couple of loops how are we going to deal with really challenging problems?
Why would you turn away a candidate that is able to explain why your process is flawed, stand for what he believes and propose a solution that gives both parties what they want. Do you have such surplus of candidates that you can throw away the ones that have spine with impunity? In your case you want to learn if the candidate is able to code and what best way if he shows how he does it while he does it with you sitting beside. Also explaining the process and showing way more like asking for clarification and verifying results with you?
You're kind of cavalierly assuming that everyone agrees with you that the process is flawed. This is definitely a question that reasonable people can disagree about. And if you not only disagree with this hypothetical hiring manager, but you even do it in the fairly arrogant way you're writing now, I wouldn't blame them for passing.
Just to expand a little on why a take-home test could be warranted, I can imagine a few scenarios:
1. You're a Facebook/Amazon/Netflix/Google/Microsoft and you have candidates lined up around the block trying to apply.
2. You're bootstrapped or full on headcount and can afford to take your time and absorb lots of false negatives.
3. You're in a very niche space and know that the few people in the domain are going to be willing to put a ton of work into each and every application. If there were somehow a job that let me play video games and read science fiction while fixing electronics gear on the Moon, of course I'd do a paid take-home assignment for a chance.
Somehow, neither Facebook, nor Amazon, Netflix, Google nor Microsoft give home assignments as a prerequisite for entering into the process.
I can assure you there is no shortage of candidates willing to work for any of them that would take the assignment in a heartbeat.
I can assume the reason they are not giving assignments is what I stated, the hiring process is extremely expensive and it makes absolutely no sense to do stuff that does not give any useful information but may prevent you from ever reaching top candidates that will not let themselves be subjected to this.
The coding assignment has a purpose and the purpose is not to tell if you are world class developer but assure you meeting minimum requirement to be considered for the position. If you give it as home assignment there will be tons of people willing to cheat like getting somebody to do it for you and then explain the solution so that you might pass cursory inspection. Or people who will take inordinate amount of time and spend 50 hours instead of expected 30 minutes you said should be enough.
There is no excuse, the time you spend explaining the assignment and reviewing the results would be better spent setting up a coderpad session (https://coderpad.io/) where you can actually see the person work on the solution and not only the solution itself. Where you can ask questions and have understanding of whether the person is able to solve the problem analytically or writes stuff at random until he finds solution by trial and error.
> Why would you turn away a candidate that is able to explain why your process is flawed, stand for what he believes and propose a solution that gives both parties what they want.
The insecure parse this as a threat to them, if we're being frank.
It also costs them more money, and having you shoulder as much of the burden as possible is part of the short-term-thinkers' goal.
Don't spend 50 hours on a take-home for an interview. Instead, email the company and very politely explain that they're delusional. You probably won't get a response to that either, but at least it takes less time.
Counterpoint, I botched a coding session at a FANG interview. They wanted me so they gave me a take home coding problem. I spent 40+ hours over three days banging it out.
Got the job. 57% increase in compensation. 550k/year combined.
Totally worth it.
Only negative is it's months later and my right shoulder still hurts a bit. Getting old sucks.
Ok, but FANG is a different matter: those are established, respectable companies. You shouldn't do the same for small, no-name startups that try to use those take-home assignments to extract free labor from you.
But I don't interview at companies unless I really need to get in. If it were some lousy startup and I'm interviewing there it's because I am hard up and need the job or it's tactically where I need to be next to get where I am going.
Basically if I am spending the time interviewing I am probably willing to do whatever it takes to get the job.
Which is why if you commit to doing a take home project, you should at least ask how much time they expect the project to take. For a lot of software development projects there is always something to work on and improve if time allows. Parkinsons Law and all. I might be a good idea to exceed their estimate a little to get a more finished product, but that number at least anchors the project timeline. If they legitimately answer with 50 hours, then feel free to laugh in their face. However a 2 or 3 hour project to be completed at some point over 2 weeks seems completely reasonable.
It has been shown that most software estimates are out by a factor of 40% (from what remember). I have a feeling take home exercises will add even more to that due to the initial setup as well.
They gave him two weeks to do it and it was apparently a multi-part thing where it made sense to send in answers to the first part before doing the rest. That doesn't sound like something that's supposed to take 30 minutes.
If it takes 30 minutes then what you do is organize 60 minutes coderpad session and get lots more information than just a solution that the candidate pretends he did in the allotted time.
Having worked at a startup I would not be surprised if they used that assignment in order to get some of their work done. The startup I worked at wanted to use Kaggle competitions in order to improve their AI code that they ripped from other sources (all while the marketing team made them look as if they were a legit company at the top of the field).
> they used that assignment in order to get some of their work done
Yes, that's a common technique. Another, depending on how they found and contacted this startup, is that the test isn't really from the company it claims, the contact person is actually a candidate who is tricking people into completing the take home assignment on his own interview somewhere else. A third technique, when the questions seem like homework questions, is that it can be a student somewhere impersonating a company and posting fake job ads in order to get other people to do his school assignments.
Generally one should verify the company exists and that their contact works at the company before proceeding with these. Also if the assignment appears to be exactly something that would be of great benefit to the company and also takes a good amount of work, it is best to decline as some companies use sham job interviews to get free contract work done.
Friend of mine interviewed for a role where they explained a problem and asked how he would solve it. He spent 90 minutes explaining possible solutions while they made notes. It's a pretty specialist domain so he knew others who were interviewing. After the interviews they pulled the position - I suppose no one will ever know for sure, but after putting their heads together and doing some digging they figured the whole set of interviews was put together to solve a problem the business was having, and it was just an easy way to get a bunch of solutions from very specialist / expensive people.
I actually went in for a job interview as a sys admin. Turns out they were just trying to dig for some information from my current company. Both were pretty in similar domain. I was a junior level so probably didn't prove them with any useful info...
> That in turn is making my life miserable ... anxiety attacks
> Why get someone's hopes high just to fuck them right in the face
> because there were a bunch of typos in it.
Overall if OP manages to process it the right way it'll be a very good life lesson. Never put yourself in such a weak position if you can't accept defeat. Also, if it took him 50 hours, either the task was way to big or he wasn't a fit.
- Spending a lot of time on something doesn't equal success
- Don't get miserable over things that are not in your control [0]
- Don't trust companies, they're money printing machines, not charities.
- Most people don't care about you / your time, unless it's in their direct personal interest
I see your point to not trust companies but even I after over 10 years in this industry sometimes get fooled.
For me personally, I cannot live a skeptical nor cynical life and I usually deal with people not companies. When I start the interview, I get the sense of their people, and if I find them to be decent I move on with the process. Most of the time my expectations are met fortunately. So, I can’t really blame the victim here.
Startups always claim the project will only take 2 hours, but doing a half-decent job takes more like 2 days, and in real-life you'd spend 2 weeks or more on it to do it properly (tests, localization, documentation, performance tuning, etc).
I am not sure how you are supposed to make a choice between doing it quickly and being called "sloppy", taking a realistic time and being called "slow", or any of the points inbetween.
I had a company give me an assignment to create an API for matching an order book. Business logic, web API, “must be production level code”, documentation, set up instructions, and tests. Estimated time: 2-3 hours.
I did it in 6 because I enjoy that sort of work and considered myself fast. I sent it to them along with an email saying there was no way someone could do it in 3, let alone 2, and I wasn’t interested in moving forward.
Yeah, that was definitely part of it. It was a mix of ego and desire to be helpful. I was going to finish the thing anyway, and I knew my feedback would be taken more seriously if I finished it first versus complained up front.
One of the cofounders called and tried to get me to interview, but I explained that between this and the call I’d had with the other cofounder (“What is the lowest possible salary you’d be willing to accept?”) I wasn’t interested.
The best approach is to timebox yourself to 2 hours, and then spend 15 minutes sending it to them and letting them know the next several issues you'd address, along with rough estimates for each.
I'm hunting for a job right now and this stings. I've had multiple companies just stop responding after 2 or 3 interviews. The weirdest one though was the company that after four interviews emailed me to "schedule next steps". The next steps turned out to be telling me they wouldn't be hiring me but to apply again in six months.
I have no problem being rejected but make sure you are actually doing so, a form email is fine. Ghosting me is not, and I don't need a phone call telling me you're not hiring me.
There are definitely people who feel like this, but I'm with your parent poster -- I do not want to have an uncomfortable conversation with you about why you're not giving me an offer. This isn't a breakup. We weren't dating. You can just send me an email.
It's oftentimes better for both parties when rejecting someone to do it via email. The person being rejected isn't put on the spot to compose themselves and be a good sport while the person doing the rejection can manage the response from the person getting rejected (don't have to immediately answer follow ups and/or defend their decision).
My personal favorite when applying for a job. After two phone interviews (the job as in a different country so no on-site interview) with Jeff I was told "Everything sounds great. I'll send you an offer by early next week and we can take it from there". Two weeks pass and I call Jeff, he's not there so I end up talking to Jeff's boss.
Jeff's boss is very confused, and explains that while they had been talking about hiring someone they hadn't made any actual decisions to do so and even if they had been wanting to hire someone now, Jeff was no way in a position to make job offers to anyone.
My best/favorite jobs have come about because of my network (not talking LinkedIn here). I encourage everyone to build a good network with people in the same profession, all over the country (I'm remote), and seek jobs to which you can be referred. Referrals are typically a leap ahead in line, and will get you past the BS gatekeepers.
I try, I really do, but my only referrals have all ended in ghosting by the parent company. Hopefully once I get my first job I can work on building that a little more.
At most I will do a one hour take home or online test. If I am requested to do anything more than that then I will politely decline.
My reasoning is that a potential employer can find out what they want abut me and my skills by looking at my employment history and by speaking to my referees. To invest several hours in a test that carries no guarantee of at least an interview is not an investment I want to make when I could be spending that time with my family, or working on other applications.
Another way of looking at it how I explained it to a recruiter who was annoyed that I wouldn't do his clients weekend coding test. I asked him if he would expect his client (off the shelf software house) to spend 5+ hours doing a coding exercises to prove their worth to a single potential customer - with no guarantee the potential customer would acknowledge their effort? After some hmmming and haaaaing he said no, he wouldn't. So I asked, why should I?
The take-home-task and white-boarding culture around interviews is horrendous, and unfortunately pervasive. I've worked at startups for the last 10 years of my career and I can emphatically say that there are a lot of them out there don't participate in either practice.
(General statements with lots of holes based on personal experience and general subjectivity ahead)
White-boarding is for recruiters, hiring managers, and the devs who volunteer to step into interviews, so that they don't have to properly vet a candidate. It's lazy, and very often unrealistic.
Take-home assignments display a general lack of respect for the candidate's time, are often nothing like the work actually being done at the company. And are a lazy, passive means to gatekeep the hiring process.
Interviews that cover/ask about basic algorithms without acknowledging modern development practices and critical thinking (e.g. where and how to find the answer) aren't indicative of creativity or flexibility of the the teams you'll eventually land in, nor the company on the whole.
---
The best advice I give newer, less experienced developers is: Build a public body of work in one way, shape, or form. Build relationships with people who can be good references. And lean on both as points of confidence when looking for work or being recruited. Look for companies with which the first person you speak with has a technical background, and actually understands what the role is for.
> Build a public body of work in one way, shape, or form.
This can be pretty difficult. Most places you work for will not have your work as open source. And if its backend work then there is not a lot to show the public in terms of end results. The sort of thing I am good at are building relatively large scale projects, it's not the sort of thing that I can do in my spare time without spending months.
On top of that, I have offered people examples of code that I have in bitbucket and they still insist that you do their pointless c"oding challenge". Evey company thinks that they are special.
Say what you will about the merits or necessity of all-day in-person interviews, at least the company is investing a roughly symmetric amount of time into the interview process.
It's more time on the company side, if anything. Each hour of interviewee time probably costs two hours of interviewer time, and that's before accounting for hiring committee time, the cost of real estate for the rooms, recruiters, interviewer training time, etc.
Our recruiters discourage us from sending out "take-home" tests, but I have to admit, I'd rather see a comprehensive "can you build an endpoint that fetches data from other places - some in parallel, some in serial - and build a response?" type challenge instead of "can you reverse a string?" or "can you find the next permutation of this number sequence?". Yes, it'll take about an hour or so to pop something up on your GitHub. But it'll show me how/if you handle errors, if you add logging, if you write some tests. I get that not everyone has the time (or desire) to devote to this but... I sure do hate doing the "CS-secret-handshake" to make myself believe a developer can solve problems.
Some random advice from the Internet, for what it's worth:
If you want to see how/if a candidate handles errors, logging, adding tests, etc. you should explicitly ask the candidate to handle errors, and add appropriate logging and tests.
Otherwise, you're mainly testing whether a candidate can read your mind.
The problem is, the appropriate level of error handling, etc. depends on context and if part of that context is in your head only, your test is sampling a lot of random noise.
That's only if I would refuse to talk to someone who DIDN'T do those things. I've yet to reject talking to a candidate that achieved the goal, yet left out those "nice to haves".
Sure they are. This is the OPENING to a larger conversation. This is not, "get this right, and you're hired". I've yet to see anyone attempt it and NOT get it to work... the few that have put some quick logging and error handling were nice surprises and that drove the conversation when we got them on-site.
Agreed. We gave a test for an agency a couple of months back. Our junior forntend dev complained about a number of things that we hadn't specified (using typescript for example). I pointed out that it was a bit unfair to mark down on things that were unspecified.
Wait, you're expecting someone to whip up an endpoint that pulls in arbitrary parallel and serial data sources, handles errors, has logging and also has tests IN ABOUT AN HOUR?
How long would you expect someone to need to write code that makes a few HTTP requests (or read files or whatever other data source is specified), some kind of parsing or decoding (probably JSON) to get the URLs for more requests, and spawns a couple of threads?
Nothing about that sounds tricky or time-intensive to me in any language I've used very often. An hour sounds perfectly reasonable to me.
I'm curious where you're coming from here. What part of this would you expect to spend so much more than an hour on?
All your doing is testing if someone memorized the same APIs and libraries as you have, and has recently done whatever project you just did that's just like this (except it took you a week, and now that you know how to do it you think someone else should be able to do it in an hour). But your company already has one of you and doesn't need another.
In my case (the GP here) no I don't care WHAT framework/language the candidate users. But they DO have to know how to use a webclient of some sort. And any person with experience in any common stack should be able to perform a data fetch. If you can't do that, you're probably not a fit as that half of what our microservices do.
Regarding whether my company would like, or needs another me, you'd have to ask them. I believe they'd say they would like several more of me. And there's nothing wrong with that. I provide a good amount of value.
I was including time spent reviewing documentation there. I definitely don't have any of those memorized. I almost never write code without frequently consulting an API reference.
Am I misunderstanding you, or are you really saying that you expect someone to take a week to write a program that spawns a couple of threads and makes a couple of HTTP requests?
If it were only to take an hour then it's not a "comprehensive" exercise in the ability to solve problems as the OP desires.
It would then be an exercise with toy data that measures how smoothly the candidate conforms to the expectations of whatever framework they're using to solve hello-world-level problems.
the GP is probably coming from some workplace that doesn't do exactly that same thing all day, every day, and doesn't know a framework for this from the inside out.
How to do a custom HTTP request on any language will probably take some good 15 minutes reading the documentation (if one is perfectly comfortable with its networking documentation), how to parse JSON will take at a minimum some good 30 minutes reading the docs even on Javascript (unless you are ok with eval). Discovering how to serve that endpoint is a multi-hour learning task by itself.
uh, I can write an endpoint that does that in about 15-30 minutes in node with aws amplify if I'm doing queries with no parameters are other funny stuff. The most time consuming part would be getting the project set up.
I suppose, but "an hour" basically means straight-up non-stop typing for something like this. It would be stream-of-consciousness coding like in a hacker movie.
That's more than just "flow" that they're expecting to see.
> "can you build an endpoint that fetches data from other places - some in parallel, some in serial - and build a response?"
Years back now this is what we did when we were hiring, and then used it to jump start the conversation in the interview. Tried to keep it to an hour or so of work, but if someones interviewing at multiple places that can add up quickly.
I think your recruiter is probably right, unless you have some sort of outstanding place where people are lining up to work. Personally I refuse to do anything like it for interviews now, and I know a lot of others on the more experienced end that do the same. There's way too many places that'll hire without it to bother, unless it was somewhere like google where its sort of expected.
Sadly this is the current market. We're grasping at finding the best way to judge whether to bring someone onsite. Video coding challenge? Simple phone conversation? We've done all of these and they often go the same way, hours taken out of multiple people's schedule only to find that we should have weeded this candidate out at an earlier stage. (Not always, but often enough)
Take-homes are valid. Maybe 4-5 hours worth of take-home is a reasonable approach to seeing if someone is really a decent coder. Lots of companies will ask you to spend 4-5 hours in an onsite interview. Substituting much of that onsite interview time with an take-home exercise has its pros and cons, but it's not insane, and it's not exploitative.
For one my first interviews out of school (justin.tv) I had a take home which I liked, but it wasn't a substitution for the interview time - it was more of a pre-screen for the phone screen which then did the same solve a puzzle while I'm watching you thing.
The take home went well and took an hour or two, but it was a well contained problem and fun to write. I didn't do well on the docs share screen which is largely a separate skill you have to prepare for and I find more stressful.
Early on the 'I'm watching you solve a math puzzle' is brutal especially if you didn't go to MIT/Stanford where you're pretty well prepared for how to succeed in the technical interviews. My school (RPI) was more harmful than helpful - they had no idea how the process worked so you mostly learn through failure. This plus a dash of imposter syndrome makes succeeding in these out of school pretty tough. Once you've validated your skills by succeeding and working somewhere it's easier - I'd guess because you're more confident in your ability.
I wonder how much engineer mobility is limited by the stress of these interviews. If you don't find them stressful you have a pretty easy way to massively increase your income in a couple years. There's a lot of value in just getting good at passing technical screens. I don't have a better solution to this, but it is frustrating. Lambda school's approach to preparing explicitly for it is probably a good one.
For your average node.js developer, no, that's not at all optimistic. Installing Express, and some sort of data-fetching library and setting up the routes. I'll admit, when I did the challenge in Java/Kotlin, it did take considerably more time to get the JSON serialization into POJOs set up.
Why is it wrong to hire a developer that's had experience in the exact field in what I'd want them to work? Isn't that a great deal of ALL hiring?
It's a bit like having a home builder job interview: "Have you had experience framing a house? No? Then I'm a little unsure you'd be fit for this job." It's not wrong for me to say, "no, you've never done this sort of thing before, you consider it too hard to do in an hour? You might not be the best fit"
Nothing wrong with it. Seems a little bit restrictive, if you already have code like this for your organization couldn't a relatively junior person work by analogy in much shorter than 1 hr?
While going through a data science internship a bunch of my colleagues applied to this rideshare startup that's (in)famous for having "high standards" and having this comprehensive take home problem that took a week to complete. It was obvious from what others spoke that the type of people they were looking for does not match our profiles, but they gave this challenge to everyone who showed interest and never took anyone after that anyway. To be fair they did interview some before rejecting them.
I feel like such large take homes should only be done if you really think the candidate is a good fit after some interviewing.
If you're hiring, and you do this kind of thing, you're only going to get people who are desperate, which tends to not be the top talent. Top talent usually has options, and won't put up with this kind of garbage. So if you're doing this, you're filtering to get lesser talent that will put up with being abused. Is that really the hiring filter you want?
I do occasionally give take homes that could take this long but it is only when the candidate is purely junior and doesn't have much/any work to review and show for themselves, but shows a lot of promise from a general employee perspective. I always let them know that they are welcome to use this work in their portfolio. I also let them know that we have senior level staff available to answer any questions they may have as they are working through it. We want to know how they approach problems, how able they are to figure things out, and if they know when its appropriate to reach out for help. I would never use this work for anything outside of this testing environment. If you are wanting to make a major career jump and haven't spent a whole lot of time building up your Github or filling out your portfolio, be ready to jump through some serious hoops.
>I hope you're compensating them for the time. Junior, or otherwise, that's disrespectful of the candidate's time.
Typically, we provide a small compensation for the candidates time, although it probably doesn't amount to a lot per hour.
>Eesh. This is just an abject example on just how bad the hiring process has become.
To be fair they can jump through hoops on their own and build up a body of work through personal projects etc and we will make a hiring decision based on that or we will provide them beautifully designed test assets and ask them to make something functional to the best of their ability. When they are done, hopefully its something that they can be proud of and build upon, whether we hire them or not. We put ourselves at their full disposal to help them wherever they are at as they complete the test project.
Well, some people are cautious when they are working with assets provided by someone else... where and how they share it. I wouldn't just assume I can put IP provided by someone else on my portfolio without written consent.
Been there, done that. Spent considerably more than 50 hours on it too. Not because I broke the rules but because they made it a point to specifically emphasize that I should take my time rather than submit something half-assed. -- I will not be so naive in the future.
Now I specifically ask how many other candidates for the same spot are in the stage of the take-home exercise. If it's more than half a dozen, forget it.
It depends on a number of further factors: Anything up to 48 hours I might do for free. For anything more, I would push pretty hard on them paying for my time to make sure they have skin in the game. A number of reputable companies do this now.
I wouldn't even suggest this. Anything over 1 hour is biting into my own valuable time. Your take-home challenge should not take longer than a coding challenge I'd do for another company (and those are around 30 minutes).
If they don't care to spend phone or on-site time interviewing me after this, then they were never worth applying to in the first place.
I should clarify: By 48 hours I mean that my comfort zone would be a 48 hour timespan from getting the assignment to handing it in, which might be 10hrs spent actually working on it.
Some companies do impose a limit like that, to reign in people who would break the rules and put massive numbers of hours in to get an edge over people unwilling to do that. ...this limit is something I agree with as good practice.
Also, as a bit of context: I tend to work remotely. When interviewing for a remote job, I don't think I would prefer it if they were to fly me in. That would most definitely be even more time wasted, plus the time I spend on a plane is doing nobody any good, neither them nor me.
About a year ago a recruiter from a NYC company called me about a role which sounded interesting.
Then they said the initial part of the interview was to write a project for them, which essentially amounted to "rewrite memcached in go".
I must assume they were looking for free labor under the guise of an interview. I strongly suspect there was no job. I offered to do the work for $200/hr, never heard back.
Actually, I did hear back over six months later when the same recruiter contacted me again with the same story. I reminded him that we already talked about this long before.
Never do work for free under the excuse of an interview.
I've hired dozens of developers and I do use take home assignments but primarily to weed out obviously unqualified candidates. My objective is to keep good developers interested through the entire process but arrive at a "no" decision as early as possible. My take-homes typically take qualified developers 15-20 minutes to complete but require some amount of research to complete (e.g. third-party API documentation). I've found that if you ask too much of candidates too early in the process you lose a lot of good ones.
Everybody is weighing in on whether coding tests are good or bad, and whether or not they personally would do one.
Framing them as either good or bad (or would vs would not take) misses the point though. What we're discussing isn't a binary thing, it's an elasticity curve from something like (effort required / lucrativeness of job) to the willingness of the candidate to complete the assignment.
On that basis, I'd say there definitely are cases in which I would spend 50 hours on a take home assignment with even a 1% chance of success. There are also cases where I wouldn't spend five minutes on a take home assignment with a 100% chance of success.
If you're going to give take home assignments, the effort required should be in line with how amazing a job you're offering. If you're offering people $1mm/yr to work on <that thing you love>, putting a huge filter out in front is probably in your best interest. If you're trying to get someone to move to SF for $70k a year...
As a side note: if you're going to have a take home test, have the decency to make the scenario interesting and the answer illuminating.
I have done the takehome style interview before. I spent about a day on it, then said "here's a day's work, there is an API and a backend with tests, writing the frontend would be straightforward" and they said "go away unless you do it all". I went away. They had enough of a programming sample to make a hiring decision.
As a hiring manager, the takehome is very tempting. Candidates put their Github profile on their application. You go and look and there's nothing there except some make-react-app template. Their work experience on their resume is bullet points like "enabled solutions for the business through synergy", which they've been doing for five years. But they write you a cover letter about how much they like your company, so you want to give them a chance. You read on HN about how whiteboard interviews are unfair. So with no data, you reach for the takehome. If they can do some assigned work, then they'll probably do well in the role that they've applied for, and that's a good hiring decision. And they said right there in the cover letter that they'll do anything to get this job. It just seems natural.
For that reason, it's something I keep in my back pocket. (So far I've used it 0 times, though.) You can definitely have a Github repository that is more valuable than any takehome would be. You could actually talk in detail about the sort of engineering problems you've solved on your resume, and the takehome wouldn't show me anything new. But the reality is that the vast majority of candidates do neither. They work all day, so the last thing they want to do when they go home is write some open-source software. I get that. They have no idea what a resume should look like, since they've never been in that resume screening or interviewing role, so they write whatever some professor in college told them to do. ("It must fit one one page," is what I was told. I have learned that the opposite is true, if you want a job anyway.) So having some way to determine "can this person program at all" is valuable. But it's very time-consuming for the candidate, so is not ideal. A smart candidate will say "nope". A naive candidate will spend 50 hours on a 2 hour task and be mad. So it's probably not ideal.
(As an aside, what is the deal with these boot camps? Every single applicant has the same exact react app in their Github, and an entry for building it on their resume as though it was work experience. I sifted through 100 such resumes recently and almost have a script to determine which bootcamp they went to based on which files are in their Github. Is anyone getting jobs this way!? I am beginning to think that it is some social experiment involving bots.)
I've been on both ends of this story: as a developer candidate and as a manager willing to fill the position.
Story 1: test project for about 10 hours, done according to industry standards. HR asked to refactor it so the code base would be read-accessible via webserver. I've declined it as a bad practice, learned enough about the company.
Story 2: put 10+ hours into inventing interesting take-home case and writing spec, gave it to 5 candidates, gave every one of them a half-hour code review session, accepted the best one.
I am having fun while writing code and prefer to work with similar people. It's okay if you don't want to build a take-home project for me, there are lots of software engineers who will and it will be more fun to have them around.
And, by the way, you may chat with cook for hours about food, ingredients, sauces and hygiene, or you may ask him/her to just grill a steak right here and taste it.
I know how frustrating it is for candidates but having been on both sides of this, I sympathise with tech leaders at startups who are on the hiring side too.
We used to send out open-ended programming assessments as part of our hiring process. It's really hard to keep track of everything without an ATS and good internal processes and even with those it's hard to predict how many candidates will drop out at this stage so there's a strong incentive to invite too many and risk getting swamped than vice versa.
Not proud of it but I've definitely kept candidates waiting for several weeks due to being unable to keep up with the rate of submissions.
I think there's a non zero chance this guy is assuming too much malicious intent and could get a positive response still
> I know how frustrating it is for candidates but having been on both sides of this, I sympathise with tech leaders at startups who are on the hiring side too.
Don't. Because it's a self-inflicted problem. The "tech leaders" (aside: this is a gag-worthy phrase) do it to themselves through inflated requirements and no real holistic understanding of what they either want or need in a role.
Hiring well is not difficult. Hiring well with stupid expectations is, and that is firmly and inescapably the fault of ye olde "tech leader", and sympathy is undeserved.
There is a middle ground for these types of assignments.
Have your interviewee come up with a potential design and ask them to highlight some specific concepts or programming methods. Then cover an individual component in person, pair-programming style.
I think take homes are pretty good.
I have done them and I am now providing them for new applicants where I work.
It is amazing how many people have a resume that looks good, and seem solid but they cant code in any reasonable way.
We do phone screen, bring in applicants that have a good resume and presented ok on the phone part. If we like them, we give them a take home assignment that is based on our technology stack, everyone gets the same one for each posistion.
They committ it to our github, we spend some time looking through it. We bring back the best performers for a second interview where they can present their work and talk about the experience.
If we like that we hire them :)
The quality of our hires have gone up once we started doing it.
Take home assignments usually indicate that the company has a 'take home' culture.
If they find it so easy to ask someone to work on something in their free time when they don't have any leverage, imagine what'll happen when you work for them.
I've only done a very small amount of hiring, but I honestly can't imagine assigning take-home work over an hour or two without paying the applicant for their time. I can't see how an ethical engineer can do otherwise.
Given that it was a data science interview is it possible they were expecting it to be a fast simple thing (some pandas, some sklearn, you’re done) and instead he did some long slow manual thing so they rejected him?
Regarding take-home assignments, if you do decide to incorporate this into your hiring process, I think pulling a page out of Aaron Swartz's "How I Hire Programmers" [1] is a good place to start. Important points being to keep the task small and non-proprietary. If it is legally and financially possible, then also pay the programmer for her/his/they time.
This spurred me to think of a neat way to help the community.
A site that takes requests for opensource code packages or modules (or refactors or contributions) and lets applicants work on one of those.
The hiring company could select what skills they want to test the applicant on and the applicant could pick among any number of matching requests for open source work.
You hear this a lot but it's really not practical under a lot of circumstances. For starters, it will often be a violation of your current employment agreement.
I do get the issue. I've been in jobs where having a writing sample or even giving a presentation on some topic were pretty much non-negotiable and, if a candidate didn't have those ready to go, they'd have had to prepare them. But, at least in those cases, it was a topic of the candidate's choosing so they didn't necessarily need to create something custom.
This is why these threads can be frustrating for juniors with no experience. Yeah sure, if you have ten years of on the job experience you can refuse companies that make you do take home tests. If you have zero years then it's a lot harder. My hit rate for interviews has been about 1/20 for actual interviews per sent job applications. If there's a coding challenge and it gets me to the next round so be it.
I don't know how to reconcile this new trend for take-homes, and more generally, ever more arduous recruitment processes ; and OTOH, the usual claims that there's a deep shortage of good candidates for software development jobs.
"good candidates" are those who meet two conditions: 1) competent and 2) suckers, in the sense that they'll put in a lot more work than they'll get in compensation.
The process successfully selects for good candidates.
Am I the only one who likes take-home assignments? Not for 50 hours, but I’d far, far rather spend some of my weekend comfortably coding on a chunky assignment than be asked stupid ‘cracking the coding interview’ questions in person.
Yup. I did a similar assignment although much shorter. The company then decided not to hire anyone. Never gave feedback or even looked at it. Since they I won't do this type of shit anymore unpaid. If they pay, we'll see.
Regardless of what was signed, I doubt that the company would own the copyright if the developer wasn't paid anything for it (and didn't even receive feedback). A valid contract requires that each party receive something of value.[1] And the company can't claim it was a "work for hire" because it wasn't paid for.
I would absolutely send them a bill for the time. Oh you didn't pay? Small claims. Then it's also public record. My guess is given the facts you'd fare pretty well.
There was no agreement for compensation, so I don’t know that’d work. Some actual damage would have to be done. Lost time alone isn’t enough, it could maybe be shown to result from the damage and need to be restored. Justice is restoration, what’s broken? I change minds though small actions like refusing to work for companies that are out of alignment with my values, maybe this could do it.
Sending a bill would be more of a symbolic FU than anything.
I responded for some clarification: Where could I improve? What would make me a more attractive candidate? Nothing. We're a pretty close-knit tech community (Boulder) so it felt like a real slap in the face.
I manage dev hiring at my company, and when I give take-home assignments, I make sure to give them a timeline of no more than 2 hours. If you get to that point, it's okay to tell me what you would have done, as I should be able to tell by that point if you know what you're doing and could accomplish it.
"Busy" is not an excuse. If you've got the time to interview someone, you make the time to treat them respectfully and provide quality feedback.