We only expect you to make what is possible in 2 hours, and we've seen a bunch of similar exercises. It doesn't have to be poor quality, just basic. Usually the UX isn't expected to look nice at all either.
So in 2 hours (according to the article, not this comment) you expect a candidate to deliver a functional reactive single page javascript app, with localstorage offline storage, searching (perhaps with filtering over a "category" model also), responsive, ideally with some form of test coverage & tested on multiple platforms.
I have a long way to go it seems! It would definitely take me more than 2 hours to do that to a standard I'd be happy with. And there's no way I'd submit "what I had" in 2 hours if I could sneak off and spend more hours of the weekend doing it & return something polished.
Do you penalize people who give something "too good" or query them on whether the _really_ only spent 2 hours doing it?
I have no idea, since I'm an iOS dev, not a web dev. We've seen a lot of these coding exercises btw, but the ones I've done have been onsite, so there is no way someone could of spent more than 2 hours on something. Usually the standard is if your able to complete the exercise, that's pretty good! I've only seen tests written once or twice, mostly because there was no time. You also see a lot of shortcuts due to the time constraints. You go through and explain your code, so you can point out 'this is a shortcut, normally I would do XYZ".
Usually when someone makes something 'too good', it usually means they've leveraged libraries that they already know. If they make a lot of code, I know they probably spent more than 2 hours. By making it a weekend project, maybe they are subtly hinting that better candidates will spend more time on it, which I think is shitty and one of the reasons why I don't like homework questions.
I'm assuming for all of the things you've just said, it means you are using libraries that make a lot of those things one liners. Like read/write local storage, search a data struct, reactive UX changes, etc.
CoC (Convention Over Configuration) solves most of the problem for you, since it's basically CRUD, and that is boilerplate stuff in pretty much any language.
Of course the task should be a test of the stuff you'll be doing on the job. If the job is to create quick websites without a whole lot of complexity for lots of clients, this would be an apt test. I'd fail that miserably and probably not like the job anyway. If the job involves working on more complex backend systems, then have the candidate write an async messaging system or DB storage system from scratch. I'd ace that. If the company has a large product, give multiple projects and let the candidate self-select.
Maybe we're just very different. It would only take me minutes to whip up a few Django models, a few CRUD views and a Bootstrap frontend, but I've never needed to write a messaging system or DB storage from scratch (there are dozens of these off-the-shelf).
That having been said, most of my value is writing sane, readable, cohesive code that can easily be extended years later, with a minimum of refactoring. That's what has been most valuable to the businesses I've worked with, and employers love the fact that my team is the one with the lowest implementation times for new features.
Yup, everybody's different, nothing wrong with that! I appreciate people who do the work you do, but not every software company does websites at all. And even of those who do, plenty have grown to the point that off-the-shelf doesn't work anymore and some specialization is of greater value. (Think Uber, Slack, etc)
Yeah, exactly. You'd need to go to one of the big companies to need those skills, so you usually get companies who want some sort of API glued together with off-the-shelf components, mainly because smaller companies are much more numerous than larger companies and off-the-shelf is good enough at small scale.
This wouldn't cut it at the companies you mention, I agree. I think the main thing is that the actually valuable skills (being able to figure things out on your own, having an intuitive sense for when a solution is suboptimal even when you don't know the optimal solution, knowing design patterns, etc) are transferrable, so a good developer could work on either thing.
It probably wouldn't take two hours to become acclimated, but after a short ramp-up period, they'd be pretty good at it.
a) Creating a frontend form to submit movies b) Creating the database to store movies c) The 'search to find the movies' feature
Maybe I could do it in two hours, but it'd be pretty bad, and there's no point showcasing poor quality code.
My favourite was when they asked me to produce examples of things I had coded. Like any other creative industry, a portfolio is normal.