151

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.

  • 1
    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". – Darren Ringer Aug 7 '18 at 13:20

13 Answers 13

252

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 '18 at 3:45
  • 9
    * 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... – djsmiley2k Aug 3 '18 at 7:59
  • 7
    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 '18 at 8:07
185

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.

  • 59
    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. – TKK Aug 1 '18 at 20:27
76

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.

  • 32
    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. – bta Aug 1 '18 at 22:31
  • 4
    Start with a readme file so if this is checked into source control, it leaps out at someone who is reviewing the code. – Andy Dent Aug 2 '18 at 8:30
  • 3
    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. – ESR Aug 3 '18 at 4:13
  • 3
    @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 – Dan Aug 3 '18 at 8:15
  • 2
    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. – Adam Smith Aug 3 '18 at 20:31
31

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.

20

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.

  • 85
    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 '18 at 18:36
  • 3
    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 '18 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 '18 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. – Martin Carney Jul 31 '18 at 20:17
  • 1
    exactly - OP sounds like he encountered spec work, not an interview – NKCampbell Aug 1 '18 at 16:56
19

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.

  • 3
    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 '18 at 4:47
  • Which top rated answer exactly? – Volker Siegel Aug 7 '18 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 '18 at 12:27
12

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

4

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.

2

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.

  • 5
    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? – damanptyltd Aug 2 '18 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. – damanptyltd Aug 2 '18 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. – marcus.greasly Aug 2 '18 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. – Lightness Races in Orbit Aug 2 '18 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 '18 at 4:44
2

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 '18 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. – mathreadler Aug 10 '18 at 8:50
1

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. – mathreadler Aug 7 '18 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 '18 at 9:24
1

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.

0

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

  • 7
    "Certainly, a programming test that all candidates would have to do is not unreasonable" - that doesn't follow at all. – TessellatingHeckler Aug 2 '18 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. – SmallChess Aug 2 '18 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? – SmallChess Aug 2 '18 at 2:17
  • @TessellatingHeckler The question was more like a rant for losing to another better performed candidate. – SmallChess Aug 2 '18 at 2:18
  • 5
    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 ?? – vikingsteve Aug 2 '18 at 9:47

protected by Masked Man Aug 3 '18 at 5:45

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.