If an interview includes a technical test involving an unreasonably large task and short time limit, does it make sense for a candidate to turn in work that does not meet the candidate's quality standards to finish by the deadline? And if the candidate does attempt the task, and the scorer fails the candidate without offering useful constructive criticism of the candidate's work, how can the candidate react in a professional manner?

How can I decide if I should take on technical tests that I consider absurd (e.g. an unreasonably large task with a short time limit) in the future? (Not just for this particular instance.)

I am a contract software developer with over 20 years of experience, so frequently I have very brief interviews and often a technical test too, usually to be completed at home.

Recently, I was put forward for a large company I was a perfect match for, had a very brief 'interview' which was more an informal chat of them explaining what they wanted. They said there was a quick technical test to do and they understand that prospective suppliers like myself do not want to spend hours and hours proving themselves, so I wasn't overly worried; usually they are a handful of questions or ask me to build quick console application to demonstrate a few concepts.

The technical test for this company was to build an ASP.NET MVC website, with a REST API back-end, that connects to a database, and on the MVC website build an administrator page that allows you to search for users in an autocomplete fashion.

The test was to be completed in two hours.

It's of my expert opinion that nobody would ever storypoint this to being anything like two hours of work, if done properly. I would put a few days down at least to get the architecture right, etc.

However despite this I blasted through it as best as I could and came up with a fully working solution that wasn't too badly architected. They asked for a few questions to be answered as well, to be submitted with the response, including, "What would you have done with more time?". I put in followup e-mail the bits that I cut corners with, and why I wrote it the way I did. I also wrote it using .NET Core 2 because they said that's what they were using for their system.

I think I did a pretty good job, cramming all that into two hours of development.

The response via the recruitment agency was that they couldn't get it to run, and so they had a developer look at it who said it was very poor quality.

I think the reason they couldn't get it to run is because .NET Core 2 is very new and notoriously tricky to get working properly - any kind of version mismatch between the SDK you have installed and the one used to write it can create issues as I deployed it to my own server afterwards to see why they said it didn't work, and I had to update my local SDK to match the server.

The fact they said it was poor quality suggests that the developer they showed it to was not taking into account the time constraints. I wasn't able to get any other feedback; the recruiter pretty much ex-communicated me as a result of their negative feedback, which is incredibly annoying.

I'm more annoyed about them saying my work wasn't good enough, because I have that personality type where I hold myself to an incredibly high standard, and the fact it has burned me with the agency, than not getting the job. As a contractor I am usually brought into companies where incompetence reigns supreme (the development team walks out, the development team has no idea what they're doing, terrible management, etc.) so I may just be able to chalk it up to that.

So this leads me to my question:

How can I decide in the future if I should bother with this kind of "Kobayashi Maru" of technical tests, where I look incompetent if I complete it within their time frame? Should I say, "Sorry, but this technical test is not possible to complete in 2 hours?", or is there something else I could or should have done?

I would like to add that I am a contractor, not a permanent employee. This means I'm running a business here; I will do any kind of work within my skill set regardless of whether the client is good, bad, horrible, incompetent, etc. because it comes with the job. It also means there are much fewer options when it comes to places to work; while I can get a permanent job easily, the same is not true for contract work.

  • 8
    This reminds me of the tax service places that show up around my town every year near the end of the first quarter each year. They hire people to stand beside traffic dressed up in costumes and wave signs to bring in customers. The interview process for this job is to stand by traffic for a few hours in costume, waving a sign, and looking enthusiastic. People tend to be told they weren't enthusiastic enough, and not get the job. But they never actually have to hire anyone as long as people keep "interviewing". Aug 7, 2018 at 13:20
  • They want someone who has done this many times before, and who doesn't need to study the technologies or design from scratch. Mar 17, 2023 at 13:45

11 Answers 11


By walking away from them.

GS (Goldman Sachs) once wanted a small code sample from me, which ran down to an exchange order book simulator. Nothing too particular, EXCEPT they specified full test coverage and PRODUCTION CODE QUALITY. For something that critical it runs down to a week of work testing every single edge case, because this type of code is extremely critical.

I sent the recruiter an offer and told him that if they don't pay - no play.

Some companies have stupid ideas and put up ridiculous tests. Your example is similar - there is no freaking way to do that in 2 hours outside of having it already prepared. I daresay this is borderline fraud. It likely is just a sign of comical incompetence.

Remember this is IT - and IT is a sellers market. Tons of jobs - no specialists. Behave like that. Do not deal with idiots. I refuse any coding work without PRIOR interviews, because there is another side: All those "interesting, challenging" projects are just the same stupid same over and over anyway. I want to know first whether I want to waste MY time, because I love to actually do projects I like, and recruiters totally have no idea what projects are about these days.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Masked Man
    Aug 3, 2018 at 3:45
  • 17
    * there is no freaking way to do that in 2 hours outside of having it already prepared. * -- Or the job was destined for someone internal who already knew what the test would be... Aug 3, 2018 at 7:59
  • 9
    Still does not matter. The only way to do that would be to have the code already prepared. Does not matter how much you know, at a certain point even pure typing speed is not enough.
    – TomTom
    Aug 3, 2018 at 8:07
  • Instruction was to create an algo that printed this. gist.githubusercontent.com/cmikec/9e926a20e5d04b942b03/raw/… Is that considered as ridiculous? Their product is sort of a booking app where you can have errands done for you. Sep 24, 2019 at 15:43

Remember, when a company is interviewing you, you are also interviewing them.

Use inane tests as a screening tool.

If the TEST gives you unreasonable goals and timelines, guess what you can expect on the job.

Don't take it personally, a bad test is not a useful gauge of your skills. If they say your work wasn't good enough, and you know that it was, then they obviously aren't going to appreciate you on the job either.

Again, it's not you, it's them.

  • 69
    I once received a test where I was asked to write a calendar app and document its Big O performance. I documented the performance of the standard collection I had chosen, and noted that 1) the performance could be tuned by changing one line of code; 2) the optimal choice would depend on usage patterns, and they hadn't provided any; 3) for small collections, theoretical performance is usually dwarfed by fixed costs; and 4) in production you would base your decision on testing, not theory. Not only did they not accept this answer, the recruiter gossiped about it to my current co-workers. Aug 1, 2018 at 20:27

Hindsight being 20/20. This is what you should say next time:

"As a rule of thumb, I don't do any take-home homework unless I speak with the client first."

"Are you the client? No, then connect me with the client's hiring manager. And no, if you work for HR (you're not the client unless you want me to build an HR-related application)."

"Ok, what does this person do for your company? Will he/she be the person I'll be reporting to should your company hire me? Ok, yes. I want to speak to that person."

Once you're finally talking to that person, then you say something like:

"Ok, have you read my resume? Do you think we can skip this entire take-home project?"

Assuming that the hiring manager still doesn't want to skip it, then you could say:

"The problem is that I've been burned before.

For one thing, I don't know if I should just build the project from scratch, or just reuse some of the code I have lying around? One time, I built the project from scratch in a couple of hours, but I was criticized for not having a production-ready application.

And another time, there was a small version mismatch, and their IT didn't know how to tweak the configuration file to make my project work."

But whatever you do, don't give this explanation to the recruiter. Don't explain and don't justify yourself to the recruiter. It's useless trying to explain yourself to a gatekeeper. The more information you give a gatekeeper, the more likely he/she will use that information against you, since by design, a gatekeeper very rarely has the power to make concessions, but on the other hand, their role is more about looking for reasons to screen candidates out.

So assuming you've been talking to the actual decision maker, the hiring manager you'll actually be reporting to, and assuming you're getting good vibes from this person, you could say:

"Ok, I am willing to do the take-home project, but I'd rather be there when my project is installed and evaluated.

Do you think we could set up a time when I could come in with my code and we could set it up together on one of your developer's machines? "

"How about this upcoming Wednesday? [...] Will you be there? Will one of the developers be there as well? "

But again, only do this if you're getting good vibes from this person. Trust your own gut feelings. If for any reason, you feel they're using this take-home project as a lazy way to screen many dozens of applicants. Or if for any reason, you feel they're trying to extract some free work out of you, so they can put it in production, do not agree to the homework.

The same goes if you show up and they don't want to install/review your project when you're there. If they want you to do their homework, they have to invest some time into you as well. It's a show of mutual respect.

And if for any reason, you're not getting that respect. For instance, if they swapped the engineer you were supposed to meet with an HR person at the very last minute. Be polite, but be firm. Do not give them your take-home project. Tell them that you'll be glad to reschedule the interview and leave.


I don't like referring to other answers in my answers, as answers should be able to be understood by themselves. However, the top voted answer basically boils down to "The company is a pack of idiots. Run away from them." This gives the OP nothing to improve about themself, and nothing to change in the future. I see areas that the OP could improve, regardless of whether the company has done anything wrong or not, which we as answerers don't actually know, since we have only heard one side of the story.

As far as I can see, you didn't communicate before you started the task that you firmly believed it could not be done in two hours.

Here's the sequence of events how I see it:

  1. You were asked to complete a coding challenge
  2. When you received the challenge, instead of communicating your concerns, you started coding
  3. You rushed the challenge, cutting corners
  4. You submitted a low-quality project that didn't work without a lot of fiddling
  5. After receiving feedback, you started justifying your work

Here's how I imagine the company saw it:

  1. The candidate accepted all the conditions of the challenge
  2. The candidate submitted the project on time
  3. The project didn't work
  4. Our lead developer said the code was very poor quality
  5. The candidate started making excuses for their work

Imagine you are in a work situation and your manager/team leader asks you to complete a task in an unreasonable amount of time. If you don't immediately communicate that you can't do that much work in that little time, then any failure is your fault for accepting the initial conditions. You are the expert, not them, and they rely on you to communicate with them.

I can't stress how important it is that both sides have a common understanding of the situation. You had an insurmountable gap of understanding because you missed your opportunity to address it. Next time you have a problem, communicate it straight away or the other party will think everything is fine! Not communicating important information is lying by omission, and any form of lying is unprofessional. How they react to the information is their responsibility, not yours.

I recommend reading The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin (Uncle Bob), in particular:

  • Chapter 2: Saying No
  • Chapter 3: Saying Yes
  • Chapter 10: Estimation
  • Chapter 11: Pressure

If the company rejects your application because you asked for feedback and clarification before starting the task, they haven't filtered you out, you have filtered them out as a company you don't want to work for.

  • 6
    While I do think the OP was probably better off not working there, I think it's great you give actionable suggestions he can actually use for improvement. +1; I do this type of communication every day, and it's one of the most important parts of my job in actual fact. Correct estimation of effort and setting accurate expectations (which doesn't mean "lowering expectations" either, by the way; sometimes people estimate 4 months when it can be done in 2 days).
    – Wildcard
    Aug 3, 2018 at 4:47
  • Which top rated answer exactly? Aug 7, 2018 at 10:46
  • @VolkerSiegel This is one reason why I don't like referring to other answers. The one that starts "By walking away from them."
    – CJ Dennis
    Aug 7, 2018 at 12:27

I've encountered some smart and some stupid tests (SQL/BI) and have actively walked out of one that was stupid, explaining that what they wanted was the wrong approach.

I have also seen tests that were actually attempts at a free project, with "sample work" that was essentially a new solution. Again, I declined to complete these.

It happens, I chalk it up to experience and move on. I always schedule interviews for after hours, so there's no real loss on my part.

  • 91
    I had a 2nd interview where I was teamed with a programmer employee and we worked pair programming for two hours on his current project/task. They told me up front that it was real work and they would pay me for it, which they did. I think it was an excellent solution - get real work honestly, see the candidate in action in the real work environment, let the candidate experience the real work environment.
    – Mar
    Jul 31, 2018 at 18:36
  • 4
    That is really cool. Some of the big name companies here have incredibly intensive interview programs that are unpaid, with like 5 rounds and a giant tech test that involves integrating with their APIs. They pay well once you have the job, but it's a lot to invest if you don't think your skills intersect enough.
    – NibblyPig
    Jul 31, 2018 at 19:01
  • 3
    @MartinCarney Getting paid is the crucial part there. That sounds like a really good part of an interview so long as you get paid regardless of if you get the job or not. If your not paid, then they are just asking you to give them stuff they can profit off of for free, and that probably breaks a few laws, even if you signed a contract that had clauses saying you gave up your right to be paid for your work and intellectual property.
    – Ryan
    Jul 31, 2018 at 19:19
  • 12
    @Ryan absolutely. When you consider that it costs thousands or tens of thousands to acquire one employee, being unwilling to pay advanced candidates for their efforts is a little absurd.
    – Mar
    Jul 31, 2018 at 20:17
  • 1
    exactly - OP sounds like he encountered spec work, not an interview
    – NKCampbell
    Aug 1, 2018 at 16:56

Well you tell them exactly what you'd tell your boss if confronted with that task.

Either they don't know what they are doing, then you'll learn a lot about the company, or they want to see that you don't waste time (company money) doing things poorly instead of talking to the person without the technical knowledge to judge this.

There are two outcomes, you pass with flying colors for doing the right thing, or you've dodged the bullet and don't have to come back in two months telling us how your boss demands impossible stuff ;)


Here's my approach:

  1. Communicate with your contact at the company that you don't think it's possible in the time, and what you plan to actually do.

  2. If there's time to wait for an answer, wait; if not, do what you intended, and document your choices in detail

  3. Ideally sketch where you would take the rest of it.

Note that very few interviewers actually calibrate and test that a task takes 2 hours. If you really want the job, take it to some level of completeness in a given amount of time.

As you've discovered, quality usually trumps fitting in with time, unless they have strict mechanisms to ensure all candidates fit within the time.


This reeks of fake test to map up your personality, especially how you handle absurd and stressful events. Are you the kind who

  1. get annoyed and leaves or
  2. the one who silently tries to work it out or do you
  3. actually try to argue and explain with management what things are unreasonable or
  4. get so stressed out you don't know what to do or
  5. are you the one who pretends to try to work it out but give equally absurd made up results back because that's exactly what anyone coming up with such a task would deserve?
  • +1 Gauging how the candidate reacts under pressure is a common interview tactic.
    – Eric
    Aug 9, 2018 at 22:26
  • @Eric I've never seen it happen, but it's what I would guess would be the reason if it happened. Maybe more common in other places than where I've been. Aug 10, 2018 at 8:50

It’s of my expert opinion that nobody would ever storypoint this to being anything like two hours of work, if done properly. I would put a few days down at least to get the architecture right etc.

Begging your pardon, but you’re missing the point.

Think of it from the team’s perspective. They want someone who’s familiar with all of ASP.NET, MVC, REST, talking to a database, and the moderately advanced feature of one autocomplete textbox.

Could I get these things done? Yes, eventually. After all, I’ve heard of all these things, so I might go ahead and list them on my resume. An expert like you will be able to wire together a working system under the time limit because you deal with this stack all the time, but I’d have to spend hours digging through the manuals.

A resume is a piece of paper where listing bullet points is trivial. A bad hire is worse than no hire. I assume you did not have a personal recommendation from someone on the team, so the hiring manager is looking for a demonstration of competence. True, a real production-ready system would take much longer, but the test did not ask for production-ready because it asked what you would’ve done with more time. Success on the test shows that you are fluent with all the layers and more importantly that you know how to prioritize. Make it work and then make it pretty!

A two-hour test is not the time for architecture astronautics.

Moreover, you are almost certainly not the first candidate to see this test. The team has used and perhaps tweaked their filter multiple times, and at least one developer has gotten through. Turning up your nose — as has become highly fashionable in recent years — in righteous indignation or “educating” them why it’s a bad test will, in their view, put you in the bozo category. Phew! they’ll think, another procrastinator or primadonna we don’t have to deal with.

How to handle it? Look at it from your prospective customer’s perspective. Rather than dismissing as absurd, give the benefit of the doubt. For a two-hour test briefly note your assumptions, make the sunny-day case for the simple demo work, and in the time remaining document how you’d make a real system robust.

  • 6
    I dont think you read the question properly. OP did what your answer says to do, and still the client disregarded his solution because of what the OP believes was an SDK mismatch or something trivial. He tried to approach the situation as you indicated, with a hacky but working solution but met an incompetent development/IT team. Can you reframe your answer to address the full question? Aug 2, 2018 at 1:06
  • 2
    I don't think it's fair to make assumptions outside of what the OP has stated. If you think the OP has the wrong idea, you must first reframe the question (which is completely fine) then answer that appropriately. Right now your answering based on assumptions that you've not substantiated or proven. Aug 2, 2018 at 2:38
  • 1
    I'll agree with @GregBacon on this one -yes, a 2 hour test isn't about the best architecture.It's a tight deadline, but .net mvc will do almost all of the heavy lifting on this - anything else is massively overthinking the brief (and missing the point somewhat). And, unfortunately yes - complaining afterwards will sound like sour grapes. Aug 2, 2018 at 4:42
  • 1
    Sounds like a good approach. It's what I did back in my Uni days. Okay, we had a week rather than two hours, but at the end of the day you still have a system that is perhaps not as complete as you'd like it to be, so you write about potential future work. This demonstrates that you know how to develop software and manage your project, and that you are always thinking of next improvement steps. It could simply be that this was what the interviewer was looking for, though I will concede that the specific requirements listed in the question seem particularly extreme for a 2-hour timescale. Aug 2, 2018 at 17:02
  • 1
    This is a good counterpoint to the top-voted answers. Note that if this really were the goal, the interviewers should say, "The purpose of this test is for you to demonstrate that you have sufficient experience with these technologies to put together a basic working framework quickly. It needn't be perfect, but it should work."
    – Wildcard
    Aug 3, 2018 at 4:44

This answer makes no statement on whether these kinds of tests are a good thing or not (or whether I condone them), but focuses on the specific question.

How can I decide if I should take on technical tests that I consider absurd (e.g. an unreasonably large task with a short time limit) in the future?

Like you would do in the real world:

  • Communicate how long the task would take reasonably.
  • Lay out your plan of what to do in the given time (i.e., do less, or do it worse, or both).
  • Do as much as you can, to the least level of quality which you can stomach. Focus on getting a working solution before a complete solution.
  • Document clearly where you cut corners, what the implications are, and the resulting TODOs.

All of this would help me greatly, as an employer or client, to judge whether I want to to work with you.

Depending on the management structure of the employer/client, the guy employing you (i.e., your direct boss/customer) could very well be in a position where he cannot influence what kind of work you get. Matrix management does exist... in this case I would prefer to have someone who can handle such situations with grace over a hero who delivers the greatest code of all time, but is not able to communicate about time/quality limits.

The exact measure of whether to go for more quality, or for more content, depends. For example, in your case, you will probably be mostly interested in them seeing that you can provide quality work. So you might cut a few features (by using some placeholder etc.), but keep your code quality high. Similarly, if the work were, say, security related, you would do the same. But if it's a completely uncritical proof of concept of something, then one might veer more in the other direction. Document all of this (succinctly), and you're well on your way.

PS: I like to avoid "mad or bad" judgements. I.e., you should not care about whether the client is just crazy, or out to get you (i.e., have you perform work for free), solely judging by the size of the task. The real quantity that matters to you is your time, and that was fixed. As long as you're fine with investing the two hours into a potential new client, it should not matter whether the task is easily done, or a high pressure job, or just two hours of small talk at their office.

  • I don't agree with your last point. It will likely give you more trouble in the future if you get a reputation that you can be pushed around anywhere. Maybe you simply don't care, but other people will care and they may erroneously think being handled like that makes you feel bad and that will make them pity you no matter how little you actually care about their silly pressure games. Aug 7, 2018 at 4:15
  • @mathreadler, I understand what you mean, generally, but I don't see the relationship to my last point. My last paragraph is purely "internal" and contains no advice on how to act visibly. Or did I formulate it wrongly to give that impression?
    – AnoE
    Aug 7, 2018 at 9:24

As other answers have at least hinted, the motivation behind the test could be reasonable, particularly if the test:

  1. Is well-tailored to the actual job requirements;
  2. Minimizes less-important elements;
  3. Is clearly not an attempt to get "free work"; and possibly
  4. Comes with at least some hints about what the reviewers are "looking for."

At a previous job, I designed and administered an arguably-"absurd" programming test. The job was always a senior-level full-stack ASP.NET/SQL Server developer job, and the task involved creating a very basic web application involving one page and two or three simple stored procedures. The candidate performed the test on-site using standard tools:

  1. Visual Studio (version of candidate's choice within the past two or three versions);
  2. SQL Server Management Studio; and
  3. A web browser, not just for testing but also for looking up documentation, resources, etc., which I specifically told candidates they were allowed to do.

I provided the candidate with a basic "shell" solution (in each of the permitted Visual Studio versions), and I created the database and tables in advance.

I gave the candidate a one-page description and told the candidate that I would come back in ten minutes to answer any question about it, after which time she would have one hour to complete the task.

When I returned after ten minutes, after answering any questions, I told the candidate that if she wasn't sure she could finish every part of the task within the hour, she might consider focusing on part of the task that she could complete and get running in the allotted time. I also mentioned that if she had further questions during the hour, she could find me two cubicles away and ask.

Because I wrote the test, I could complete it from start to finish in about forty-five minutes. I absolutely did not expect candidates to complete the entire test in one hour. The "absurd" time limit was in place for three reasons:

  1. We wanted to see whether the candidate had even a half-reasonable grasp of the job requirements. Remember, this was for a senior-level position. (Well over half the time, the answer was "no.")
  2. The candidate should be able to analyze basic requirements and split them into manageable, discrete tasks.
  3. Extending the test past one hour would take more of the candidate's time without giving us much, if any, additional information.

At the conclusion of the hour, I asked the candidate to show me what she had, whether she had any part of a running solution to demonstrate, etc. We would generally take about five minutes to go over the work at this point, then the candidate would have a one-on-one interview with the manager. During that interview, the development team would all look at what the candidate had submitted. We really looked forward to this duty because it was never dull.

If the candidate had a running solution that handled its intended part of the overall task, the candidate almost certainly passed this phase of the interview. Even if the solution didn't run yet, if we could see substantial progress and evidence of the candidate's competence, we would typically still consider the candidate. We always checked the candidate's browser history to see what resources she accessed.

Reasons actual candidates didn't succeed included:

  1. Literally producing nothing after the full hour. I'm sad to say this situation happened multiple times.
  2. Plagiarizing code from the candidate's current job and attempting (and failing) to modify it to meet the requirements of the test. When we suspected this, the browser history would give it away.
  3. Inability to form a connection string to connect the application to the database. This one might seem a little unfair, but remember that we were looking for senior-level candidates, including senior-level SQL Server development experience. We certainly didn't expect the candidate to remember how to construct a connection string, but we did expect the candidate to be able to look it up quickly. ConnectionStringBuilder would also have been absolutely fine, but no one ever used it. The very first example from https://www.connectionstrings.com/sql-server/ would have worked just fine.

There was another part of the interview with the manager and the development team together, and we would ask questions about the candidate's solution, how she would have approached the rest of the project, etc.

In summary, I advise considering the employer's motivations for an "absurd" test before dismissing it out-of-hand.

You must log in to answer this question.

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