How to handle interview technical tests that are absurd (e.g. an unreasonably large task with a short time limit)?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

I don't like referring to other answers in my answers, as answers should be able to be understood by themselves. However, the currently 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.

Answer 4

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.

Answer 5

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.

Answer 6

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 ;)

Answer 7

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.

Answer 8

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

1. gets annoyed and leaves or
2. the one who silently tries to work it out or
3. actually tries to argue and explain with management what things are unreasonable or
4. gets so stressed out you don't know what to do or
5. 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?

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

If the assignment would take you an unreasonably long time, I suspect you simply are not the candidate they are looking for. Shrug, thank them for considering you, and move on to the next interview.

If this happens frequently, you may be interviewing for the wrong jobs, and should consider either something more junior or closer to your core competencies. Or consider upskilling before applying for these positions., to extend your competencies before they ask you to demonstrate them.

If the problem is that they are looking for a superhero who doesn't exist... They are entitled to waste their time looking. It's a pity they waste the candidates' time too, but that is unfortunately part of the process. When looking for an enchanted prince, either as employer or employee, you're going to have to kiss some frogs.