I wonder if that's why I wasn't a good fit for a recent company I interviewed with using a take-home assignment... bear in mind it's been at least a decade since I last took a take-home, so things might have changed.

I received the task on Friday evening, I spent the week-end thinking about the problem. Monday I had actual work and on Tuesday, I spent a day coming up with a shit implementation. Then, I started improving it for two days until I think it got in a good shape. I basically wanted to transmit that I can start from the base, add functionality and then iterate on the problem by documenting, refactoring, adding tests, evolving the code base etc.

So I'd say I worked for around 24 hours over 168 hours and the feedback I got was:

> Thank you so much for your interest in joining <redacted> and the time you took to submit the coding challenge. In reviewing your application though, I have decided not to invite you to the next round of interviews as I believe there are other candidates that are a better fit for what <redacted> needs right now.

This is turning into a subjective rant, part of me wants to delete this but I'm just gonna go ahead and finish it; When I was younger, I used to love take-home assignments because it felt better than just doing algorithms, and then I used to get proper feedback, what I did wrong, what aspects I could improve in the future etc. This feedback gives me nothing. Just the realization I wasted time.

You have to lie about take-home assignments. That is the accepted way.

I had a take home test that was to last 2 hours, and so I promised myself I would spend no longer on it. I provided a complete log of what I did minute by minute for a take home test for the last test I did as a defensive measure...

There was no break, no pondering, this was flat out knowing exactly what needed to be done and just typing constantly....

0:00 - started cloning

2:37 - finished cloning

3:11 - npm install

3:53 - localhost working

7:24 - removed timeout (intentional bug left in)

10:41 - Got images returned from the server (npm run serve)

13:27 - CSS started - thinking about design

22:26 - Grid for desktop

36:16 - Included user info

49:56 - responsive

56:37 - Added performance section

1:07 - Name form

1:21 - Email validation

1:35 - Most fields done. Need DOB

1:42 - DOB done

1:53 - form styling

1:57 - tidying up

2:01 - Saved this file

I didn't end up getting the job including feedback such as...

- Did not upload job search indicating repo to GitHub

- Didn't use `specific css attribute`

- Grid is rudimentary (the 11 minute one I made)

- HTML could be more semantic

- Form validation for name allows numbers (actually a programming falacy that names can technically be anything)

- Complaints about having multiple classes in one file.

I'm wondering exactly where I could have fit these in?

The week before I spent 4 hours on a task and delivered it within 12 hours of the assignment. I got an email with a single paragraph. `Unfortunately, after reviewing, the team has decided that they won't be moving forward to the next stage of the process with you`

These tests all have unrealistic expectations. I used to enjoy doing them for the learning experience, but now, it's just a solid graft with zero downtime coding the same app time after time.

So whenever I chat to a recruiter about the recruitment process I always drill down into the take home test, and the process of doing that let's them know that I won't be doing any take home tests. You have to simply question it sometimes and you can get it upgraded to a pair programming assignment which if you are honest, and have experience works in your favour.

Oh man that is a truly fantastic timeline. Thanks so much for sharing it. It really clarified for me why I can’t ever seem to get the take-home assignment done. I care too much!

I’ve withdrawn my application the last few times I’ve gotten task home assignments: I’d get to the 2 or 3 hour mark, realize I’m still working on clarifying my documentation (because I want to communicate that I consider this essential to a minimal product) and haven’t finished the feature(s) yet, call myself a shitty developer who is apparently an imposter, and then call it quits.

I've probably burned some bridges this way, but whenever this has happened to me I've sent strongly worded messages to the recruiter and hiring manager. It probably goes nowhere, but I think it's time that we as an industry stop putting up with this shit.

It's also a great indication that it's not a company you want to work for anyway, but I don't have the stomach for accepting this level of disrespect towards applicants.

The only people who benefit from this situation are the people who have the luxury and freedom of 20 hours to spend on take-home projects. And even when I was that person once, I still hated it.

The folly is that if you did upload to github, they would have wanted to see steady commit history as well, which would have given away how much time you actually worked on it.

The key is lying because you already had a similar code base to use, most likely from interviewing so much you'd seen it before.

I actually didn't get a job for over-commiting. I hit a point where things were working, and wanted to be able to git-diff in VS Code, and they declined my application due to that.

I was going to push as well, as I wanted to make sure that was set up right, but they associated that with 'pushing untested code to production'

yeah its completely arbitrary and they don't tell you what they are going to be scoring by

but then they pretend its a meritocracy

That's seriously impressive work – though it occurs to me that you didn’t account for all the time spent thinking about what you were going to do in the two hours. And the feed-back is hilariously bad.

I’ve often wished I’d focussed more on coding over system administration but reading accounts like this makes me happier about my recent career choices.

I had a take home a couple months ago. I'll spare you the details but if the output was to be non-hacky it was 4 or 5 days of work. I put in ~20 hrs, sent it back and said, "Here's where I'm at. I'd love to finish it but it's not reasonable to expect so much time if the final answer might be 'No thanks.' I'm not into such waterfalls..."

To this I'll add, I have a saying: "How you hire, is who you hire."

40 hrs? Waterfall? 2021?? And we all have been led to believe dinosaurs are extinct :)

Same here. Quite a long time ago I got a take-home assignment. It's about setting up a router on a linux-based machine. I was going with a design that focused on maintenance and understanding, so I decided not to use iptables directly. After a few days I gave up, because there was an issue with the upstream distribution that I was not aware of. I actually had a very good setup after the _deadline_, but it's too late.

I would never do take-home assignment again =))

I always do better with take-home assignments than I do with a whiteboard or live-coding interview.

I only accept paired assignments. If you are going to use my time, the least you can do is offer an equal amount of time on your side.

How does this work? Who is the other party (someone from the company?) and what do they contribute?

They contribute the evaluation and time-boxing

"Thank you for your time, we will keep you in mind. Next!"

Point of programming assignment is to see if you can actually write code. No one is waiting for perfect implementation, just working code that fills the spec, documentation, and tests.

"here's a computer, please implement a function in $languageOnYouCV that receives two words and returns true if they are anagrams of each other, false otherwise, if time permits add some unit tests" seems to fulfill that need just as well, and should be quick enough that being in the room or not is more about what makes the candidate more comfortable and gives the most insight for the interviewer.

That sort of problem is about the right level of complexity for a candidate to show they can think about a problem, provide an implementation, and discuss alternatives. Something they should be able to do without ever studying or grinding LeetCode.

However, there's always room for the interviewer to muck things up.

For the anagram problem, there are a range of solutions, including elegant & inefficient, clever & efficient, and robust & efficient. Do you dock someone depending on which they reach for first?

There's limited time, and a candidate may assume you're mostly interested in "how they think" and thus focus on the algorithm alone. After the interview, do you run the candidate's solution against test cases that you never mentioned, docking them for "missing" matters of casing or non-alphabetic characters? If the candidate themselves wrote unit tests, do you dock them for missing test cases you felt should have been included?

Do you dock them for not checking for invalid inputs, even though the candidate might normally work in a type checked variant of the language that wouldn't have permitted that anyway?

So many possible hidden assumptions. I know I've been rejected for similar unstated expectations in the past, and in retrospect, I know I've been guilty of doing the same to others.

At that point it's not a coding exercise, it's a full blown case study.

This isn't a programming contest and your company isn't ACM

That is where we interviewed as an industry 10 years ago. Then people noticed a few holes (what, they don't know fundamental $x!?) and those were filled. List vs map, complexity, tests, trees and traversal, http api stuffs, unixy things, and then into networking fundamentals, distributed systems stuff, etc.

10 years ago, nearly no candidate pulled a distributed queue solution in a design interview and now it is a standard answer in their pocket.

Is the candidate allowed to use google?

Just asking since it's a very easy task but I'd wanna doublecheck how to reverse a string in that language.

anagram, not palindrome.

It helps me on filtering out shitty companies. I don't want to work in a place that does not value my time. And there are plenty of companies to work with.

The take-home assignment seems to me a slightly broken system; it's easily gameable because there's zero supervision.

Let's say there's two candidates for a position who are both asked to complete the take-home assignment, Candidate A and Candidate B.

Candidate A is the superior candidate and spends only two hours on the task (as requested), and Candidate B spends 2 days. Candidate B submits the better assignment and is more likely to land the job as a result, despite Candidate A being the better candidate.

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.

Yup, the worst aspect of it isn't that it takes a long time to make it work right but the feeling of imposter syndrome and the fear of expectations if one manages to get in.

Like, if you expect me to write 1K lines of code in 2 hours as I read documentation, debug, test it - then god knows what the expectations are at a full day at work.