47

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.
11
  • 32
    I'm afraid 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.
    – jwsc
    Jul 29 at 6:10
  • 6
    Don't deal with companies who set unrealistic expectations. It does not matter if somebody else considers it fair. It's your time and your decision only.
    – Neolisk
    Jul 29 at 14:58
  • 25
    @jwsc that's answer material right there :) please, consider turning it into one otherwise comments may vanish unexpectedly
    – DarkCygnus
    Jul 29 at 15:56
  • 1
    @Bernhard Barker I believe they know that the task will take a lot longer, if they don't know this or refuse to believe me then I will walk away
    – wot
    Jul 29 at 18:45
  • 3
    With meetings, context switches, etc., a developer in an office will often only get about 4 hours of actual coding in a day. So, 2 hours is, in fact, "half a day" and the experience is in knowing that.
    – thehole
    Jul 30 at 19:48

11 Answers 11

59

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.

1
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Kilisi
    Jul 30 at 18:15
39

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.

11
  • 19
    no, I've a lot of experience in very similar work, I immediately thought the first task is 4 hours, and without prompting a colleague confirmed this, btw they approached me as I have a skillset that matches their requirements
    – wot
    Jul 29 at 7:37
  • 14
    @Joe Strazzere, it really cannot be done fully in the time, no body could do it in 2 hours, I have enough experience to know this, and I asked a colleague for confirmation, so that is not really the question, the question is 'is dealing with an obviously unrealistic estimate of time part of the process'?
    – wot
    Jul 29 at 10:16
  • 6
    @Joe Strazzere I appreciate that you have taken time to comment, but I am asking a generic question that applies to job applications other than this particular instance, I am using this specific case as an example only
    – wot
    Jul 29 at 10:20
  • 10
    This is poor advice. You have a responsibility to inform your manager of any issues that might affect your ability to deliver within the time allotted as soon as you become aware of them. If they expect the task to be done in 2 hours and you know you can't make it, then you let them know immediately and they will make a decision about how to proceed. Throwing up your hands and refusing to even attempt it is extremely unprofessional, IMHO.
    – aleppke
    Jul 29 at 16:04
  • 4
    @aleppke "You have a responsibility to inform your manager of any issues that might affect your ability to deliver within the time allotted as soon as you become aware of them." True, in the context of actually doing the job. In the context of applying for the job, i suspect they've set up the test so they can interview not only the most qualified, but also the most interested in the job. They'll probably have some replies that express interest, and some that express hesitation. Jul 29 at 16:31
32

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.

3
  • 1
    I've definitely come across companies where they give you tasks of increasing hardness and expect most people to fail to complete; if you do it all, that shows you're a brilliant programmer (or lucky, or had seen the exact same thing before), but even if you fail, that doesn't mean you're rejected.
    – Stuart F
    Jul 29 at 16:07
  • 1
    I think this will heavily depend on what the task actually says. If I were to say "complete this task; it will take about 2 hours" (which is how I read this question), I would expect candidates to complete the task, regardless of how long it takes (although if many candidates tell me it takes much longer than 2 hours, I'll rethink the task). If I say "get as far as you can in about 2 hours", or possibly if I were to say "complete it in no more than 2 hours", then that would obviously match the interpretation given here. Jul 29 at 20:02
  • 4
    In real life it usually sounds like "Hey, we've got 2 weeks and we need this done", and as an engineer who understands that there's no way this can be done in 2 weeks it's your job to come up with a plan of what can be done in 2 weeks.
    – Egor
    Jul 29 at 22:04
11

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.

7
  • 7
    Giving out big, very open ended and poorly defined tasks -- especially if the applicants are told it should take them 2 hours -- is a terrible thing to do. Why jerk people around?
    – Martin F
    Jul 30 at 19:03
  • 6
    This is amusing, because I'd expect willingness to do an 8 hour task (or continue with a hiring process after someone demands you do it) to apply to a job is significantly anti-correlated with employability. I mean, most good workers will have plenty of alternatives that don't make those demands. I'm guessing your system filters for marginal employees (good enough to succeed, not good enough to take a pass), or applicants down on their luck, who have no better options than to jump through your hoops.
    – Yakk
    Jul 30 at 19:05
  • 2
    From your perspective, this would look like "most people who apply do a bad job or drop out even though they look good on paper", and you'd feel great about "dodging a bullet" and "picking the cream of the crop". So long as you have a tiny demand for new talent, and are willing to spend a bunch of money on getting new talent, your plan will continue to function. Hiring is hard.
    – Yakk
    Jul 30 at 19:07
  • 1
    This can also be a picture for the applicant of what to expect in the position: big, very open ended and poorly defined tasks with an unrealistic deadline. Jul 30 at 20:05
  • 4
    Do your candidates know this in advance? Otherwise you might be selecting out the better candidates who don't want to waste their time on assignments that are clearly underestimated, while favouring more desperate candidates who'd do anything to get a job. Jul 31 at 7:43
9

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.

5
  • 8
    Hmm. I would actually hire C. If I ask you to do some task in an unrealistic time, and you are able to evaluate the task, do a proper estimation, and argue it correctly? That's way more valuable to me. Assuming, of course, that your estimation is good, and that you're able to complete the task within it.
    – AJPerez
    Jul 29 at 20:59
  • 1
    The question says that A is impossible -- the task cannot be done "good enough" in two hours. Between B and C, C is better. C did what an ideal employee would do -- inform their manager of what they can realistically accomplish with the resources available to them and let their manager make the decision of how to proceed. Jul 30 at 16:07
  • 1
    If someone can look at a task, and quickly and accurately determine how long it will take, that is $$$gold$$$.
    – Yakk
    Jul 30 at 18:58
  • 3
    Giving out big, very open ended and poorly defined tasks -- especially if the applicants are told it should take them 2 hours -- is a terrible thing to do. Why jerk people around?
    – Martin F
    Jul 30 at 19:04
  • 2
    The problem with all this is the expectation that applicants know the context and what you are looking for. Is this a test carefully designed to elicit a specific response (what kind?), or something an HR person found it on a website, or off-the-cuff from a developer who has focused on this area for years and can do it in their sleep, or what? Are you looking for push-back because you had an anxious dev who would agree to any schedule ('don't fire me!'), or proof that they are fast, or 'leadership' (look up 'winnowing'), or what? Not everyone knows and shares your assumptions. Jul 30 at 20:02
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.

6
  • 2
    I received a task where I have to develop a functioning platform similar to IG to perform CRUD with pictures, with full validation and testing. I skipped that employer.
    – Nelson
    Jul 28 at 23:06
  • 3
    @Nelson yeah I believe you. It's not rare to see posts on TWP now and then with cases like that, I also experienced this myself some years ago during an interview... seemed to me like they were giving me one of the tickets and features they had on their TODO list lol
    – DarkCygnus
    Jul 28 at 23:08
  • 4
    I didn't even get an interview. This task was the pre-interview screening they gave to recruiters. I barely know what the company does because they were in some weird "dark mode" startup phase. That one felt more like a scam.
    – Nelson
    Jul 28 at 23:10
  • 8
    I just turn these requests down. I don't do take home tests. If you want me to put in time, I want either money or an equivalent amount of time put in by you. Jul 28 at 23:11
  • 1
    @GabeSechan and Nelson: xkcd.com/1293
    – DarkCygnus
    Jul 28 at 23:18
4

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.

4
  • "they won't know if you're the one who completed the project, or if you had someone else do the work for you." which is one reason we only supply the assignment 2 hours before the interview. It's supposed to take less time than that, but you won't have the time to also find someone else to do it AND review the work so you're familiar enough with it to survive questioning about your solution.
    – jwenting
    Jul 29 at 7:37
  • 3
    @jwenting, Actually, time-limited homework assignments are a good idea. This way, when you're done, you know you're done. Sadly, most of the employers I've run across give supposedly 2 hour assignments without time-boxing them. In other words, you may decide to work on it two hours, but it's unlikely that your competition won't use the entire three days given to them. This turns the process into a race to the bottom. Personally, I don't like it. But I definitely like the way your employer does it. I wish more employers followed your lead. Jul 29 at 18:29
  • IME, the first 3 bullet points are unrealistic. Knowing people at a business assumes you've networked with enough people to have this ability. Having a hiring manager look at your GitHub instead of the mandated task isn't likely to happen. Them looking at GitHub will only happen if they are interested enough to actually interview you, and that won't happen if you don't do the task. Third party recruiters are almost the only way I've gotten a job in the past 20+ years. Most companies just don't use HR for hiring. Jul 30 at 17:54
  • @StephanBranczykI agree, if you want to do such a coding test, force the time limit that way and make the test small enough it can be easily done by a matching candidate within that time frame (so don't give them a 3 day task and tell them to do it in 2 hours).
    – jwenting
    Aug 3 at 6:55
2

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.

1
  • 1
    If they really don't know how to do the task, or how long it should take, then they are guilty of getting free consulting work out of the applicant! Shame on them!
    – Martin F
    Jul 30 at 19:07
2

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.

1

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.

1
  • 1
    Giving out big, very open ended and poorly defined tasks -- especially if the applicants are told it should take them 2 hours -- is a terrible thing to do. Why jerk people around?
    – Martin F
    Jul 30 at 19:04
1

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. :)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .