FYI - last beating of the dead horse. In addition to candybar and some of the other devs here, I ran my X assignment by a guy who used to consult for us and is now the "node guy" at Heroku. He also has tons of angular and general JS experience. He was a little easier on me than candybar with his initial assessment of my app. I think we have very similar KISS approaches.
But he did make one really interesting point after reading X's feedback on the assignment.
Quote:
Based on the feedback, and the spec, I think you made the right call there. I'm not impressed with their critique of your solution because of this:
"More broadly, we're looking for evidence that someone has worked with large-scale apps and a code base shared by many developers who may (by necessity) be ignorant of each other's work." (review)
vs.
"We’re trying to assess your architecture expertise, not the framework author’s. Libraries like jQuery or Underscore will help you with busywork, but frameworks like Ember or Angular will rob you of opportunities to show off your chops." (spec)
These two statements simply aren't compatible. The premise of multiple teams working on a large-scale app together is *based* on the idea that they have a shared understanding of an underlying framework - this is why companies like google and facebook build and use systems like angular and react! What do you think would happen if one of facebook's 1000 engineers came in and decided to totally reinvent everything the rest of the company uses for his next project?
As far as I see it, this conflict leads to three possible scenarios:
1. You build what a good developer should: a small, pragmatic solution that meets the spec while being open-ended enough to grow later as the team and spec grows. Following their spec, you don't use a frontend framework, but you also don't invent your own home-grown framework because that's a terrible idea and a huge waste of time.
2. You ignore their spec and build the sort of thing that you really would in production - build and test systems along with a front-end SPA framework like angular, react, ember, knockout, etc. Of course, if you did this, they'd have a valid reason to fail you since you broke one of the requirements listed in the spec.
3. You build your own crappy version of angular, ember, react, etc, and use it to implement a massively over-architected solution that's much larger and more complicated than solution #1. This appears to be what they're looking for.
Worse, they were very unclear about what they actually wanted (I'd have guessed #1). I hate working for customers who can't communicate their actual business needs.
The irony is, you have a lot of very valuable experience you could bring to their team. When checking out that spec I was thinking, "****, this would be like round 3 for suzzer on this kind of app."
I hadn't thought about that massive disparity between the review comments and project.
Part of the problem might have been the manager over the device team department was out. So the director of the entire UI department (the guy who originally found me on linkedin) was filling in facilitating the assignment with the engineer. I get the feeling the director is not technical at all. It could possibly have gone differently if the device team manager had been around.
I'm glad it didn't though. Even if the job was going great - I would have been depressed for a year+ uprooting and moving to a new place where I didn't know anyone. I've done it before, comes with the territory. And if the job sucked on top of that it would have been horrible.
