What would be a good 4-hour development task for a job interview?

Question

We're conducting a job interview for web application developers. First round was an in-depth verbal interview for shortlisting candidates, now comes the second round where selected candidates will have to actually produce working code.

Candidates will have full Internet access, free choice of development environment, frameworks, etc and 4 hours to build a working (or at least partially working) web application from scratch. The development task should test their abilities in all the three usual layers of web application development - database design and implementation, server side and client side development.

Given the very limited time, the task obviously can't be too complex. However I still would like to get a general picture of the candidates' skills regarding development fundamentals. My focus is on data abstraction, database design, using patterns like MVC and DRY, using javascript past jQuery.hover() bindings over menu items.

Here is the short version of one I thought of: Build a currency exchange web application. Use the xml feed at http://www.ecb.int/stats/eurofxref/eurofxref-daily.xml, store currency rates daily in a database, build a web interface that provides a) exchange facility between two arbitrary currency using the latest rate b) historical data presentation for any selected currency.

However I'm not too hapy with that one for several reasons. The db design part falls on rather the easy side, and server side development does not really include any algorithmically challenging problems. Also testing the historical part would be hard (unless I provide a custom historical feed for them to load the db with meaningful values).

What would be a good task for this purpose? Is it even possible to figure out a good problem set for such a short time that truly test all the above abilities of candidates?

EDIT:

Though there were a number of answers with much higher votes that the accepted answer, I still liked Spoike's thoughts on this topic best. Provided a good example and admitted that there are legitimate cases of requiring a candidate to write code on the spot. We did it this way (using the above currency exchange task with some modifications) and I did not regret doing it at all. I talked candidates through their solutions, and seing their differing approaches and their abilities to communicate the whys and hows of their solution helped a lot in the final screening.

Answer 1

Anecdote time!

At one place in a job interview I was once given a programming test in Javascript. The tools I had were basic: Notepad++ and the Internet. The task was to build a simple drag and drop interface with three differently colored boxes, and bonus points if you could make the drag snap by an amount of pixels given in a dropdown box (1, 5, 10, 20, 50). I was also given a working prototype, but was asked not to look in the source code.

All right! A cool challenge, I thought. (I wasn't actually warned beforehand that I was going to do a several hour long coding test).

It took me roughly 3 hours to hack it all together including the snap functionality and me fretting over when the drag didn't work (some code samples on simple Google search don't actually work and have some really bad eval coding). I only needed to get it working in the browser of my choosing (and I coded using Chrome). The code was reviewed while I was sitting next to the programmer and we were going through the code with me answering questions.

I thought it was a fun little and simple exercise, specially when I claimed to be a javascript software developer. But I can also say it was a draining experience at the same time because of the focus that the test needed.

I was offered the job but had to decline because I got a better job offer elsewhere (who didn't do such a test with me).

Anyhow, if I would do such a coding challenge on someone else I'd at least make sure of the following:

• Keep it simple, don't use frameworks so that you can test the basic knowledge that the programmer has.
• Have a clear goal, provide a sketch or a working prototype you've built yourself
• Make it cool enough, (getting div-boxes to move around in javascript was sufficient enough for me)
• Review the code together with the candidate, to see if he is able to communicate his code clearly and discuss possible bugs

I guess this is the way to go if you want a competent programmer who can hack together prototypes and walk you through it. Essentially; all we want from our candidates is to know if they can solve problems. Other than social skills you also need to check for their problem solving skills in the context of software programming or developing, which you do by seeing them in action with a short and simple project.

Answer 2

I don't really like that kind of tests for a couple of reasons

1) They're not applicable to how development really works In four hours they can only be expected to make something rudimentary. What does that really tell you about their skills?

2) Working from "nothing" is really hard for such a short period of time Sure it's a skill but is it something you should judge everyone from? You'll filter out anyone that's a bit more deliberate that might be very fast once they get going

A better test IMO would be to have an existing solution, done in the technologies you find most relevant. There should be a description with "goals" for the solution, like "support multiple languages", "be testable", "Performance"-criterias etc. The solution would also have a number "flaws" relation to those goals and dependencies/architecture in general. Their job would be to refactor the solution as appropriate and also describe potential flaws that can't be fixed within the time-frame and how they could be resolved.

This should test their skill on a more real-life project as well as code comprehension, refactoring, performance and architecture skills

Sidenotes

If you're by doing this kind of interview are saying that they need to be able to perform under tight deadlines and a stressful environment you're also telling your candidate that your job kinda sucks, to which degree is arguable of course.

Overall I'd also like to add that I think "testing" is a lot less accurate at predicting a programmer's skill than judging him on his prior work, his references and his passion for the craft. It's good for weeding out the obvious unqualified but not much more than that.

It's worth nothing that good candidates are evaluating you as much as you're evaluating them. They're have options and if you're lucky enough to find one looking for a job you should "sell" your company as much as they have to "sell themselves". A perfect employeer-employee relationships is like the perfect relationship: two parties which lots of options that choose each other :)

Answer 3

I have hired quite a few developers over the years, and I am more and more moving away from these technical skills tests. I usually have a basic questionnaire with a mix of multiple options questions and free form questions to establish some basics on technical skills.

However, I have found that most people can pick up technical skills. That's not where the problem lies. What is really important is to figure out how this candidate will fit in with the rest of the crew. How does he communicate? How does he operate within a team? Will (s)he follow existing policies or will (s)he insist on doing things his/her way? I have had contractors who absolutely excelled at the technical level, but were a complete nightmare when it came to managing them. OTOH, I have had junior developers who were not all that great at coding, but formed a great team and performed well after a short period of time.

Answer 4

How would a Failure Look?

With basically only one datatype (Currency Exchange Rate) there's not much to repeat (DRY), and i would argue, that using more than what the framework provides out of the box would be a case of 'Yagniy' (so, little database design and MVC), and your requirement so far does not impliy any Javascript (a HTML-Table is also a presentation, and even a nice flash graph can be implemented by providing only a dataview and using one of the free flash graphs to do the rest).

While the test really lowers the chance, that a non-fiz-baz-compliant candidate slips through, it seems to me, that it doesnt proove much more, and a candidate, who manages to demonstrate the virtues you search for in a quantity that can be measured, would tend to overengineer.

Better ways to fail

I would suggest, that you implement the application yourself, present it with the specs to the candidate, and ask him to implement a change request.

This way, there is a chance for failure (DRY is violated, if he implements already existing features once more, MVC is violated if he just fumbles a little in the view instead of propagating the change to the business objects, etc)

Also, the Bias against Frameworks with facilities for setting up new projects would be eleminated. There would be a new Bias against the chosen Technology, but if you choose the same technology he would be working with that should not be an Issue.

Answer 5

The thing is, if you do something like this, then the interviewee thinks this is how he will be treated normally. Your company is under scrutiny from their side too.

I.e. Putting an interviewee under extreme pressure to perform with high risk of failure means less happy interview outcomes and less chance of getting a good candidate.

But, it can be done in a way as to cover knowledge although not as a core interview technique.

e.g. I have done a pair programming session with an experienced programmer at the company I was being interviewed at. This worked well as the tasks we performing were simple, and covered various subjects within programming scope.

Answer 6

I tried to think of a good "full web dev stack" task once, and the best I could come up with was something involving autocomplete.

Autocomplete could involve JavaScript, UI work, Ajax, backend work, hitting a database/data store… It's a pretty small and limited task that touches the full stack.

That said, I haven't actually tried assigning someone this task during an interview, with or without time limit, so I can't speak to how well it works in practice.

Answer 7

4 hours is I think too long and time waster for the developer. To be fair, do something quick may be half an hour. I dont like injustice with developers. If you let him sit for 4 hours and he can do his job, better pay him for his time if you not hire him. Please respect our developers. They are one of the difficult and one of the least appreciated ppl on this planet.

I agree with other answers. One of the basic things is how well do you get along with the developer. Somekind of test is always welcomed by the developer just so he/she can prove his skills.

I was asked a half an hour test just likes yours but shorter. I was asked to implement something like "A user login int and submits a review, All of it is stored in the database". If I could not write the code then pseduo code was acceptable. I had internet access and he could actually see my screen what I am doing. This was a trivial task for me. He came in after 15 min (I believe) and looked at my code. I did do thing the perfect way which gave him an idea (I made out points which previous develper disn't make), I know things pretty well. But then he reject me because he said you did not indent the code proper. I said, well this is just a test to get thing done but anyways.

What was wrong? He did not like my personality. And I think that is the no 1 reason I can not land a job. I dont have a charming personality and that means I may be unfit for most jobs. Not to mention that I extremly kind, polite, love rules and a very good listener. He talked about me perhaps not well dressed, etc.

So I think a test is a great idea, but 4 hours is a bit too long. I have had test before which was I completed at home, they worked but I did not get hired :) So the thing is consider a developer for basic skills, dont abuse him. If he knows the stuff and is acceptable to work with, you can hire him.

Thanks

Answer 8

"Is it even possible to figure out a good problem set for such a short time that truly test all the above abilities of candidates?" It is possible. But, it goes too far when you propose a 4-hr coding task for a candidate who has just walked into your office.

1. Some people take time to adjust to new environments. When someone comes to you for an interview, s/he is obviously coming for a discussion not for an actual project. That's the mindset we carry when we go to some new place of work. Putting a candidate through a 4-hr exercise immediately might build up unnecessary stress.

2. I think it's a bad idea in general to carry out such large coding exercises during interviews. It's like when you are auditioning for an actor, asking him to do a short film on the spot. A good idea would be to ask the candidate if some of his past work/code/design can be reviewed during the interview.

3. It is never possible to "truly" test all the abilities required for a programming job. A good way is to have a problem set and have an open discussion about specific choices, important design decisions, data structures over the problem set.

If you insist on some coding exercise, you can give them a problem set prior to the interview and ask the candidate to submit a solution before they turn up for the interview.

Answer 9

I'd give them a snapshot of a previous project to work from and have them improve some part of it (optimize a bottleneck, fix a bug, introduce a pattern,...) this is what they'll be doing 99% of the time they are working with you

things to pay attention to are:

• readability/maintainability of the resulting "fix"
• if it actually works
• how well it integrates with the existing code
• what else they worked on in that snapshot (what issues they saw as to be worked on)
• how long until they got the idea and concepts of the framework

in the following interview you can then in particular ask about stuff that came up later in that project and see how they would deal with that

Answer 10

We do these but as a 2nd round interview, with plenty of warning to give the candidates a realistic chance.

Task is typically a rather real-world one in my organization -- build a 3 part registration form. It has the right amount of depth and breadth and is really applicable.

Answer 11

The task you have them perform should be representative of the type of think you'll need them to do in the future. If you need someone who really knows how do design complex systems, then perhaps your task should include the design process of a complex system (e.g. airline scheduling).

If, on the other hand, their task will be translating a design into working code, then you should give them a fully fleshed-out design and ask them to code up one small section of it.

If you want an end-to-end project, then pick something simple. Nobody benefits if the candidate spends 3.5 of the 4 hours writing more-or-less the same kind of code. You learned what you needed to know during the first 30 minutes; the rest of the time was just busywork.

Also remember that some languages allow you to write significantly less code to perform specific actions -- writing a webserver in Python or Perl or Go, for example, is trivial since there's already library code to handle almost everything. Writing just about anything in C is going to take much longer.

Answer 12

[I originally only commented, but the OP requested I add an answer, so I'll expand it somewhat and add as an answer - The TL;DR answer is in my original comment]

Setting any kind of development task in a job interview situation has to be approached very carefully, IMHO, however, it's absolutely correct to set such a task as it's very important to get your candidates for a programming position to actually write some code.

The difficulty of course is make the task just difficult enough that you can "test" the candidate's ability to both really think through a problem, then write code towards solving that problem, whilst keeping the task simple enough that you can expect the candidate to produce enough code for you to actually judge their ability in a very small and compressed time-frame.

In interviewing web developers, I've always devised my tests that consist of a complete application. This is somewhat akin to the real-world in that I'll expect web developers to know at least something about the many "layers" of a complete application - the database, the "business logic" code, as well as HTML/CSS and any client-side code (i.e. ASP.NET Markup/Controls etc). I can and do judge candidates on each "layer", but of course, for a web developer I don't expect them to display a "seasoned DBA" level of knowledge about databases for example.

Now, although I use a complete application, I always make it a fairly simple one. Something with a single use or function. My most recent one was a URL Shortener website. Something akin to bit.ly or tinyurl or goo.gl (without any statistics or link tracking). This is a good example, as the functionality of such an application is limited to accepting a long URL and spitting back out a short one. It may include a "preview" page (similar to tinyurl.com), but there's definitely a requirement for some algorithmic logic there in order to produce the shortened URL. (Shameless plug for my own implementation!) The benefits of this are that each single layer is just simple enough to be done relatively quickly (the database, for example, could be as simple as just one table!).

Given that candidates will only have a few hours to complete this task, and given that this is an interview situation wherein candidates are likely to be under additional pressure and display more nerves, I have to take this into account when "judging" their final application. In this respect, this is where the programming task differs quite drastically from the "real world". I believe that as long as you accept and acknowledge that certain factors or metrics differ in certain ways, and then account for that when judging the candidate, you should be ok.

Now for me, the golden rule for this is:

I explicitly stress to the candidate that I am NOT going to judge them on the "completeness" of the application, I am ONLY going to judge them on the quality of the code that they do deliver.

I also always tell the candidate that I expect them to write their very best code for the task, as though this were a real-world, production application I'd just asked them to write. Again, I explicitly state that I would much prefer to see a well-written incomplete application, than a badly-written complete one.

When the time limit for the task is over and I'm reviewing the candidate's code, I don't care if the application is functionally complete or even if it compiles. What I'm looking for is for the code that exists to appear to be good quality code (i.e. SOLID & DRY) and code that demonstrates that the candidate had a good understanding of what was required of the application, and of them.

In response to my original comment, keppla asked:

Is there so much that can be repeated in an URL Shortener? Or a big chance for enough classes to demonstrate the Letters of SOLID?

I tend to agree that it's fairly difficult if not impossible for a candidate to display all of the attributes of SOLID (and DRY) code in such a simple, and probably incomplete, application however it should be easy to show the S in SOLID (Single-responsibility principle) within the code, and if I also see even just a single unit test or even rudimentary dependency injection (or any other mechanism the candidate has employed in order to reduce the dependencies between higher and lower level objects) well, that's a big plus for them. Hell, even the existence of a hand-coded interface shows a level of understanding that lots of other candidates simply won't have.

Ultimately, in judging the candidate's code, I have to ask myself a number of questions:

• Did the candidate understand the problem domain?
• Is this code good quality code?
• Given enough time, would the candidate have completed this application to a good, real-world quality standard?
• Is that time-frame (from the question above) acceptable in the real-world?

That last question is admittedly a bit "fuzzy". You have to try to extrapolate how much time the candidate would have required to complete the application from the code that the candidate did produce.

Although there are more factors involved in making a hiring decision, so long as I can answer YES to all those questions above for the programming task, the candidate will have scored very highly on that element of the interview.

All in all, what you're looking for is: SMART AND GETS THINGS DONE!

Answer 13

I agree with a lot of the comments already posted saying that in depth technical test can give you the opposite to what might be trying to achieve.

I think a better test is to ask the candidate to write some pseudo code to count for 0 to 100 and if the number contains a 3 print 3, if the number contains a 5 then print 5.

You can get a really good feel for whether the candidate actually cares about what they do from their reaction: If there are enthusiastic to solve the problem and relish the challenge then this is a good soft skill to have. If they can't be bothered to do it then they are probably not for you.

Answer 14

My focus is on data abstraction, database design, using patterns like MVC and DRY, using javascript past jQuery.hover() bindings over menu items.

Strip frameworks, full internet access and free choice of environment. You want to test the core skills of the developer. What can he do, what does he know? Someone who can't fix a compiler error without internet is someone you do not want. Someone who can't create a database schema without looking at the internet, is also not someone you want. Frameworks etc. can be learned, if there's a good understanding of the core language/technology. But do give them an offline documentation of the technology in use (e.g. MSDN offline version).

Moreover, I think the task is ok for four hours. You might want to give them a task they cannot possibly finish and tell them so. Then you'll see how they react and how they start building it. Are they poor programmers or do they layout a decent structure first?

A good test should also include all layers of the application. Let them setup the application and explain which technologies they used and why.

Carification: Many people are complaining about a restricted internet access. But the truth is, there're plenty of copy & paste programmers out there, who take most of their code from the internet and put it together to a patchwork program. You cannot judge what a candidate can do on his/her own when you allow full internet access. You don't really know whether they really understand the code or not and there's probably not enough time to ask in detail during the interview. You might totally overrate his/her ability, when all he/she can do is leeching code. Those candidates will have hard times when they have problems which can't be googled. They might seem efficient at first glance, but eventually they produce low quality software which they can't debug.

If a candidate has problems with a really nasty compiler error or technology, help them fix it for the task. You just want to see what they can do by themselves, how they go about the problem, what structures they create. That's the important part. It's not important whether the average candidate knows his XML-Api inside out.

Edit 2: When you've got someone who needs to google elements of the core language or core API, then this person is probably also not familiar with design concepts of that particular technology, too. Let's assume you want to hire someone to create a WPF GUI. This person can quickly google and create a working GUI. But it will probably be a GUI which is a mess. I'm 99% sure you won't apply good structures like MVVM when you're learning the technology on the job or learning while doing by googling. You won't see the good solutions without extensive knowledge of the technology, instead you'll take the next best solution from the internet. And when you know the technology and it's concepts already, a documentation is sufficient.

Also, it depends on the position you are interviewing the candidate for. If you want a programmer, then it's of utter importance that he/she is fluent in his/her core-language with its idiosyncrasies and paradigms. This can't be googled in a short time anyway. I am not only talking about syntax issues! But it's sure a good sign, when a programmer does not rely on google to get the job done.

Answer 15

Personally I'm not a fan of actual "coding tasks" for an interview, least of all a 4-hour one (way too much time for me to be at your company for an interview. Are you going to pay me for that?).

One of my favorite interviews ever was sketching on a whiteboard discussing architecture (not of software) for a theoretical mad scientist's mansion. It was interesting because we talked about various things to get a hang for how I solve problems. Something like that, I think, works better than actual coding; code can be improved upon, but design skills have to be known from the start. Instead of a 4-hour coding session why not do a design session? See if the candidate knows how to design the application and what concerns they would need to be aware of.