FYI I had no timeline attached to this test, but who ask candidates to work 3days on something before being hired ?? If its what they expected from me I would have straight refused.
Here is what I would have replied to the reviewer should he have asked:
- The choice of using a Laravel back end was an informed decision to emulate as close as possible what would be my workflow on a real life app. Beside as opposed to front-end framework it has almost no cost attached and makes the back-end more maintainable and agile - Laravel is an amazingly clean framework. Finally the assessment of the basic PHP knowledge such as using PDO to connect MYSQL had already be made on paper test so there was no point repeating this there.
- The JS is certainly not perfect, game.js could use some refactoring, but my intent was not to make a production ready app but to show that I know how to write proper and maintainable vanilla JS. Given more time I would have addressed those details (which BTW are not the real issue in that code).
Also you'll notice that I chose NOT to use a framework there as it was not needed. Again this was an informed decision.
- Sudo: I was worried that whom ever would try to install the app bumped into permission issues so I tried to make easier to install. I should have made a note of that. So point taken here.
As for composer, I wouldn't want to work with any company that use PHP everyday and don't know what composer is.
Composer is package management for PHP. Just like Gem or NPM. IMO such a test can be interesting to assess the ability of a developer to organize his logic and architect an application, but using it to evaluate the ability to produce "production ready" applications is my opinion missing the point as it's in the former that you can see the core ability of a developer while the later just requires time investment and tedious grunt work tasks. Witch is why I chose to concentrate on what matters.
No, just stop. Listen to what the parent says here. You made it hard for anyone to review your code because of all the framework misdirection. He/she also reports on your liberal mixing of ui and game state code in javascript which points to lack of understanding of MVC, or separation-of-concerns in general.
If you want to respond, respond to those items, not excuses <- denotes junior-level mentality.
So using abstraction is not something a senior does ? It seems to me like the contrary. The more experience I have the more I like to abstract things instead of making them from scratch.
But even so it seems a bit heavy of judgement to disqualify me with such strong word over this choice.
(this is probably not going to be a very popular answer here, since most people enjoy making things abstract, and feel like they're creating value)
Making things too abstract, too early, is usually a bad sign. In most cases, the most most specific and straight forward solution to a problem is the best one.
There's definitely cases where you're simplifying things by making them more abstract and reusable (but making something reusable before you need to reuse it is a waste of time) -- another good case is where you're using the principle of separation of concerns.
I think when I started developing I made everything very abstract, b/c all the books you read would also tell you that was a good thing.
Also, please do not confuse abstraction with reuse. "abstracting things" has nothing to do with "making them from scratch". You're definitely conflating two things inappropriately there. I can write reusable code that has absolutely no abstraction in it, and I can write code based on an abstraction that is completely un-re-usable.
There's nothing wrong with abstraction. But you should use the right abstraction for the job. You don't need a huge PHP web framework, tons of dependencies, an entire package manager, sudo access, and so on to have a simple memory game with a high score backend.
Remember, when you're looking for a job, you're not looking to create some build and forget application. You're going to be working as part of a team. Other people need to be able to maintain your code. For a problem that should be able to fit onto a single page, you don't want to have to browse through a 7 megabyte git repo with nearly 10,000 files in it.
An analogy might be if someone's trying to hire you as a carpenter. They ask you to build a cabinet to demonstrate your skill. You go and find a prefab house frame, an entire prefab plumbing system, and so on, and build the skeleton of a house. Within that, you build a reasonably functional cabinet, though it's kind of hard to judge the cabinet among the entire rest of the incomplete house. How do you think that's going to compare to someone who just went and build a cabinet, and spent the time getting it built really nicely, paid attention to the detail work, made sure the door hung true and opened and closed without squeaks?
Here are a few things that I note at a cursory glance; and notice that I haven't even gotten to the logic of the code, because all of these things are red flags that come up before I am even able to read it:
1. Checking in dependencies to Git. That's not how it you do it; dependencies should be handled by a separate package manager, in which you depend on the appropriate versions of packages. You should never check anything other than your own source code into Git.
2. Your commit messages. Commit messages in Git should follow the format of an email describing a patch. The first line should summarize what the commit does; the rest of the commit should contain a description of why you are doing it. See the following for an explanation of what good commit messages should look like. First from the Git source itself:
3. Inappropriate use of frameworks. You included a lot of dependencies that are unnecessary for the problem at hand. Dependencies have real costs; every extra dependency is something that could break, could have a security bug, could be a pain to upgrade in the future. Now, that doesn't mean to never add dependencies; but do so with a certain amount of care.
4. Simple spelling and style errors. Tabs vs. spaces. Inconsistent spacing: "var _createCell = function( color, id ) {" and "if ( el.className.indexOf('turned-over') > -1)" (note: decide whether there are spaces between parens and their contents, and stick to that choice). You spelled "RESTful" as "restFul". Things like this are seen by developers as canaries in the coal mine; if you are sloppy about the very basic stuff like tabs vs. spaces, are you really going to be mindful of other important things? Consistency of style is important for keeping code readable, if you can't even keep consistent in a simple code interview problem, why should anyone think that you'll be able to do it on a day to day basis when under real deadline pressure?
Here's my exercise for you. If you want to get better, and be able to pass future job interviews, condense this down into as small a codebase as you can, with as few dependencies as possible. I think that you should be able to do this in less than 100 lines of your own code, and only the most basic of dependencies like jQuery and some simple microframework on the server side.
Give that a shot, and then take a look at both for comparison. Which would you rather maintain? Which will be easier to make changes to? Which is easier to code review?
Regarding 1. As far as I know, npm says in it's docs you should add node_modules to your scm because there is no way to install the exact same version through npm on different machines. On the other hand, composer has a .lock file which specifies commit hashes it installed on the dev machine, so a composer install installs the exact same commit on every machine.
@OP: You didn't commit the composer.lock. That means that your code might run locally but breaks on another machine because there might be a new version of laravel 4.2
Can you provide a link to that? That's not how npm works at all. You specify dependencies as a dictionary: keys are package names, and values are versions. They support commit hashes, but do not require them. See: https://www.npmjs.org/doc/package.json.html#dependencies
I would have made it 755 on my environment but I wanted to make sure the install work properly as I know this is often a friction point during install of Laravel
Then clearly you don't understand how to use your framework, or you don't understand how to run a webserver. Saying "I would have made it.. but..." is certainly not something i'd let fly in my dev team.
I've taken a look at your code and you do not appear to be senior-level material. You managed to turn a relatively small game into 40+ files and 15+ directories of mostly useless framework fluff just to make what appears to be a mostly-javascript game.
- Trying to review your code, I have to navigate a nested tree of framework php and nodejs includes to actually discover what the heck is going on.
- Why do you need nodejs for development? That just introduces yet another framework to install and deal with packaging and deployment. Why not just stick to backbone or some other minimal framework tool in javascript? You're not even importing that much useful stuff to warrant using npm.
- You're doing a lot of manual dom manipulation which looks sloppy
- You've committed a minified css file
Maybe some of the code you wrote might be okay, but your choice of setup and prep for a project seems pretty junior. Get some experience working with veteran developers on more complex projects (i.e. not simple web dev).
Yeah, I confess I'd find it hard to review someone's code with random-looking indentation going on, it's easy to imagine someone treating it as a bad sign. Definitely fix this for your next interview, keep trying though. :-)
I'd suggest paying more attention to how the code shows up in Github next time (assuming they're reviewing it on Github). If I'm reviewing a potential hire's code, I'd want to see that they pay attention to details like that, lest the production code base get super ugly / hard to read.
