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.