Did you do the test blind? i.e. Did someone give you the problem without you knowing/hearing it before? If you wrote the problem, or even heard it before you had to solve it, you had a big leg up on someone who's never heard it.

Fair points. FWIW, we've asked people how long the problem took and they all said it took a few hours, so I think it's the right scope. It really is a fairly easy piece of work.

Actually, I think this whole fear of candidates pervasively lying about time-to-completion is something of a red herring.

(1) It may seem counterintuitive to some, but my own general policy is, when it comes to little stuff ("how long did it take you to do X"), you just have to trust people, to a certain extent. Sure, some people may blatantly or grossly lie. But most likely these people will reveal their slipperiness in other ways, very very quickly.

Meanwhile -- and I think people are quick to overlook this -- playing the "policeman" role in every transaction with the candidate brings substantial negatives. By definition, it's adversarial. And generally there are (nearly always) non-adversarial ways to get the same information about the candidate ("Are they basically honest?") you're looking for. They take creativity (and an ability to read emotions and pick up on other signals), but they're there.

(2) Much bigger -- really, there's no need to sweat about the time to completion at all. Just look at the quality of the code.

It all just comes down to the fact that everything is interconnected: Good people generally turn out good stuff in reasonable amounts of time. When you're looking at good code, there is, I find, an intrinsic aura of ease and comfort which shines through it -- such that you just can't imagine it took them very long to produce it. Everything just flows -- just like it does when you talk to them.

Mediocre (and dishonest) people, on the other hand... never produce good stuff in virtually any amount of time. Sure, they can take the whole weekend to polish off their code... but it will still look bad, or at best, "Meh".

There might be some false positives (or outright frauds) by this approach), but I suspect very few. And those that do slip through, are easy to spot by other means (such as asking them to talk about their solution, for even a couple of seconds).

I think the concern is that the homework task could be too large and because people have an incentive to appear competent, they might lie about that to make themselves look bad. That means that we're giving too hard a task but we'll never find out.

As to how likely it is that people will lie, given that we've hired several people who did this homework and they've proven to be as competent as we believed, there's at least some anecdotal evidence that some people have not lied.

You can't ask a candidate how long it took, they have no incentive for truth here. Either they say it took all night and you think poorly of them, or it really did take a few hours.

You have to ask someone with no skin in the game.

As others have pointed out, your interviewees have little to no incentive to give you an accurate time estimate.

Beyond that, I think "a few hours" is a bit too much to ask for, especially since you are presumably following up with an in person interview centered around the assignment. That's a big time commitment, and the commitment on the assignment especially is very asymmetric.

I'm not a big fan of assignments for this reason. They are just so asymmetric. I've been given interview homework that was supposed to take "about an hour" and it was more like 4 to 5 in reality. It felt like an unreasonable time request. I did the assignment, and did in fact tell them it took considerably longer than their resonates. I was invited for an on-site after all that, but declined for other reasons.

You are begging for people to lie to you.

If that's the way you think people are... then those are the kind of people you'll attract.

It's how the universe works, basically.

It took a few hours and "it really was an easy piece of work?" How considerate of you. Who was it an an easy piece of work for, someone with unlimited free time. An unemployed person. What a joke. Any problem is easy when you yourself contrive it. Here's an idea, how about you pay someone for the 3 hours or work you are giving them. Say a lot about you.

I would prefer that we pay people to do this, but unfortunately that's not my call. That said, no one seems to complain so bitterly about the all day interviews that places like Google do (and insist you fly out for in person).

Isn't asking people to fly out for 6-8 hours of interviews (which effectively takes 3 days minimum out of your life) a much greater burden than spending 2-3 hours on some coding which you can do at a time of your choosing? (Followed by 2-3 hours of video chat interviews spread across multiple days, no flying required).

Also, just to clarify, the homework problem is _not_ something related to our business. The solutions are of no business value to the company.

Are you paying as much as Google? Is your job going to give the same prestige as having "worked for Google" on your CV?

I am not saying that you are wrong, but applying to Google does sound like it will have many benefits above your average company.

Google is hardly the only company to do in-person all day interviews. I've had several in my career, none of them with Google. IIRC, they were with Shopzilla and Grant Street Group, and Livetext (not exactly Google-famous companies). I wasn't thrilled about flying out for 6 hours of interviews, but at the time I thought it was reasonable for them to ask for this. I'm not sure I'd do it again unless I was incredibly excited about the position in question, but I'm older and more jaded now.

As to how much we pay ... Our pay is very good, and all but one of the positions for which we've had the homework requirement have been telecommuting as well. It's actually a pretty desirable place to work if you like good pay, telecommuting, working at a small company, a low pressure environment (we've been profitable for many years), and various other perks (training budget, flexible hours, blah blah blah).

And the above poster would seem to have an eminently sensible interviewing style, himself:

http://blog.urth.org/2016/03/08/tech-interviewer-theory/

The last time I was in the hiring side of the process... I had what I considered a pretty easy assignment... it was for a full-stack JS developer (node). The assignment was to read in an XML file (preferably via an input stream) and write it out to a JSON file of a predetermined object structure.

There were no other limitations put.. "bonus points for stream based input" "bonus points for test cases" ... only a couple people actually delivered a "working" solution (one that ran and outputted anything), none of which had the correct output (one was close enough), and none had any tests.

It was truly something that should take a "skilled" developer a couple hours. And not something that should be entirely alien. To say the least, I was really disappointed with the results. I did the project myself in about 2 hrs, with test cases, 100% code coverage. (before I even gave it out, it was as trivial a challenge as I could come up with for a real world problem).

Why should I have to pay the couple dozen people for their 3 hours, when none delivered a correct solution?

In the end, the person with the closest to correct solution, was the one with the least experience... that person got the job.

Well you're one of the brave and true, then.

And I had someone on my previous team make a point of bringing up this fine point at a meeting, also ;)