How to deal with unrealistic interview task time estimates

Question

I've recently applied for 5-6 jobs and all have asked me to complete a tech test, but 4 have provided quite considerable tasks, and every one of those stated 'they should take you about 2 hours'.

I sought an estimate on the latest task from an experienced colleague, who stated that it would take 'at least half a day', and that is just task 1 of 2 I need to complete.

My question is how do I deal with this, I wish to pursue this role but how do I tell them that the task is probably 4x the work they believe it is, without making it seems like I'm a slow worker?

Edit: The responses have helped me realised what my question should have included:

Is it likely that the unrealistic time estimate (there is no question that is is unrealistic) is part of the vetting process? If so how do I deal with that?

A couple of points I should have made clear at the start:

• I do not want to just give up and walk away from every employer who does this, I'm happy enough to consider it to be part of the process.
• I do not want to leave myself open to abuse in future if I accept a role with an employer who does this, ie because I met this deadline I don't want it to be expected that I always meet other unreasonable deadlines.

Answer 1

You've asked specifically how you should broach it with them. I would write something like this:

Dear internal recruiter,

Thanks for sending on the take-home task — I've given it a look over and I think to get all the requirements done would take longer than the 2 hours that you've discussed. How would you like me to proceed?

I can spend two hours on it and then add a list of further improvements that I'd make given more time. Would that be suitable for you? If so, are there any areas that you'd prefer me to focus on / ignore?

Please let me know your thoughts.

Thanks

wot

This gives them a chance to say:

• "No sorry, you'll need to complete all the requirements to pass this test." — in which case, you know where you stand & can make a judgement call if it's worth your time or not. You also find that out before you put in 2 hours worth of effort & that have it rejected as a straight "no".
• Or else they can say "Sure, that's fine, please pay attention to unit testing/API design/etc, and it's OK if you don't complete B or C".

(If they're the type of place that gets annoyed for asking, that would be a red flag for me.)

Do keep in mind that if you choose to 'only' spend 2 hours on it, you're potentially competing with people who've spent all weekend on it — whether or not that gives them better consideration is probably down to the internal recruitment policies and is going to be hard to tell.

Answer 2

My question is how do I deal with this, I wish to pursue this role but how do I tell them that the task is probably 4x the work they believe it is, without making it seems like I'm a slow worker?

You don't.

If you don't want to do the (supposedly "at least half a day") work, you decline, then move on to the next company. Otherwise, do the work.

I can pretty much guarantee that if you approach them trying to show that their estimate is unrealistic, or unfair, or how your friend thinks it will take at least half a day, that will be a strike against you.

Answer 3

As someone who reviews take-home interview tasks with similar time estimates, I always appreciate it when a candidate states that they indeed spent 2 hours to work on the task, even if they haven't completed it. This means that, given a hard deadline, the candidate is able to prioritize the most important parts of the task and get them done. We also ask the candidates to attach a README document where they can explain what they would have done given more time.

An unrealistic time estimate does not mean you will automatically fail the task if you don't complete it fully and on time, and it is not necessarily an indicator of company culture. If you're interested in this role - take the task and complete as much as you can within the allotted time frame. If the company rejects you for not being fast enough - don't get too discouraged, an environment where speed of development is valued above all is probably not a healthy one and you should take your skills somewhere else.

Answer 4

I think there are already good answers, but I've been asked to turn my comment into an answer, so here is my take on the situation:

My company does the same. We give out tasks that are rather big, and if you do them in good quality, it would at least take you 8 hours. But we actually know that most applicants will not invest 8 hours for a proof of concept task. So we are perfectly fine with a part of the task, when the applicant does a good job at documenting what he has completed and what he has omitted. We want to see how that applicant thinks, organises and communicates. If you haven't time to complete the task, do as much as you are comfortable with in good quality, and communicate what you left out.

The last two applicants did the following:

• Applicant 1: Did half of the task. Did it very throughly, documented his thought process, documented the time used, asked questions for clarification. Got the job and is now a very productive member of our team
• Applicant 2: Did the whole task, but got nothing quite right. It was a hardware design task, he selected parts with wrong power rating, outdated parts, some placeholders without footprint, etc. The schematic was so rushed, integral parts were missing. Of course his journey ended there.

From a company point of view: Giving out big, very open ended and poorly defined tasks can be a good measure to judge applicants, if done right. If done wrong, you loose good applicants because they get annoyed and drop the application. Communication in all of that is key, not only from the applicant, but also from the company.

Answer 5

Imagine the following scenario from the perspective of the hiring manager:

• Applicant A returned the assignment the next day, and it is of a "good enough" quality. When you ask them how long they actually worked on it, they say they worked 2 hours as requested.
• Applicant B returned the assignment the next day, and it is about as good as that of applicant A. When you ask them how long they actually worked on it, they admit that they actually worked 4 hours on it because they wanted to deliver the best work possible.
• Applicant C does not return an assignment. You instead have an email in your inbox saying that they are unable to complete the task in just two hours and call it an unrealistic time estimate.

Which one would you hire?

Should I be convinced that applicant A says the truth about finishing a task in 2 hours which took another candidate 4 hours, then I would hire them. They are obviously the more qualified candidate. If I think they are lying about finishing in 2 hours, I would hire applicant B. They exceeded the deadline, but they were honest about it. And they were able and willing to fulfill my expectations regardless and delivered on time.

I would certainly not hire applicant C because they didn't even try to fulfill my expectations.

---

OK, so you certainly don't want to be a C. But you don't think you have what it takes to be an honest A. And you don't want to be a B either, because you value your time too much. So what can you do?

A possible course of action could be to:

1. Make an honest attempt to fulfill the task
2. Stop after two hours
3. Submit the incomplete results
4. Attach an explanation that you ran out of time and would have implemented features A, B and C using approaches X, Y and Z if you had N more hours.

This puts you ahead of an obviously lying applicant A and might give you an edge over applicant B whose approaches to features A, B and C were worse than those you described.

Answer 6

My question is how do I deal with this, I wish to pursue this role but how do I tell them that the task is probably 4x the work they believe it is, without making it seems like I'm a slow worker?

Having unrealistic expectations and deadlines since the interview tasks could be a red flag that more unrealistic deadlines will come in the future if you are accepted.

It could also be that they are "bluffing" or hand-waiving the complexity of the task given, so you are not discouraged and give it a try.

Still, I advise you to be very aware and trust your gut on this one: if this feels like it's too much work and they are maybe using this interview task as a "free dev work", then chances are they are indeed... feel free to refrain from doing the task, and politely thanking for their time, if you don't feel ok with what they are asking you to do.

The good thing is that you have other options to consider, and some have more realistic deadlines and tasks for you to do. Perhaps you should focus on those instead.

Answer 7

Take a look at it from their perspective. They're receiving too many resumes from far too many unqualified candidates. And they think that this take-home project is a good way pre-screen most candidates.

This isn't to say that completing a perfect take-home project will automatically get you the job. After all, they won't know if you're the one who completed the project, or if you had someone else do the work for you. This is why this kind of project should only be seen as a pre-screening process. Once you pass this pre-screening, you will be tested again during the follow-up interviews.

So with this in mind, here are some things you can do on your end:

• Apply to jobs using internal employee referrals. Through the use of internal employee referrals through my first-degree and second-degree contacts on linkedin, or through contacts I've made through competitive programming websites, I've personally been able to short-circuit the take-home project pre-screening process a couple of times.

• Work on your github portfolio. If you have a good personal github portfolio to begin with, you can ask that they review your github in lieu of doing the take-home project.

• Avoid using 3rd party recruiters, unless they're using an email address/alias directly from the client company. The less intermediaries you have between the hiring manager and yourself, usually the less pre-screening you'll need to go through.

And if you do decide to do the project:

• Ask to speak directly to the hiring manager (if you haven't been in contact with them already) to make sure you understand the criteria of selection for passing this stage. Ask if you will receive feedback from the hiring manager himself/herself on the actual work you do.

• See if with modifications and using none of the copyrighted materials provided by the company, the take-home project could later be used as the basis for a personal github portfolio project for yourself.

• Expect ambiguous requirements. Dealing with ambiguity is part of our job sometimes. In some cases, this means you will be expected to ask clarifying questions. In other cases, this may mean that you'll be expected to make some of those decisions yourself.

• And for some projects, don't be afraid to say 'no'. If things don't feel right, or if you feel they're not respect your time, it's ok to walk away sometimes.

Answer 8

It could be they don't actually know how long the task should take and are giving you a "guesstimate".

It could be that they know that the task should take longer than they've told you and want to see how you deal with unrealistic deadlines and pressure.

It could be any number of other things.

All you can do is to do your best in the time allotted. What happens beyond that is beyond your control, so don't get yourself worked up about it.

Answer 9

I think this is a very common situation, sadly resulting from both sides of the hiring equation - candidates and employers - making mistakes and covering them.

Other answers here assume some additional competence in the companies' recruitment process, and that they are either deliberately setting hard deadlines as part of the test to see how candidates react, or are happy to accept partially-done or low quality answers. Having seen the way these tests were handled by my own employers when I was a core part of the recruitment process, and as a candidate, I fully subscribe to a variant of Hanlon's razor here, where the intent is to give a fair test that can be achieved in a reasonable amount of time, but the end result does not work that way.

I think the following factors combine to make the actual task time larger than it should be:

• Companies are often interested in making a task complex enough that it tests code structure and design issues.

• After designing a moderately complex task, wishful thinking by staff involved in the rescruitment encourages them to make estimates that may seem do-able, so that candidates will apply, and the recruiters feel reasonable about themselves.

• Familiarity with the problem description by the people designing the task can make technically competent staff give low esitimates.

• Companies setting new interview tasks rarely sense-check any part of them by having existing staff not involved in the interview design perform them.

• Best practice code writing, iterating on designs, documentation and unit tests are often not considered or only partially considered when estimating. This is a common problem with estimates on real-world tasks too.

• Candidates, eager to impress, and not being observed carefully, will often underplay the extra time they put in to polish a task. They may well have an idea conceptually solved in the first hour or two, and then spend two to four times that polishing the end results, getting good code coverage etc.

• Candidates that present great code with best practice and lots of polish are noticed when the code test is analysed in isolation, and more likely to be put forward with positive comments about the test solution.

• If it is not checked automatically, then the time taken to complete the tasks is rarely checked, or followed up. Even when it was obvious that someone put far beyond normal effort into a task, or the information volunteered this was not raised or seen as a negative point against their recruitment. What was noted was the quality of the work.

When I have worked on recruitment tasks I have seen evidence of these issues. As a candidate I have experienced a wide range in how reasonable the real length of tasks and time estimates can be. Many companies do manage to set technical tests that are achievable in two hours, and many do not.

A reasonable compromise is to use an automated test which somehow times the candidate - emailed instructions with 3 hours to respond (triggered by candidate), or online resources like HackerRank can both work. Timeboxing the tests in this way may be unfair or awkward for other reasons (it sets up exam-like pressure for instance which is not realistic in a real job), but at least it limits the time investment expected from the candidate.

Whatever the reason, the test is set up by the employer, and as a candidate you are not usually in a position to change or challenge their process. Unfortunately, you are also undermined by other candidates competing for attention and willing to put extra effort in.

I would not advise you to comment or push back on any recruitment tasks, unless you are feeling confident that it will be well received (have you already spoken to the hiring manager, and did they suggest you could contact them about the task). In each case you have to make a judgement call on whether you want to perform the task, and how much effort you want to put in for the role. Treat the time estimate like you would if a colleague had done the estimates for some task that you go handed, and forgot about some details, so it could be quite a bit out unfortunately.

In the last year, in a similar situation to your question, I tried time-boxing myself to the suggested time (1 hour). I produced a script (in Ruby) that did everything that was asked for. In the same overall test I also produced code that demonstrated that I understood good use of class composition and unit tests - there was a separate more focused tech test as well as the more extended task. So I decided that it would be OK not to "polish" the tech task script, just demonstrate that I could analyse a problem and produce code to solve it. Result: I was rejected with a comment that my code was not well structured and that they were expecting unit tests. I believe that is due to one or more of the driving factors I listed above.

So my advice is: Decide whether you want to apply based on your assessment of the task length, and whether you want to give up a week of evenings or half your weekend just to apply. Then either apply with your best attempt at the task, or politely decline.

Answer 10

I believe that one of the purposes of this task is probably to see how you deal with being assigned unrealistic tasks. They're trying to find out whether you're

• the sort of person who goes hell for leather on a fool's mission, or
• the sort of person who speaks up early when assigned an unrealistic deadline.

Here's how I'd approach this. Say to the interviewer "I don't think I can finish this task satisfactorily in just two hours. Would you like me to spend exactly two hours on it, then hand in what I have managed to complete? Or would you prefer for me to complete the task and let you know how long it took?". Then act accordingly.

That will mark you as a better employee than someone who takes on unrealistic tasks without flagging the problem.

Answer 11

The time estimate probably comes with some assumptions about the tools you have at hand. At my company we tell people that our "take-home test" should only take a couple hours, but that's true only if you have a development environment already set up. I can complete the assignment within 2 hours since I already have everything I need set up, but if you need to install Vagrant and get a VM running for the first time in your life, well that's going to take a bit longer.

But when we score it, we don't consider even for a second how long it took you to actually do it. We can't know that just from looking at the code. The things we care about are:

• Correctness (including edge cases)
• Runtime efficiency
• How idiomatic the code is
• Readability
• Being well-documented and not over-engineered

We would rather take on someone who can do the job, even if they do it slowly, rather than someone who can't do the job at all.

With that said, your time is precious, so if you don't have the time to do the task, I think it's fine to pass on the interview and move on. In my opinion, time estimates by recruiters serve a nefarious purpose, anyway: they convince you to spend enough time on it for the sunk cost fallacy to kick in. :)