Thursday, 28 November 2013

No, I will not hack on your codebase for free under the pretext of it being a "technical interview"

Yes, I'm aware you need to asses my technical skills, however, I'm not going to work for free. If I want to do that, I'll hack on some open source something or other that takes my fancy. Witness this company, paying well for a [Hipster Programming Language] dev. I casually dropped them a line and they rather liked what the saw, so they invited me in for an in person interview.

I arrive at the newly appointed offices, complete with ping pong table. I guess I should have known right then. I get introduced to the team and after a little 'get to know you' coffee, we sit down at a large bench filled with 27" iMacs. The conversation ensues:

Lead Dev: "So I thought we could spend the day pairing on a little code"
Me: "Okay, sounds cool - do you have something in mind or should we grab a little open source something that needs a little TLC?"
LD: "Well, I thought we could work on our application, we've got some features I want to implement and push live by the end of the day"
Me: "Um, you mean *your* application. Like, the one I would work on if I was an employee?"
LD: "Yeah, that's the one"
Me: "Okaaaaay. My day rate is 450 yeah?"
LD (looking confused): "Excuse me?"
Me: "My day rate is 450. As I understand it, you want me to hack on a live product that you're getting paid for."
LD: "Yeah, but I need to assess your technical chops"
Me: "Sure, so lets grab something open source. You get to assess my technical chops, we get to give a little love back."
LD: "But our technical test is on our codebase. I know it well so I'll be able to properly assess you"
Me: "I'm sure you do, but you are asking me to work for free"
LD: "No, it's a technical test"
LD (frustrated): "But I need these features out in the field today. Anyway, I don't see what the problem is, it's only a day's worth of work."
Me: "Do you work here for free?"
LD: "No"
Me: "Right. Exactly"
LD: "So, should we get started?"

Let me say this very slowly, so you will be sure to hear it:


Then I'll be more than happy to hack on your app all day everyday.


  1. *thumbs up*

    Had a very similar conversation myself recently.

    NonTechie founder: "Need to assess your coding skills, going to ask you to integrate this API into our app"
    Me: "Okay. I specifically said that a technical interview should not be on your live codebase but if it's just an API what are the credentials"
    NTfounder: "Over to my Lead Dev..."
    LD: "We don't actually have those credentials yet. Oh, and our code base is a bit hacked together at the moment so if you could design an Infx that was easy to plug new APIs into at the same time that would be great."
    Me: "Goodbye...."

  2. It's crazy how many shops want you to work for free, and see absolutely nothing wrong with it as long as it's in the guise of an interview. Thankfully the trend to that has been moving the other way, if reluctently. Had two code tests where the days work was paid for. Nothing that would make you rich, but no chump change either. More employers need to follow this example.

  3. While I like the idea of improving some piece of open source software as part of an interview process, I also kind of like the idea of working on the hiring company's codebase as well. The code will probably tell you more about the place than any conversation you have that day. To me, that's just valuable enough to not need to be paid for the contribution. But hey, it I wouldn't oppose the idea of getting paid some sort of non-insulting flat rate either.

  4. Nothing wrong with working on the company's codebase as part of the interview. That said, there is a HUGE difference between, let's pair on this problem for an hour so I can see what it's like to work with you and get a better understanding of your technical skills, and, I need to get 3 features out today, so help me ship them over the next 8 hours.

  5. I once had an interview "technical test" which was "Write an Excel/VBA program that connects to Interactive Brokers and executes VWAP trades." If I wrote the program for him, then he wouldn't need to hire me at all! I offered to do it as a consulting project, and the interviewer got angry.

    That's one way I know that he was trying to cheat me, because he got angry and hostile when I suggested billing him for it.

    I had another interview, where someone wanted to hire a programmer for a fixed-bid project, but he had no written specification. I pointed out that I'd be an idiot to accept a fixed-bid project with no written specification. He expected me to spend some time for free helping him write/polish the specification. I offered to bill him a few days for the time spent helping him write it, and he got offended. If I wrote a proper specification for him for free, that would be most of the work, and then he could hire someone much cheaper to implement it.

  6. If I were to get this proposal in an interview, I'd be inclined to do it *if and only if* we could agree on that the purpose was to assess me and my working processs, and not to get anything completed by the end of the day. I would also demand that it is indeed pair programming, and not "here's a chair, I'll see you in 8 hours".

    In that context, I'd be focused on doing a professional job, pointing out flaws in their existing system (carefully.. Actually I think I'd word it as "areas of potentional improvement") while emphasizing my strengths and diversity. Getting things done would *not* be the focus. Leaving them with something half done would actually give them a good incentive to hire you. After all... how much to you get done in a single day anyway? Finally, I would also make it very clear that I'm not coming for a "second interview" in order to finish whatever I started.

  7. Hahaha! This is funny!

    This is really true ?! haha awesome!

  8. That radically differs from what I usually do but I love the idea :)

  9. I'm sorry, but I must respectfully disagree on a number of points. I think you make a number of flawed assumptions and miss some great opportunities when you pass up an interview that allows you to work in their code base.

    1) Maybe this company was different, but as for me if I bring in an interviewee and say "Let's pair on some code for a day, and try to release a feature" I know up front this will be an up hill battle. Can you really say that you, an interviewee who has never seen the code base, will suddenly make amazing production grade code? I am absolutely sure that if I were to grab one of my other engineers, seasoned in my code base, I would get this task done in half the time. The point is, I am assessing you to see how you work with me, what your attitude is while we pair, what your contribution to the process is, and to a lesser extent how your code looks. Can I get this out of an open source project enhancement, maybe. But I can certainly get this out of my code base and it will cost me more than it will cost you in income.

    2) You've missed the opportunity to look at my code base for a day. I can't name the number of times where I have walked into a company after a lovely interview experience and said to myself "I wish I had seen their code base, this is horrible". Your other blog post states you want to "test the company" before you take a job. Test them.

    3) I won't discuss how low your day rate is, and how it establishes that you are an inexpensive engineer (that may have been what you were trying to get across) but I will discuss investment in future earnings. In my last few jobs I have received at least a 5 figure signing bonus, and generally a healthy pay raise (this is generally why I move companies). When I sit down to pair for an interview "for free" I don't think of it that way. I think of this as an investment into my future earnings. I am going to get a signing bonus from this "trendy startup, complete with ping pong table". I am going to get a healthy pay raise. It will equal far more than my day rate. You might say "But what if you have to do 5 or 10 of these interviews with companies before you get a job?" I often do! Getting a job is a numbers game. But I am still highly compensated for my time, just not right that moment. It is ok to defer payment. Investments can be quite rewarding. (Not to mention, money isn't everything. There are other reasons you may want to leave to another company. Account for that in your equation). If I interview with 10 companies and they all have me working on their code base, I hope they enjoy the one day of free work. I won't get paid by all of them. But I will not lose a dime of my own income in the end. I will make it back when one of those 10 companies hires me.

    I understand from this blog that you would rather not be tested and that you would rather not work on a companies code base. But a company that wants to hire you, wants to hand you a pile of cash and a hefty salary and benefits, needs to assess you somehow. You also need to assess them. I think a day of pairing on their code base can easily tell you if you are a fit for them and they are a fit for you. In the case of this interview, maybe they very quickly figured out you are not for them.

    1. I couldn't agree more with these points. Equating time with money in a 1-to-1 relationship locks you into thinking of money as a wage worker.

      Also, you were brought in under the understanding that it's an interview. It's not like someone it lying to you. I agree that I would much rather see the actual codebase I'm going to work on rather than an open source project or a contrived programming example. The idea that one should be paid for interview coding time is silly, as pointed out by the efficiency loss of using day-one engineers. The implication seems to be (a) that you're as good on day one (the interview) as any of the engineers that have been working on the code base for months/years, which is a joke, an (b) that the company is somehow using interviewees to get most of its work done, which even if true, is a horrible way to get anything done in a reasonable amount of time. I've just never heard of a company that does this, so the fear seems completely unfounded and not thought through all the way.

    2. But if that's so, why does the interview last... 8 hours?!

  10. A good deal benefits both parties. I would be more concerned about the ethical construct of the organization rather than the days pay; however, even a day is excessive. If a hiring manager can't figure it out in 1-2 hours, maybe their "chops" should be looked examined.

    1. That's what I was thinking too. I'll do anything they want for 1 hour or so (of the pure coding part), but unless it's a company like Google or Amazon, I'm not spending all day interviewing. And under no circumstances would I work on the SAME problem all day. There's no circumstance where that would ever make sense.

  11. I don't get what the big deal is.

    Especially after months of blog posts saying how bad whiteboard-style interviews are.

    Nobody wants to do algorithm questions, and now pair-programming on their app isn't good enough?

    1. Pair programming for EIGHT HOURS is. That's not an interview, and it doesn't make sense. It's even a crappy way of getting people to work for free, so if they're that desperate, you don't want to work there anyway.

  12. This happens all the time in the animation industry. "Hey, could you come in and do some drawings for us? It's, uh, for a test."

  13. This comment has been removed by the author.

    1. Considering the demand for devs these days and the fact that there are a lot of good companies out there, I'd just walk if I thought the company had no idea how to hire a dev or had bad culture or management. I've been in that situation and don't ever want to be there again. I'm very picky about what companies I'll consider an offer from. I only like to work with smart people and if the company doesn't know how to find smart people then I probably wouldn't want to work there.

      Most companies worth working for should be able to afford to pay you for a few hours of time spent working on their code base. If they won't, then I think it's an indication of the attitude of management or unfamiliarity with current industry hiring practices. This also means I probably wouldn't want to work there.

  14. I would just keep a contract on hand that they have to sign before beginning agreeing that you own all rights to anything you work on unless they hire you or pay you for your days work. If you don't benefit then neither do they.

  15. I used to work at a company that would take every candidate through three 2-hour pairing sessions on our code base.

    I can confidently say that we never benefited from the code that the candidate wrote. Our code base was large and complex, and we spent more time explaining, asking, and answering questions than actually producing code. In many cases the code that was produced in these sessions was not up to our quality standards and we threw it out or reworked it. We invested this kind of dev time because we wanted to be sure that 1) we liked working with the person, 2) we could have high bandwidth conversations with the person, 3) they asked good questions/would call for help on things they didn't understand, and 4) they could be happy in our code base. Frankly only 1 & 2 could be adequately addressed hacking on open source.

    As a candidate at a real business, it is to your benefit to get a look under the hood while interviewing. You can see what kind of minefield you're walking in to. Are these guys making obvious coding errors? Is there a tremendous pile of technical debt? Are things tested in a way that you agree with? If it's not worth it to you to invest a few hours up front to vet the code base in a place you could be spending years, then you're going about it all wrong.

    1. I believe the issue here was that the supposed interview lasted a whole day, not just an hour or two (which would have been reasonable, for exactly the reasons you mention).