ukmuiik

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.

Todd Wilcox 1,6111615 · Answer 1 · 2018-07-31 18:37:04Z

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.

Comments are not for extended discussion; this conversation has been moved to chat. — 2 days ago
* 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... — 2 days ago
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. — 2 days ago

score 154 · Answer 2 · 2018-08-01 17:15:44Z

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.

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 at 20:27
@TKK What's most comical is that an entire app doesn't have a Big O performance, as that metric is specific to a single algorithm operating on a specific data structure. — Aug 3 at 0:26

rath 11.6k74267 · Answer 3 · 2018-07-31 15:57:26Z

Document your decisions in the code.

/**
 * Application entry point. The entire test was to be written in 2 hours,
 * and a lot of corner have had to be cut. Where possible this has been
 * documented in the code. Please look at the accompanying report for
 * further explanation on the decisions taken due to time constraints.
 */

And so on for each major module.

Provide a document which includes a rough time-spec - you mention a few days to get the architecture right which should've been on the first page. They shouldn't have had to ask for a write-up, they should've started evaluating your submission by reading that. Any instructions to set up the environment should be in there as well. You could've provided a Dockerfile with the versions already set up. This could be a 2-hour task on its own, and it's absolutely fine to cheat here as long as it's documented.

CYAing in the code comments makes sure whatever poor schmuck gets to evaluate it knows immediately what they're dealing with and adjust their expectations accordingly. This works in case they use a blind evaluator with little knowledge of your constraints.

I have used this technique several times to great effect. Throw whatever you can together, but leave lots of "TODO: xx" and "UGLYHACK: xx" comments so that the reader understands what you would have done had you been under a realistic schedule. The person reading your work might not have the same problem statement that you have, and may not be aware of all of the restrictions. — Aug 1 at 22:31
Start with a readme file so if this is checked into source control, it leaps out at someone who is reviewing the code. — Aug 2 at 8:30
See, when I was in the same situation as the OP, the reviewers didn't even look at my code (I know this from the Github insights) they just looked at the end result and listed all the incomplete things. I was gobsmacked.They wanted more than a week's worth of work and estimated 4 hours for it, so I handed them 4 hours worth of quality code resulting in a tight MVP. Obviously it wouldn't be polished and production ready, 4 hours wouldn't even be enough for testing...I'm furious just thinking about it. — 2 days ago
@EdmundReed Hard not to be, but you just have to sleep in the knowledge that people who operate like this are doomed to failed and badly ran projects and you're better off being no part of them — 2 days ago
I used this approach just recently when I had a take-home test for an interview. The task was not overly ambitious, but their given expected output did not match what the problem indicated and it wasn't clear why. I tooled around trying to find what they were looking for exactly for about half of my allotted 2 hour work period, at which point I gave up, produced the solution that seemed to be intended from the text, cleaned up code where I could, and made comments where I couldn't. I got the job, and during the code review in the follow up interview they praised me for those comments. — 2 days ago

score 24 · Answer 4 · 2018-08-01 23:28:49Z

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.

JohnHC 11.6k82942 · Answer 5 · 2018-07-31 15:44:10Z

up vote
16
down vote

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.

answered Jul 31 at 15:44

JohnHC

11.6k82942

72

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.
â€“Â Martin Carney
Jul 31 at 18:36

2

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.
â€“Â SLC
Jul 31 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 at 19:19

11

@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.
â€“Â Martin Carney
Jul 31 at 20:17

1

exactly - OP sounds like he encountered spec work, not an interview
â€“Â NKCampbell
Aug 1 at 16:56

suggest improvementsÂ |Â

DonQuiKong 457312 · Answer 6 · 2018-08-01 17:10:35Z

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

score 10 · Answer 7 · 2018-08-03 01:06:42Z

EDIT

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.

ORIGINAL ANSWER

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:

You were asked to complete a coding challenge

When you received the challenge, instead of communicating your concerns, you started coding

You rushed the challenge, cutting corners

You submitted a low-quality project that didn't work without a lot of fiddling

After receiving feedback, you started justifying your work

Here's how I imagine the company saw it:

The candidate accepted all the conditions of the challenge

The candidate submitted the project on time

The project didn't work

Our lead developer said the code was very poor quality

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

EDIT

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.

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). — 2 days ago

score 2 · Answer 8 · 2018-08-02 02:35:43Z

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.

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 at 1:06
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 at 2:38
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 at 4:42
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 at 17:02
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." — 2 days ago

Marcin 1324 · Answer 9 · 2018-08-02 19:08:04Z

Here's my approach:

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.

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

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.

score 0 · Answer 10 · 2018-08-02 22:27:45Z

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.

Peter Mortensen 43447 · Answer 11 · 2018-08-04 05:20:56Z

There's absolutely nothing wrong with the 2-hour insane technical test. All other candidates would have to do the same test, so your probability of being offered the job is no different to an easy beginner programming exercise. There was no bias; you were asked to do it simply because you had applied for the position.

You are the seller in the job market, and it's your responsibility to accommodate the buyers as much as possible. You have little bargaining power other than going for another position. Certainly, a programming test that all candidates would have to do is not unreasonable, regardless whether you can actually compete it or not. If you are highly qualified for the job, but unable to complete the test, other candidates would also not able to complete it. So what's the problem?

You try your best. Angry at not being offered for the position? The company has to hire someone, so someone else might have done a better job. The point for an impossible programming test is to find the best performing candidate. Whether the best candidate complete the exercise is irrelevant.

how can I decide if I should take on technical tests that I consider
absurd

You should feel comfortable for any technical test if you think you have the skills for the job and all other candidates would have to do it. Never do an insane test if you believe if it is an attempt for free programming jobs or/and given to you due to bias (e.g. racism).

PS: I never mentioned OP is not "good enough". @TessellatingHeckler

"Certainly, a programming test that all candidates would have to do is not unreasonable" - that doesn't follow at all. — Aug 2 at 2:13
@TessellatingHeckler ?? If candidate A does it, B does it, C does it ... The company picks the best performing candidate, what's the problem? Whether the best candidate actually compete is unimportant. — Aug 2 at 2:15
@TessellatingHeckler OP couldn't compete the test, so were other candidates. Offer to the best solution under the 2 hours time limit. What's the problem with that? — Aug 2 at 2:17
@TessellatingHeckler The question was more like a rant for losing to another better performed candidate. — Aug 2 at 2:18
Ive done a "difficult" programming test in 3 hours. Out of the "A, B, C" tasks, I only managed to complete task A, but they key difference here was that the technical manager and a developer reviewed my solution immediatel after I completed it. This ensures the solution runs, is "fresh", and we have opportunity to go through the code together and discuss it. Btw I did best out of all candidates (no others completed task A) and got the job. So sometimes maybe you just have to make the best out of a seemingly impossible situation instead of freaking out / giving up ?? — Aug 2 at 9:47

Todd Wilcox 1,6111615 · Answer 12 · 2018-07-31 18:37:04Z

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.

Comments are not for extended discussion; this conversation has been moved to chat. — 2 days ago
* 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... — 2 days ago
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. — 2 days ago

score 154 · Answer 13 · 2018-08-01 17:15:44Z

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.

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 at 20:27
@TKK What's most comical is that an entire app doesn't have a Big O performance, as that metric is specific to a single algorithm operating on a specific data structure. — Aug 3 at 0:26

rath 11.6k74267 · Answer 14 · 2018-07-31 15:57:26Z

Document your decisions in the code.

/**
 * Application entry point. The entire test was to be written in 2 hours,
 * and a lot of corner have had to be cut. Where possible this has been
 * documented in the code. Please look at the accompanying report for
 * further explanation on the decisions taken due to time constraints.
 */

And so on for each major module.

Provide a document which includes a rough time-spec - you mention a few days to get the architecture right which should've been on the first page. They shouldn't have had to ask for a write-up, they should've started evaluating your submission by reading that. Any instructions to set up the environment should be in there as well. You could've provided a Dockerfile with the versions already set up. This could be a 2-hour task on its own, and it's absolutely fine to cheat here as long as it's documented.

CYAing in the code comments makes sure whatever poor schmuck gets to evaluate it knows immediately what they're dealing with and adjust their expectations accordingly. This works in case they use a blind evaluator with little knowledge of your constraints.

I have used this technique several times to great effect. Throw whatever you can together, but leave lots of "TODO: xx" and "UGLYHACK: xx" comments so that the reader understands what you would have done had you been under a realistic schedule. The person reading your work might not have the same problem statement that you have, and may not be aware of all of the restrictions. — Aug 1 at 22:31
Start with a readme file so if this is checked into source control, it leaps out at someone who is reviewing the code. — Aug 2 at 8:30
See, when I was in the same situation as the OP, the reviewers didn't even look at my code (I know this from the Github insights) they just looked at the end result and listed all the incomplete things. I was gobsmacked.They wanted more than a week's worth of work and estimated 4 hours for it, so I handed them 4 hours worth of quality code resulting in a tight MVP. Obviously it wouldn't be polished and production ready, 4 hours wouldn't even be enough for testing...I'm furious just thinking about it. — 2 days ago
@EdmundReed Hard not to be, but you just have to sleep in the knowledge that people who operate like this are doomed to failed and badly ran projects and you're better off being no part of them — 2 days ago
I used this approach just recently when I had a take-home test for an interview. The task was not overly ambitious, but their given expected output did not match what the problem indicated and it wasn't clear why. I tooled around trying to find what they were looking for exactly for about half of my allotted 2 hour work period, at which point I gave up, produced the solution that seemed to be intended from the text, cleaned up code where I could, and made comments where I couldn't. I got the job, and during the code review in the follow up interview they praised me for those comments. — 2 days ago

score 24 · Answer 15 · 2018-08-01 23:28:49Z

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.

JohnHC 11.6k82942 · Answer 16 · 2018-07-31 15:44:10Z

up vote
16
down vote

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.

answered Jul 31 at 15:44

JohnHC

11.6k82942

72

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.
â€“Â Martin Carney
Jul 31 at 18:36

2

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.
â€“Â SLC
Jul 31 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 at 19:19

11

@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.
â€“Â Martin Carney
Jul 31 at 20:17

1

exactly - OP sounds like he encountered spec work, not an interview
â€“Â NKCampbell
Aug 1 at 16:56

suggest improvementsÂ |Â

DonQuiKong 457312 · Answer 17 · 2018-08-01 17:10:35Z

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

score 10 · Answer 18 · 2018-08-03 01:06:42Z

EDIT

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.

ORIGINAL ANSWER

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:

You were asked to complete a coding challenge

When you received the challenge, instead of communicating your concerns, you started coding

You rushed the challenge, cutting corners

You submitted a low-quality project that didn't work without a lot of fiddling

After receiving feedback, you started justifying your work

Here's how I imagine the company saw it:

The candidate accepted all the conditions of the challenge

The candidate submitted the project on time

The project didn't work

Our lead developer said the code was very poor quality

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

EDIT

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.

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). — 2 days ago

score 2 · Answer 19 · 2018-08-02 02:35:43Z

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.

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 at 1:06
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 at 2:38
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 at 4:42
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 at 17:02
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." — 2 days ago

Marcin 1324 · Answer 20 · 2018-08-02 19:08:04Z

Here's my approach:

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.

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

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.

score 0 · Answer 21 · 2018-08-02 22:27:45Z

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.

Peter Mortensen 43447 · Answer 22 · 2018-08-04 05:20:56Z

There's absolutely nothing wrong with the 2-hour insane technical test. All other candidates would have to do the same test, so your probability of being offered the job is no different to an easy beginner programming exercise. There was no bias; you were asked to do it simply because you had applied for the position.

You are the seller in the job market, and it's your responsibility to accommodate the buyers as much as possible. You have little bargaining power other than going for another position. Certainly, a programming test that all candidates would have to do is not unreasonable, regardless whether you can actually compete it or not. If you are highly qualified for the job, but unable to complete the test, other candidates would also not able to complete it. So what's the problem?

You try your best. Angry at not being offered for the position? The company has to hire someone, so someone else might have done a better job. The point for an impossible programming test is to find the best performing candidate. Whether the best candidate complete the exercise is irrelevant.

how can I decide if I should take on technical tests that I consider
absurd

You should feel comfortable for any technical test if you think you have the skills for the job and all other candidates would have to do it. Never do an insane test if you believe if it is an attempt for free programming jobs or/and given to you due to bias (e.g. racism).

PS: I never mentioned OP is not "good enough". @TessellatingHeckler

"Certainly, a programming test that all candidates would have to do is not unreasonable" - that doesn't follow at all. — Aug 2 at 2:13
@TessellatingHeckler ?? If candidate A does it, B does it, C does it ... The company picks the best performing candidate, what's the problem? Whether the best candidate actually compete is unimportant. — Aug 2 at 2:15
@TessellatingHeckler OP couldn't compete the test, so were other candidates. Offer to the best solution under the 2 hours time limit. What's the problem with that? — Aug 2 at 2:17
@TessellatingHeckler The question was more like a rant for losing to another better performed candidate. — Aug 2 at 2:18
Ive done a "difficult" programming test in 3 hours. Out of the "A, B, C" tasks, I only managed to complete task A, but they key difference here was that the technical manager and a developer reviewed my solution immediatel after I completed it. This ensures the solution runs, is "fresh", and we have opportunity to go through the code together and discuss it. Btw I did best out of all candidates (no others completed task A) and got the job. So sometimes maybe you just have to make the best out of a seemingly impossible situation instead of freaking out / giving up ?? — Aug 2 at 9:47

Search This Blog

ukmuiik

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

11 Answers
11

EDIT

ORIGINAL ANSWER

EDIT

protected by Masked Manâ™¦ 2 days ago

11 Answers
11

11 Answers
11

EDIT

ORIGINAL ANSWER

EDIT

EDIT

ORIGINAL ANSWER

EDIT

EDIT

ORIGINAL ANSWER

EDIT

EDIT

ORIGINAL ANSWER

EDIT

protected by Masked Manâ™¦ 2 days ago

Comments

Post a Comment

Popular posts from this blog

Color the edges and diagonals of a regular polygon

Relationship between determinant of matrix and determinant of adjoint?

What is the equation of a 3D cone with generalised tilt?

Category

Random preview

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

11 Answers 11

EDIT

ORIGINAL ANSWER

EDIT

protected by Masked Manâ™¦ 2 days ago

11 Answers 11

11 Answers 11

EDIT

ORIGINAL ANSWER

EDIT

EDIT

ORIGINAL ANSWER

EDIT

EDIT

ORIGINAL ANSWER

EDIT

EDIT

ORIGINAL ANSWER

EDIT

protected by Masked Manâ™¦ 2 days ago

Comments

Post a Comment

Popular posts from this blog

Color the edges and diagonals of a regular polygon

Relationship between determinant of matrix and determinant of adjoint?

What is the equation of a 3D cone with generalised tilt?

11 Answers
11

11 Answers
11

11 Answers
11