We do a take-home assignment for junior devs where I work. The actual coding knowledge is pretty minimal. Few people fail based on the code alone. What we're actually looking for is if they can follow directions. A surprising number of people can't read a list of requirements and make sure they all get implemented.

For junior devs, we don't actually care if they do it in 2 hours, 2 days, or the whole 7 days we allow them. There's no bonus points for turning it in the next day, and I don't think anyone has ever actually done that.

But we're at the point that if they fail a single point in the requirements, we stop looking at them. This was a really hard decision, because there are candidates who are really nice and seem to otherwise do good work, but we've hired some of them and they inevitably continue to skip steps even in simple tickets. We end up letting them go after multiple warnings and months of wasted time, and having to do it all over again.

Of course, if you can't code you aren't going to get in either, but that actually seems to be a lower bar than following directions.

Very insightful and true. Even during a conversation, many people "translate" what they hear into something else, and will quote back, a few seconds later, a totally different sentence and think that's exactly what you said.

Kids in school often don't read assignments properly either, and skip everything until the first question. I don't know if they think it saves them time or fear there's a trick somewhere that they will avoid that way.

In life in general, people like ambiguity; it helps to smooth things out. But in programming it's a problem.

I think it's a profound fear of ambiguity that drives these behaviors: the urge is to move past the 'understanding' part by finding some single interpretation and then move on to the 'doing' part, which is the satisfying part. I think formally writing down the specification for any kind of work starts with holding all the ambiguities in of it in your head. In this case, the approach depends on whether the student is more interested in 'computer programming' or 'software engineering'

From a hiring standpoint, the problem imo, is that employers set the timebox thinking that it means something when comparing candidates' solutions. I couldn't care less whether somebody spends two hours or two days on it. I want to see the best solution somebody can produce. I have engineers that can do things quickly and others that can do them more slowly, and both are infinitely more valuable to me than someone who can't provide a quality solution under any circumstance. In my experience, if you're filtering out the slower engineers that produce quality work you're going to be in for a very long hiring process and miss out on a ton of great engineers.

When I've interviewed using homework like this, it was with the sole purpose of bringing it along and talking to it. That won't be gamed. And, by the way, that lends itself also very well for bringing whatever fitted in the time box, and having a discussion on the meeting about the tasks that remain, and about their prioritization process. You may like it when you see less production code, in favor of some tests! People coming in with a full-fletched solution, and then to tell me they didn't have time for a test, what am I to make from that?

This is the right approach. You don't disqualify based on the take home (unless it doesn't work at all).

Unless it's a nonsense solution maybe, or you clearly demonstrate that you don't know what you're talking about. But otherwise it not quite working isn't even the greatest obstacle. (Though those tests working would be nice...)

I'd say selecting the candidate who will work for 2 days and only claim 2 hours is the system working perfectly.

Sounds like there may be a niche for some kind of industry standard automated logging system.

Nothing complicated - shouldn't take too long.

Are you joking? Should candidates install spyware?

Seems obviously a joke based on the project from the article

If you have 2 hours to submit the task and you submit it after 2 days you are already out

So... you select for people that can get home within two hours and still have enough time left over for the assignment, as well as people that are willing to do the assignment in the parking lot?

Oh, we don't even meet face to face before you write code. We setup a time where you have X hours open and then we send you an email with couple different assignments to choose from. Then we expect to have your code email back to us within X hours.

This might be the worst technical assessment format I've ever heard of. I really don't get the reason for adding time pressure to this. You're combining the worst elements of take-home assignments and whiteboard interviews.

Why not send people the assignment and ask them to return it within a couple of days? What are you gaining by limiting it to hours and turning it into a remote exam?

This way it ensures you only spend 2 hours on it without being penalized. If you are free to spend any amount of time you can be sure someone spent 40 hours working on it, you really don't want to compete with that. So another person would say that this combines the best from take home and white board, you don't have to travel anywhere for the interview, you get to do a project rather than algorithm, and it doesn't waste a lot of your time.

A 2-hour project is hardly a project. It's still a contrived problem with limited scope. I don't see it as an improvement. And you're assuming that the person who is assigning the task can estimate it correctly (this goes back to the topic of the OP).

I suppose people's preferences vary a lot. Personally, I would turn this down. The format of "do as much work alone under pressure" is extremely offputting. I'd much rather do a whiteboard interview where the problem is well scoped in time and I can discuss my solution with the interviewers. I also wouldn't mind a take-home that actually takes 2 hours that I can do whenever I please - but asking for the work to be returned within hours is a dealbreaker for me.

…but they said they schedule the 2 hours for whenever you please, so the only thing being limited on here is it being an honest “2 hour project” rather than a “10 hour project that we expect you to lie about.” You still get to do it whenever you please.

I don't know what kind of assignments you think we give people, but they are things that anyone who can program can do without any thought well under an hour. Whole idea is to weed out people who don't know how to program or don't know how to write unittests or any kind of documentation.

If you are having time pressure challenges with our assignments we also don't want you.

As a potential employee I would never agree to this. If you want me to put in two hours, I do expect to have progressed further into the interview than "you are one of 400 candidates, here's your test!".

Experience shows that many people straight up lie about their programming skills to a point where they can't write a FizzBuzz to safe their lives.

But also if the person is so unwilling to co-operate that they can't so basic programming skill then I guess it wasn't meant to be.