Is my work on a developer test being taken advantage of? [closed]

Question

I am looking for a job and have applied to a number of positions. One employer responded. I had a pretty lengthy phone interview (perhaps an hour +) and they then set me up with a developer test. I was told that the test was estimated to take between 6 and 8 hours and that, provided the results met with their approval, I would be paid for my work.

That gave me some pause, but I endeavored. The developer test took place on a VM accessed via RDP. The task was to implement a search page in a web project that requests data from the server, displays it on the screen in a table, has a pretty complicated search filtering scheme (there are about 15 statuses and when sending the search to the server you can search by these statuses) in addition to the string/field search. Additionally, they want SVG icons to change color on certain data values, and some data represented differently than how it's structured in the database.

Loooong story short, this took a heck of a lot longer than 6-8 hours. Much of it was due to the very poor VM that I was running on (Visual Studio 2013 took 10 minutes to load, and another 15 minutes to open the 3 GB ginormous solution).

I was told that after completing the test I should commit my changes to source control... Hmm, OK. I followed directions. And after committing the changes, I was emailed a response. The SVGs weren't colored right, there was a bug in this edge-case, there was an occasional problem with this other thing that I never experienced, etc. So I am 13-14 hours into this thing now, and I have to do bug fixes. I do them, and the employer comes back with more bug fix requests.

All my work is apparently going into a production application. I noticed a few anomalies in the code where it looked like others had coded all of one functionality but hadn't touched anything else.

Am I just being used for cheap labor? Even if they pay me the promised 50 dollars an hour for 6 hours, I have committed about 18 hours to this thing now. If I bug fix all of the stuff they keep coming up with, I will have worked at least 16 hours for free.

I have taken a number of developer tests, but I have never taken one during which I worked on code destined for production. I have never taken a test where I implemented a feature that was in the pipeline for development, and I have never taken one that took 4 rounds and a total of 20+ hours. I get the impression they are using their developer test to field some of the functionality on the cheap.

Do I have the wrong impression? And is this testing protocol appropriate?

Answer 1

I would never participate in a code test of this nature. I have taken many code tests and done many code projects. I certainly wouldn't check code into someone else's repository under any circumstance. If they don't know what they need to know after a 4 hour sample with some minor bug correction in a pair-programming session, then they won't ever know.

Going into a test, you should know and make clear a few things up front:

1. It should be agreed upon and known that any work produced during the test may not be used for any purpose other than determining your skill at the required tasks.
2. A code test should not last more than 4 hours.
3. You are not an employee of the company, so any suggestion that you might be paid for code produced is preposterous. Insist on a written contract of payment if there is even a hint of this.
4. Set specific limits on the time you will spend on any given part of the test, and then stick to those limits. If you find yourself going over the limits for any reason, consider why you are going over that limit. Is it because of pressure from them? Is it because you've made mistakes? Is it because you've poorly estimated how long something should take to complete?
5. Stand your ground if you feel you have covered a particular topic. If you've already fixed a bug, and they're asking you to fix a nearly identical bug, say "We've already covered that topic with bug x, perhaps we could move to something else that demonstrates something new."
6. Under no circumstances should you check anything into a production pipeline. This includes into any kind of development branch that may ultimately lead to a production pipeline. When in doubt, check nothing in. For code tests that are not necessarily in person, I insist that the code be checked into my personal public repository first. This gives me at least some kind of protection from having my work used inappropriately.
7. Judge them for their behavior every bit as much as they are judging you. If you feel they are not being up front with you, call them on it. If you feel you are being mistreated, speak up.

The company you are interviewing with is also being interviewed by you. If this is how they are treating someone they are interviewing, is this a company you want to work for? I understand that often people have a need for a job and often this need will override some common sense concepts, but this should always be in the forefront of your mind. Don't be afraid to walk out. If it doesn't feel right, follow your instincts and vote with your feet.

Answer 2

Many interviews are followed by tests. Those tests are needed to ensure that you actually have the required skills and to give a better view of a few things which are difficult to test during the interview itself (such as do you apply style rules to your code).

This being said, a test is a test.

• It doesn't need to be long. There is not much you can see after eight hours of coding that you cannot see after thirty minutes. More importantly, code written during the test should then be reviewed, line per line, which takes an important amount of time. It is not unusual to spend more than two hours to review the test code written during half an hour.

• It shouldn't deal with an existent code base. Understanding the code base of a medium-scale product may take days or weeks (or months or years depending on the code quality and technical debt). Intellectual property may also be an issue (unless the code is open sourced).

  When the goal is to test how the candidate is able to maintain the existent code base, the test can be done on a small (500-600 LOC) fictional code base written specifically for the tests.

• It doesn't have to be a request to develop a real-life app or feature. It can be a completely useless piece of code, written with the sole intention to show that you've understood the problem and found an elegant way to solve it.

• It doesn't have to be perfect. There are bugs? That's fine. Take a note of them for a further interview with the candidate; it can be an excellent opportunity to see how the candidate reacts in this situation.

• It doesn't have to be done through RDC on a VM, unless you don't have Visual Studio yourself. If the goal is to see your coding and problem solving skills, it doesn't matter where do you do the exercise.

• It's out of question for the code written during this test to end up in the version control of the company. Why would they pollute their version control with something written by a candidate?

To conclude, when you're asked to spend dozens of hours writing production code, solving bugs, and committing your work to the version control of the company:

• Either they are just using you to implement features for free,

• Or they really don't understand how to do an interview.

In both cases, look for a better place to work.

Answer 3

Not going to write a long answer, but I am seriously confused, why is nobody bringing up the issue of copyright?

As far as my experience goes I have never heard about an agreement being made to transfer copyright ownership of code written during a developer test to the other party. If this is the case you can actually sue them for copyright infringement and the damages awarded for this can be quite nice, especially so in the US from the stories I have heard. And if they want to settle (do propose this) you can ask any exorbitant fee for the infringement (after which they would in principle still not be allowed to use your work and you could still sell your work to them if they would still be interested).

Answer 4

People with more career experience may be better able to answer this question, but I personally would not be very comfortable with a 20+ hour dev test. It sounds like they are using the interview to get work tasks completed.

I am assuming that you have not signed any legal documents concerning ownership of the code. So I would wait until they reviewed the code and accepted or denied it. Then if they accepted it I would ask to get paid for the full time, 20+ hours. I'm not sure that I would take payment for just the six hours that was originally suggested. If this is going to go into production, then they will need to straighten out code ownership.

At the very least, discussing payment for the code should help you decide whether you would want to accept an offer. I wouldn't want to accept an offer if they thought only paying you for six hours was fair.

Answer 5

When I was in a position to interview developers, those tests were short and simply "pass or fail", no bugfixing included, even when there were a few minor bugs in the code. That's because I wanted to assess the candidate's skills, not get a production ready piece of software.

The situation described in the question looks very much like someone is trying to get something useful for free (or cheap).

Answer 6

I've never done a dev test more than an hour long, and these have all been 'puzzles', a piece of work to see if I can solve problems and meet a stated aim within a given time limit.

$50 (or to me, £25-30) is a pretty poor day rate, it's like asking a plumber to fix your toilet in exchange for a drink.

My advice, in no uncertain terms, is to blog about your experience, referring to the company by name in case they're trying to create a whole app with this technique (people often google companies before heading to interview) and don't let it happen again. Next time they ask for a bug fix, you name a consultancy day-rate (at least 5 times what they've been offering) and make it known that developers will not work for free.

Being fooled is, sadly, part of life, but you don't have to sit back and accept it.

Answer 7

Just for comparison: The interview for my current job was around 1 hour talking about what I did so far and what the company is planning to do and how I would fit in. After that we worked together a week on a small project they had lying around, I guess just to see how we get along with each other. They paid me for this as freelancer the same amount I get now as their employee, so there was never a full day of unpaid work, let alone 3 days.

If the code is really used in production, I would send them the bill for the 24 hours you have spent, not your fault if their estimations are wrong. Assuming they didn't let you estimate how long it will take.

Answer 8

While you are supposedly getting paid for (some of) your work, this does not sound like a trial project, it sounds like a scam to get cheap/free work out of you. It may be that it is was intended to be a trial project, just not structured or managed very well.

But managment that is so bad that it is sounds like a scam, is definitely something you should take into consideration when deciding whether to take the job or not.

A proper trial project should make it clear that

• They have work that they desire to have done.
• Based upon your interview they believe you should be able to do the work.
• Sucessfull completion of the project does not guarantee a position.
• Terms for the project (how much they will pay, who owns the code, whether it is time and materials or flat rate, estimated time to completion, etc).
• The project will be reviewed and feedback provided -- not just a yes/no as to whether or not you get the position.

The terms should be acceptable to you regardless of whether you get hired -- if the terms are only acceptable if they come with a full time job, they aren't really acceptable.

Answer 9

I don't think they would actually use this to get cheap labor.

The reason is simple. After you write those tests, they need people to review what you write, yes reviewing code is much easier than writing the code itself, but it still takes lot of time.

And then after that they probably need people to maintain those tests, explain it, etc..

And I simply cannot imagine any IT company that would care about saving less than $100 especially companies in the US. It's never how business runs.

Answer 10

I'm a great believer in code tests for developers interviewing for a job. However, this sounds like the code test from hell... Code tests should never involve production code. They should be simple and should state that none of the work done will be used by the company.

Clearly, the work you did was on production code. You should be paid for all of your time - at a minimum. Try talking to an attorney and see if he thinks it would be worthwhile to sue them. Many attorneys offer free initial consultations. If fraud was involved, and in this case it looks that way, you would be entitled to quadruple money damages, and you might also be able to get some nice punitive damages on top of that.

By suing them and winning, you will make some headlines and discourage this practice by others in the future - which will be beneficial to all software developers looking for a new position.

Answer 11

Coding tests are unfortunately a fact of life. That said, it bothers me to be asked to blow four hours on a coding test as a condition of getting my first phone screening. It's unfair to ask a candidate to invest so much when the company has invested so little in the relationship.

I'm a senior developer, and I can pass their coding test. But I won't waste a bunch of time on it unless the company has shown some personal interest in me. I generally don't complete an application to any company with a big, poorly-written online application form that asks me to re-enter my resume so their poorly-written robot can botch the keyword lookup. I generally don't agree to complete a coding test unless it is brief or they are watching it live and talking to me.

Even if they're not putting your code into production, a company that wants you to spend a whole bunch of time typing before you find out if you are even a good fit is a company that is comfortable taking advantage of you. They are signalling what they want their relationship to be; you are the code monkey. They call the shots. And their interview process is designed to find people who are comfortable with that relationship.

Don't be a code monkey. Walk away.