Full Stack Interview Coding Challenges

It’s been seven years since I was last looking for a job, so I’m not sure if this is a new trend or not: Over half the companies I’ve started the interview process with have given me time-unlimited full-stack coding challenges as part of the interview process. I just completed my third one in two weeks and I thought I’d share my thoughts about this practice in general.

Challenge Requirements
Here are highly condensed versions of the requirements for each challenge:

Company A:

1. Create an ASP.NET MVC application that consists of one page that allows users to add, remove, and rate movies. Movie ratings are to be indicated with a star rating control similar to what Netflix uses.
2. Create a Javascript widget that a user can host on their blog which pulls and displays their movie ratings from the application.

Company B:

Create an ASP.NET MVC website that allows users to upload and view images. If the image is more than 500 pixels wide, or 700 pixels tall, downsize the image to the maximum allowed size, but maintain the aspect ratio. All images should be stored on the server, including the original image when images are resized.

Company C:

Create an ASP.NET application (Webforms or MVC) that allows users to add and vote on Xbox game titles for the company break room. Users can only vote once a day, and they cannot vote on the weekends. Any user can mark a game as owned, in which case it ends up on a list of owned games. The titles and votes will be stored / retrieved via a set of WCF services that are provided for you. In addition to sending the code in for review, submit a URL to a running copy of the application.

What I Liked About the Process

First off, I really liked that these companies wanted to see code. I think far too many places hire developers without seeing a line of code. True, you can determine what somebody is capable of through conversation (especially at senior / expert levels), but I think it’s a pretty big risk. Some people are really good at talking, and / or look good on paper when in truth they don’t know what they are doing.

Secondly, I really enjoyed doing these challenges. They’ve helped me from getting rusty during this period of unemployment. Additionally, I had to learn at least one thing for each of the applications. For company A’s challenge, I had to learn how to create a widget that used JSONP. For company B’s challenge I had to learn to resize an image while keeping its aspect ratio using only the core .NET framework. For company C’s challenge, I learned how to use the MVCContrib Grid and the jquery.dataTable plugin. I also learned and used AppHarbor to host the application.

What I didn’t Like or was Uncomfortable With During the Process

Finding time to do all three of these within a couple of weeks was a little rough. I did find the time, but part of me was wondering if the companies were wondering why I hadn’t turned the challenge in yet. In reality they didn’t know that I was working on three of them simultaneously. This is something I probably should have communicated to them.

The thing I was most uncomfortable with was that I felt like I had more than enough rope to hang myself with in terms of doing things that weren’t wrong per say, but that the reviewer might frown upon due to personal taste. One thing that I was really torn on was how C# 2/3/4 idiomatic I should make my code. Taking advantage of generics, lambdas, linq, anonymous types, etc… could cause the code to look like gibberish to the reviewer if he or she is still writing code in C#1 style. On the flip side, I felt that I would look like I was stuck in the past if I didn’t write modern C#. I’m not sure that finding the middle ground is the right thing to do in this case either as it could look inconsistent.

Along the same lines, I found it very difficult to decide on the right level of architectural complexity to use. These apps were all a bit more than trivial, so I could have gone either way with the complexity. As with idiomatic C#, I found myself wondering if the reviewer was going to think I was oversimplifying or overcomplicating things. Additionally the reviewer may actually want me to overcomplicated things a bit to show what architectural patterns I know. 

These two issues are things that usually get sorted out when you hash over ideas with people in person, but I found it difficult to know who my audience was when given nothing but a set of requirements.

Final thoughts

All-in-all, I thought it was a positive and enjoyable experience. If I’m ever in the position to help with hiring again, I would probably really push hard for code samples to be part of the process. However, I probably wouldn’t give such open ended challenges. I’d probably give multiple smaller and more focused problems.