> Here's a task that takes a day to do sloppily and at least two days for you to show your best work. We want to be respectful of your time so please don't spend more than 2 hours on it.
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.
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.
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.
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 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 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'
but then they pretend its a meritocracy
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.
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 :)
I would never do take-home assignment again =))
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.
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.
This isn't a programming contest and your company isn't ACM
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.
Just asking since it's a very easy task but I'd wanna doublecheck how to reverse a string in that language.
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.
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.
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.
Nothing complicated - shouldn't take too long.
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?
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.
If you are having time pressure challenges with our assignments we also don't want you.
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.
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.