42

I've been looking for work for 3 months now, while I do have some weakness I do have a set of technologies that is rare. I tried to give many exercises test but this one is different.

The potential company wants me to spend the whole day with them and from the interview, it seems they are going to keep me a whole day to work on a project.

My question is: How do I know to set a boundary of what I can do for free and in a 7 hours long day?

  • 1
    cookieMonster, I removed the legal aspect of the question, since we don't answer most legal questions here. The rest of your question should be on-topic though, and feel free to edit if you need to clarify your question. – David K Jul 20 '18 at 12:41
  • 7
    What industry is this in? For a number of jobs, it would be unusual to keep you in for the entire working day as part of an interview. There are some where it's not unheard of though. – user34587 Jul 20 '18 at 14:11
  • 1
    @Kozaky web development – user15704 Jul 20 '18 at 14:13
  • Is this a day doing work, or just being at work? In the it business it is getting more common to have people there to give them done tasks as tests but also to have them experience each other in the future environment – PlasmaHH Jul 21 '18 at 16:17
79

You need to make sure they are not trying to get you to do work for free. Ask them what the format of the tests will be, and ask them what sort of compensation you will receive for giving them a day of your time. If you find that the format is unreasonable, tell them that and do not be afraid to walk away.

  • Comments are not for extended discussion; this conversation has been moved to chat. – user44108 Jul 23 '18 at 10:21
28

Ask yourself whether this is something that you really want to do or not (the job, not the interview tests).

Can you see yourself working there and being able to do the work? Can you relate to the people you've spoken to so far? Is the working culture a match to your expectations?

If you honestly believe that you can see yourself working there and working happily, then view this as being a "trial day" with them rather than an interview exercise. This would be a good way of seeing whether you're a good fit for the company, and the team - don't look at this as them getting free work out of you, treat this as you seeing if they're good enough to work with.

If you don't feel happy about working there or question the fact that you might be a good fit, then walk away.

28

This sounds normal, at least for the duration.

It's not uncommon to have an 8 hour day of interviews, and I quite like this idea. It gives everyone in the team the opportunity to meet and work with the new hire. I've even had people work with business in discussing technical requirements - just to see how potential colleagues communicate/get along.

This also gives you the chance to suss out what the work environment is like, what your colleagues are like, what the work is like and other things you will care about.

Often people get worried about being "taken advantage of". But... there's not much you can really "take advantage of" in one 8 hour day. The effort the company will have to go to monitor you, check in, trust your work - what about bugs, what about malicious code? It's just too crazy to try for anything but the simplest challenge. And if that's the case, you might as well get a cheap freelancer to do it over a day.

And yes, it is legal to interview someone for a whole day.

  • 11
    This is not an 8 hour day of interviews, this is an 8 hour work day. This is actually pretty common in programming where the organization uses 'Pair Programming'. In pair programming you spend your whole work day working side by side on the same computer, separate keyboards but not always, working on the task. It is very different, exhausting, and is not for everyone, hence part of the interview. – Bill Leeper Jul 20 '18 at 14:11
  • Bad idea being interviewed by so many means you get the most average candidate – Neuromancer Jul 20 '18 at 20:26
  • 3
    @Neuromancer It means you get someone who fits into the team. Whether that's good or bad depends on the team. :) – Llewellyn Jul 21 '18 at 13:49
  • @BillLeeper My favorite example of pair programming youtu.be/msX4oAXpvUE – Myles Jul 23 '18 at 15:05
14

Unfortunately, I am finding small companies are starting to pose "interview tests" as a cheap (free) way to get some long time bug tickets completed. I even had this one place wanting a proof-of-concept application of something they want to do but nobody had the time to test/build so they gave it to me with a one week deadline. It isn't very common but common enough in smaller shops.

Like what @user1666620 mentioned below, I would ask about what the format of the test is and if you get compensated for it. If the test isn't some sort of common test like building a simple page or program to show your skills, I would just walk out, especially if you are unpaid and they want to keep you for an extended time.

Also as @BillLeeper mentioned, don't ask like they are doing bad. Just ask generalized information acting as if you are preparing but really trying to gauge what is going on. Ultimately you may have to show up and gauge on what is going to happen before walking out.

  • 5
    If you want to find out what this job is really like, don't ask for compensation etc. It would be fair though to ask the recruiter or hiring manager for a little more information about the format so you are prepared though, but don't ask if you are fixing bugs, writing some feature for them etc., they may take offense to that. If it does turn out to be that way, now you know how they operate and can make an informed decision if that is a place you really want to work at. – Bill Leeper Jul 20 '18 at 14:18
  • Good suggestion @BillLeeper – Dan Jul 20 '18 at 16:47
6

In 30+ years as a degreed professional programmer, I have never been in an interview that lasted more than 2 or 3 hours, and I have never given an interview that lasted more than 2. In that time period, I have never asked an interviewee, or been asked as an interviewee, to write anything that could be mistaken for production code.

If you are desperate, sure, do what you have to do. But to me it either sounds like abuse or clueless interviewers. I would be inclined to ask my recruiter (you DO have a recruiter working on your behalf, right??) to find better opportunities.

4

This sounds very much like a pairing exercise. In organizations where they pair 100% of the time it is very important that the candidate be able to handle this. It is not for everyone.

They should have told you this in advance, but this sounds very much to be the way these types of interviews are setup.

Additionally you will get to see what it is really like to work at this place. Typically they have very rigid structure, so you have to be up for that. For example, you cannot just take a break, your partner has to take his/hers at the same time since you are both working on the same thing.

So as others pointed out about asking for compensation, deleting code, etc. Not going to happen, this just is not how these places operate. Many are very opinionated about how pairing is the ONLY way to code, so be prepared for that.

I would not ask any of those questions either. Again, they are very opinionated and going against the grain on their 'process' is going to get you passed over.

Every interview is a two way street. See if this is some place you can handle.

2

Coding as part of an interview should not involve fixing bugs/tickets in their current code. This doesn't demonstrate your coding skills as much as it uses your time to get around to things they are avoiding. Remember that if you do fix bugs as part of your interview - don't commit and leave the changes in the code when you leave. Always remove your work if you feel you are being used.

Actually on the contrary, the practice of asking an interviewee to spend time working on the project, reviewing the code or writing some code to show they are capable, has become more widely accepted in the industry. This is because of a few reasons, first and foremost the number of applicants who over-sell themselves and are not able to handle the technicality side of the job. Other reasons are to measure your coding skill, the way you write your code and your attention to detail.

While these are important and can help you get the job if you don't want to be taken advantage of, there are some things you can do.

  1. You could say you have another interview a few hours later in the day, or make up some other believable excuse as to why you cannot spend a whole day at the interview. After the primary interview this is acceptable to mention only if you are asked to stay and demonstrate your coding abilities.
  2. You may choose to do the coding and as this is part of your interview you may have some kind of code review with another developer. You have all rights to delete the code you have written after and not check it in. Once you've shown it to the interviewer, etc. this is a valid reason so to ensure you have not been freely coding all day. Until you work for the company it is technically not their legal property. This only works as long as they are using a code check in system where removing your changes won't affect anyone else.

I have always spent a few hours working after interviews both in my developer jobs and when I was taken on to be a chef for the day. While you may not wish to have an interview for the full day it often increases your chances of getting the job. You have to assess it on a case-by-case basis. Some may seem sketchy and sometimes you can tell.

However I have had one interview where they did use me for the day, but they made the mistake of discussing someone else they were going to hire and that they wanted to "let [me] finish the work before telling me so that they don't need someone else to take it over and finish it off" in a room nearby while I was coding still. At that point you can bet I was annoyed. But being a professional I finished the last few bits - cutting corners and what not before demoing the changes to them. When the demo was complete they said thanks and that I can leave. At this point I turned around and said "sure, let me just delete MY code and I'll be on my way, wouldn't want you guys thinking this interview was free labour".

Best of luck to you.

  • 6
    To avoid applicants who over-sell themselves, you should simply ask them to solve a problem you already solved and write a proof-of-concept implementation, not to fix your bugs. This way you can also have some discussions about the (possibly) different approach you and the applicant had used. – Gianluca Jul 20 '18 at 14:28
  • 1
    Agreed, i also believe that is how it should be done. Though we often find that is not case, purposefully or by coincidence, i too would never recommend to fix bugs during an interview unless you are going in as a contractual bug fixer. The problem being there is no right and wrong thing for someone to do. its all circumstantial. – Im-Harrison Jul 20 '18 at 14:44
  • @Gianluca, while you're correct from an interviewer's perspective, how does the interviewee know that you have already solved it? If they suspect that you're unethical enough to use a fake interview to get free work, they'll also believe you to be unethical enough to lie about it. – Peter Taylor Jul 21 '18 at 22:20
  • @PeterTaylor fair point. However I think that a too specific question or the request to use a specific language and/or library instead of pseudocode can raise some flags. After the test you can ask how they solve it to check, eventually, but I admit that anyway the interviewee need to trust the interviewers on this. As last resort, you can write something more that a proof of concept, explaing during the subsequent discussion that obviously is just a starting point to solve the problem. – Gianluca Jul 22 '18 at 19:53
2

What are they having you do? If it's totally unrelated (such as write me a Minesweeper clone) as a test of skill and style, that's acceptable as a practice. If it's code they intend to ship, then you should be paid.

Note that it isn't uncommon for big tech companies to bring you in for 4-5 one-hour interviews plus a lunch. So a full day interview isn't too much of a stretch.

-2

I somewhat doubt you are being taken advantage of. Having a software developer for a day would probably take more time out of their workers than you are worth.

If you want to be careful, develop the program on a USB drive, show it to them and take the drive with you explaining that you like to keep all of your personal coding projects for future reference. If you are there to be interviewed it won't be a problem, if not tell you can tell them you would be more than happy to sell them the work.