I agree that the time it takes is always muchuch longer than what they state.

Companies that offer these tests before doing an initial phone screen get that email deleted. Why would I as an applicant who is applying to 10+ jobs spend time doing this test when I have never even had a chance to interact with a human.

The tests are sometimes not even close to the actual job. As in the job description is for a front end developer and JavaScript knowledge needed and they ask you to write the test using a completely different language. one company (who adversities jobs on here all the time) asked to do some php command line scripting for a JavaScript front end position. How is that in anyway a useful judgement of someone's skills. So wasting people's time is a big deliminator.

An example of a company I experienced that did the take home 'right' did an initial phone screen a couple days after applying. Then did another tech screen which was just basic stuff. After that they asked me to do a take home exercise and while completing it they continued to move forward with the application process including setting up travel arrangements. The take home test was directly related to the job and was given open ended for some creativity if one chose. The onsite final interview was discussing the code, so it would do little good to cheat on it because you need to be able to talk through it.

I didn't even get the job with them but it was actually not a painful experience for once to do a take home test.

Just my two cents, but I believe there is a good way and a terrible way to do it.

It seemed like a good middle ground to me.

Yeah, I can see why too, since almost all software is written with a literal ticking time bomb ready to go off if you don't finish it within a certain minute.

This is, of course, sarcasm. Timed programming interview tests are fucking dumb.

I mean, if an employer gives someone a take home test that they expect to take 3 hours and they give them a week to do it, that's reasonable if technically "timed"; but if an employer gives someone a take home test that they expect to take 3 hours and they actually give them 3 hours to do it, that employer sucks at hiring programmers. I won't even bother debating this with the inevitable person who chimes in to rationalize why they do this, because as far as I'm concerned it is a "the sky is blue" statement and any time debating it with people who disagree with this position is completely wasted.

The test I was referring to I'm almost certain was not intended to be completed in the time allowed. I've used it myself for in person interviews (not take home) and give candidates 3x the time I was given, few of them actually finish it completely. While it just made me feel like an abject failure at the time now I realize a big part of what was being tested was given limited time what bits I focused on. In fact that's exactly what I tell candidates who I give it to.

The bad one was about 2 yrs ago. I walked into a conference room for the final round, was sat down at a mac, and asked to write some code in their proprietary DSL without any documentation or anything. It was maddening. I almost walked out, but the salary was stupid high. Didn't get the job. Thinking back on it, maybe it was just a test and they did want me to say it was ridiculous.

    I almost walked out, but the salary was stupid high. Didn't
    get the job. Thinking back on it, maybe it was just a test
    and they did want me to say it was ridiculous.

- They are being unintentionally stupid by asking you to do this activity.

- If they are intentionally asking you to do a stupid thing and they expect you to revolt in the interview and decry the madness. How does that make you feel about your future day-to-day life at that organization?

In both cases those are not good "A-player" types of people to work for.

No need to torture yourself over more favorable prospects "lost" :)

If that was the case ... then you don't want to work there. I've worked with a few business people that intentionally filtered interviewees by strange characterists. [Aka... graphic designers that were juinor, but didn't have web dev experience (I want to say it was something stranger than that)]

Now you could debate which is a better representation of my work, the polished dog and pony show repo or the fast and dirty stuff that I push in my ongoing projects.

They seemed offended when I was frank that it would take much longer than the 1 hour they were quoting and that it wouldn't be a real demonstration of skills but more so what I could cram.

OTOH, my current work does a sort of take-home test but it can't be faked/cheated on because you have to record yourself teaching something.

Don't state that 'take home tests are the worst'. That is - failing to find better words - crap. If that is the ONLY option, I understand that this might be not for you. But - that's not the case here as far as I can tell. You, as a person interested to interview, can opt in. That is awesome.

Now - you might not be the type of guy that would _want_ to opt in, but please refrain from these absolute statements. No, that's not the worst. In fact, it's probably the _best_ option for a number of people (I myself would - if I'd want to interview with this service - opt for the home project).

I fail to understand how this 'bash the home work' attitude comes up again and again. Yes, don't work for free. But if you're doing a 3h whiteboard marathon or work from your own chair? And you pick which one you prefer? I don't get the hate here..

1: https://news.ycombinator.com/item?id=9770737

It's not "the worst" in relation to other interview options. It's the worst because it's usually in addition to other interview options. I just stopped doing take homes on my last round of interviewing. Just not worth it. It was always just added work. It never replaced a stage of the process.

If you think about it, it makes sense though. Very few companies would hire people directly based on the strength of their github account or their topcoder rank. So, if they won't do that, then what extra information does a take home really provide?

Companies seem to recognize that they want to hire people who do good work and that good work isn't done in an interview setting. But very few companies are willing to just analyze the candidate's work. They want to subjectively judge the person.

But it's important to remember that a take home exercise cannot fully replace an interview. It can replace the coding part, the whiteboard "and now we ask useless trivia questions" part. But there's no way for this work to replace the "would you fit the team" interview.

Others already discuss this in different subthreads here, but basically I'd expect the company to clearly show how their process works and - ideally - filter by ~social~ criterias first ("You might fit the team, if you can code"). Doing work for free with potentially no feedback or a 'fail' in a later discussion is crap, of course.

One of the biggest challenges in hiring is that it takes a ton of time to go through many bad candidates before you see any good ones. And time is the one thing you don't have. You're hiring because you don't have enough resources to do the work you already have.

Therefore the name of the game is efficiently rejecting candidates while using up the least amount of your existing people's time. Which means that the most expensive filters should be done last. And the most expensive one is social because judging it takes time from EVERYONE.

The fundamental reason why this is OK is that the company is hoping to pay hundreds of thousands of dollars for the candidate's time. The person who pays the piper, gets to choose how it happens.

But that said, it is still fair. The effort required to hire a new person into a competent company is significantly greater than the effort it takes a competent person to get a new job. As a candidate it doesn't look like this because you see that you personally gave the company more attention than vice versa. However you don't see all of the other people who the company also paid attention to and ultimately rejected.

If you're a competent developer it probably still doesn't look like this because the company usually develops procedures that concentrate the required effort in the hiring manager and/or HR. Therefore you have little idea how much effort is actually spent looking for candidates.

But spend time as a hiring manager and it will be obvious.

its bad for the company because the candidate can work with someone else and produce a glowing submission. I have helped a number of people do these some that have gotten the job.

its bad for the interviewee. They may spend 10-15 hours on this and get rejected for no reason at all. Do you think the person reviewing the submission is putting multiple hours into it. Doubtful.

If the intent is truly(and I mean truly) help individuals that struggle with traditional interviewing techniques then kudos. Demonstrate this by allowing candidates to interview in a way that is comfortable for them(including not taking your take home test) If its the company saying "my time is more valuable than yours. Do this assignment then we'll talk" then no thanks.

The interviewee (the vowel count makes me dizzy) can choose what he/she prefers. So that argument is weird. Maybe (if that's your point) it might be beneficial to go for the face to face interview, for direct feedback? But .. some people just _cannot_ do that. You're not talking "Ah, they didn't respond. If you'd just had visited them on-site..." here. It's "opt for the home project or don't apply". Which is empowering the candidate.

Had that recently: they said "spend no more than two hours on it" so I finished in about an hour and 45 that evening and flipped it over.

Then they started asking why my 20 or so unit tests only covered the basics when other candidates had full unit tests in the two hour time frame. I told them the other candidates were simply lying :-)

I rather put in those extra hours contracting (worst scenario), doing open source work (lots to be done that advances the productivity of tens of thousands of developers, if not more), into my hobbies, or into my friends.

As for receiving outside help, if you're judging applicants solely on their homework results, you are Doing It Wrong. The best interview I've ever had gave me a take-home programming assignment by email, then when I came in the lead programmer asked me to explain the program line-by-line and justify various decisions I made. I got the job.

It's tricky. An in-person test would put the candidate in an unfamiliar environment, and makes many people nervous. A take-home test without a time limit opens itself up to the "I'd better spend lots of extra time so I can look impressive" problem. A take-home test with a hard time limit can also make people nervous. This is the best compromise we've been able to come up with (suggestions for improvement welcomed!).

As suggested on this thread, we also don't ask candidates to tackle the exercise until they've had a chance to talk to us on the phone.

This does two things. In the long run, the time required converges towards where we want it to be (ASSUMING honest answers), and by bringing you in to talk through things, we can easily tell if these thoughts were your own by challenging you on specific parts of the prompt.

This is less than ideal since it costs the interviewee time, and time isn't cheap, but we've found that advance prep removes an even bigger wildcard in interviews: how you respond to interview stress.

"That? Oh, it was no big, probably 20-30 minutes."

The biggest problem with these though is definitely the time crunch. The first one I hadn't realized how long it would take so rushed through it at the end and made mistakes. Second one gave myself a full week rather than 4 days and that's proceeding to an in-person interview, so you need to be taking as much time as they'll allow in order for it to go smoothly.

Also, another project means more documentation added to the repo so that's pretty nice too. If the project didn't align to my interests, which thankfully happen to be stupidly in-demand right now if you have "senior" experience with them, and the position, I'd nope out of the project right away.

That's why they use the homework as the basis for the interview. In my opinion, of all things they could test you on during the interview, your own work is potentially one of the more pleasant subjects.

But the last one I did...

A junior just basically shat all over the project and claimed a lot of things.

[The submission was to write a few sample sort functions for a library... the recruiter asked for an app, the paper asked for a library.. I did both... what did I get shat upon for? The user interface/cli that wasn't required.. another thing.. Why did I have 66 commits?]

If you asked someone to do FizzBuzz at home and they sent you a git repo with 60+ commits, you wouldn't be a little puzzled about that? That would seem to suggest they really struggled with it.

For a typical whiteboard coding problem, I also wouldn't want to see 60+ commits.

I remember later on I wrote a script that listened to git hooks and rebuilt my project on a remote server. I was still testing manually at that time, as we all do in the beginning, which resulted in a large number of commits so that I could view the results on the server.

I think it's ok to ask "why do you have so many commits?" but not "why do you have so many commits?!?!?!". It's also not ok to ASSUME that a large number of commits is a bad thing automatically, unless you have reasons far better then any submitted in this thread.

But there were about 16 files in total. All of the comparators that were written had multiple tests. (I shot for nearly 100% coverage..although I wasn't going to force stdin emulation, and mock out system.exits) All of the commits that were performed were done in small amounts. (Also, a few were just for transferring work space to other computers) The task in hand would have represented approximately 4 tickets at the bare minimum.

Besides, the number of commits: That problem is resolved by merging a branch back down.

The feedback was written in a way "How do you consider that reasonable in a professional environment?"

(Another thing... I wasn't required to submit via a git repo I was required to submit via a zip file, but I did because I hoped it'd give me a leg up.... Turns out: You're better off not trying)

This might even be an underestimate. In my experience, there is a lot of research time that goes into the problem before you really dig in and start coding. I had one take-home project that required a few days just to get my system configured to begin testing code (collecting the dataset [10's of GB], installing libraries, and configuring the system).

>I've seen applicants receive friends'/roommates'/spouse's help on take home tests.

I enjoy overtly mathematical problems, so I've talked through a number of take-home interview questions with friends during the research phase, and even provided implementations for comparison and review after they've returned them. (Most recently on a take-home challenge to generate digits of pi.)

>But the company just took 10 minutes to arbitrarily reject your application.

This is actually my second biggest gripe as an applicant. I spend a couple of hours building and submitting the most compelling application I can for a job. The worst so far was an automated email response that my application had been forwarded for review, and before I finished reading the automated response I got a rejection email from the hiring manager. The emails are literally two minutes apart in my inbox. It is incredibly frustrating to put so much time into applications when they are clearly being summarily rejected.

(For anyone curious, my biggest job search gripe is not receiving any kind of firm decision...ever. I can appreciate that there "is not a good fit at this time", but I'm not going to be sitting here in six months pining for that job I applied for with your company. If I want to show interest, I'll apply again in a year or so. It's actually mildly frustrating when I get a callback three months later.)

It's hard. If you submit part of the project, which you usually have to do unless you're unemployed, they never go for it. If you call out of work a day or two to do the project... and you don't get the job anyway...

But ... it was something that took about 40 hours to complete, and ruined about a week and a half of family time. Thankfully she got the job, but if she hadn't it wouldn't have been pretty.

[1] http://onbiostatistics.blogspot.com/2013/07/periodic-safety-...

IMO, it's a less insulting, slightly more realistic version of FizzBuzz.

As far as getting help goes, I'm not sure it matters too much. There's still an on site interview, and we ask a few questions about the assignment, along with some other coding questions, and regular interview stuff. I guess if their friend/roommate/spouse is going to help them code all the time, then it's like we hired two people for the price of one ;-)

We try hard to provide good feedback on each submission (certainly not just a 10 minutes look, even for a truly awful entry).

I think that we should try harder to provide an exercise with a maximum time spent. We also try hard to overlook things that can be attributed to a lack of time but the openness of the exercises we use mean that somebody willing to could spend dozens of hours on it if he/she wanted a truly perfect solution (with unit tests everywhere, handling all API levels & devices in the wild, ...)

I personally thinks that our exercises are more objective than whiteboard tests & better reflect real life work. Actually, we take our inspiration from real problems we had to solve.

Forcing you to spend most of a day on an application means that good candidates will just not wast time applying for these sorts of jobs.

An in the uk to get befits you have to provide evidence of applying for x no of jobs per week so wasting 2 days on a single application is out

So only do timed tests?

Just ask for compensation.