The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have had a couple of take home coding tests recently and I wanted to see what people thought the expectations were for these.

In the most recent one I was asked to code a thread safe message queue for scheduled tasks, with a number of other specific company related requirements. You can potentially spend a lot of time on this, a few people I showed estimated that this would take at least 4 hours to do a simple implementation of all the basic requirements.

That led to a discussion of what is the appropriate amount of time to expect someone to spend on a take home code test? And, if you're spending 4 hours on something like this, do you expect an opportunity to review what you've turned in with the developers who looked at it?

How do you handle it if you get no feedback about how long they expect you to spend and are just told to take a few days?

share|improve this question
Many times an employer will specify some of these things. If you are wondering about what etiquette is expected if none is specified, then you might want to add that detail to the question. – NickC Nov 12 '12 at 18:07
You take the project home. You do the best you can with what ever resources you can and return what you complete as soon as you can... I do not understand what is hard about the concept – Chad Nov 12 '12 at 23:53

Typically you do not get to review what you submitted.

The take-home test is an alternative to an interview that attempts to lessen the impact of stress on the candidate. Because it is a quick measure, it usually acts as a filter rather than an indicator: "Was the code decent/consistent?", "Is there anything particularly wrong with it?", "Would you be OK looking at this kind of code in your code base?". It does not decisvely determine fit or your general aptitude.

Regarding the time - this should be established by the contact person; it can vary quite a lot. I've had tests that took an hour to code with about a week given to me. Other people would give you one day, or until the end of the day (assuming interviews happened in the morning).

share|improve this answer

IF you are told to take a few days, and not take a day and send in the results, then I expect they are telling you that they are looking for someone who can in a few days write code well, thoroughly, and correctly.

It sounds like what they are looking for is someone who can take a task, run with it, do it correctly and bring it back to them in the allotted time given, with little to no supervision.

If you get to the second round of interview, they probably will ask you about your code, about why you did what you did. If they bring you in, then they saw something that they liked, but be prepared to be grilled over your code.

I remember a time when I had something like that done to me. I wrote some beautiful HTML code, simple, and it did the job very well. I was grilled over and over again about it because they wanted to see if I would change my mind on the code, they tried to put doubt in my mind about it. They grilled me about it's function, they asked me why I did it the way I did, etc... hell they even asked me why I was using CSS the way I was.

I stood behind my code, and later I was told I should of as well because there was nothing wrong with it. They wanted to see if I knew why I did what I did, and wanted to make sure that I wasn't just being a script monkey and copy and pasting script to make myself look good.

So if you do get a call back, be nice, cordial, but make sure you know the code that you sent them, because if they are as tough as my second interview was they may question everything to throw you off guard.

Good luck either way.

share|improve this answer

Generally, the time bound is something discussed when the question is given that there should be a ballpark of how long one should spend on the problem. In some cases I can imagine finishing a take home coding problem in 20 minutes, in some cases a couple of hours and in other cases 20 hours to give a few orders of magnitude here.

If I make it to the next interview round then there may be an opportunity to discuss what was done though I'm not sure I'd expect the opportunity. For me this is part of analyzing a company's process. Is it the kind that you do the work and then never review it to see its quality and offer feedback or is there some work done to provide proper feedback to develop one's skills?

If they don't specify even after I've asked for an estimate on the time to be spent on the task, I'd probably spend about 3 hours on it and recognize that even if it is just partially finished that should be adequate. Sometimes the key with the test is to know that there will be many different things considered including can you turn in something half done?

20 hours could be reasonable if the company gives 2 weeks to a month to complete the task and wants to see a full solution including tests, analysis and other stuff that generally would be considered 'fluff' by most other people. I could also see some companies doing this for students about to graduate to see if what kind of experience they have while still being in school for another month or two so it isn't a rushed decision. While it is on the high side, I could understand a rationale in some companies where the work is intended to be done solo without many questions about how it got done.

share|improve this answer
Does anyone think that 20 hours is a reasonable amount of time for someone to ask a candidate to take on a coding test? – tmfkmoney Nov 13 '12 at 15:11
20 hours is not reasonable unless they are paying top dollar. – kevin cline Nov 13 '12 at 16:18

I'll admit, first, that I've never given or taken a test, but assuming I had the option either way, I'd take the tact that the communication about the test is just as much a part of the "interview" as the test itself.

Just like a vague work assignment, I'd start with askng for a ballpark and/or offering my estimate. "It looks like about 4 hours of work - is that what you're expecting?" and even clarifying the level of quality assurance expected and other factors for review.

I'd say (knowing nothing about the specifics) that 4 hours for something like this sounds pretty reasonable. Especially over a couple of days. I know of very few coding tasks that are less than half a day's work, and in other job avenues I know of candidates spending quite a bit more than 4 hours (per opportunity) preparing for the application/interview process. Given, also that most interview processes can culminate in a half a day or a day of interviews, it hardly seems unreasonable to ask for 4 hours of time you can schedule however you like over several days.

But it IS good to clarify, just to make sure expectations match. And it's good to keep track of how much time you're spending - if you've gone wildly over (double or triple the time estimated), then you're either way off, or this company has some crazy expectations. Figuring that out during the process, and before you've lept into the position would be an advisable approach, given that you CAN end up in situations where managment's expectation of work load is way out of sync with reality.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.