I would not waste effort with these test if it is not a language or system you are familiar with (unless you want to for fun). The companies that do this are looking for code monkeys. They want to feed you tickets and get code in return. Many of the people critiquing the submitted code are often not qualified to do so.
In general I'm also not a big fan of these interview assignments but I gotta say it probably heavily depends on how they're used. About a year ago I got my first Go job that way with little prior experience and it ended up being great.
Granted, my assignment was smaller and I knew they would get back to me. If I had been asked to develop a spreadsheet editor from first principles that would have been a major red flag.
I encourage candidates submitting something like this ask the hiring manager what will the process be. Questions like:
- Will feedback be provided on the submitted application?
- What does that feedback look like, are you spending 60 minutes asking about my implementation choices or will you also spend time offering feedback on how I could have improved my solution?
For any hiring managers by providing feedback to candidates you are showing that candidates will grow and develop on your team. By not providing feedback you risk ending up like Roam Research and loosing out on many potential applicants because you demonstrate that you aren't interested in developing your staff.
More than that, I would ask what their acceptance criteria are. I’ve taken a test like this only to get feedback that felt like a giant “got you!” from the hiring manager. There’s so much that goes into coding one of these up, and there’s a limit to how much effort a candidate is willing to put into free work, so this felt kind of bad. This was for Thomson-Reuters on their Clojurescript team.
I just wrote a post about a quite similar experience. I feel like if a candidate takes a few hours to complete a test the feedback could be a slightly more involved process but from the hiring side it doesn't really scale.
Yeah this really captures what I experienced too. There’s zero back and forth which is how you would actually work with someone. I think that’s what bothered me most — it was an unrealistic situation for how people work together, and there was no chance to defend my decisions or feel out what the actual acceptance criteria were.
I would love to know, collectively, how much labor/time is wasted per year on applications that test whether someone is good enough to do “real” labor. It’s bonkers.
It's one thing to have someone write a toy program. It's another to have someone write seven increasingly-complicated toy programs. That's really grotesque and overkill.
I only see complaints when it comes to interviews. People either complain that they're asked leetcode questions which doesn't reflect the real work, or they complain that they were expected to implement real work tasks which takes too much time out of their week.
Unless your complaint was just about the lack of follow through, that's valid, kind of shitty to not be told that you didn't get the job at least.
Didn't even get a reply... it cost me quite some hours to do this in a language I have almost no experience in.
At least there was the upside that I got to experience Clojure and Om which was great to learn about :D