Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: How do you hire contractors?
59 points by tomblomfield on Feb 27, 2012 | hide | past | favorite | 19 comments
My company's main product is a REST API and we've just released a couple of API libraries in PHP & Ruby that we wrote in-house. Our customers are starting to write libraries in other languages, but we'd like to turbo-charge this process (and help improve quality)

We're starting to talk to contractors about paying for open-source libraries - I just wondered if anyone had any tips on this process?

Specifically, how much success have you had with day-rates vs fixed-price contracts, how do you define "finished", and how do you cope with project over-run?



I'm a contractor. Make sure that the contract specifies upper limits, and that it covers some process. For example it should specify the maximum monthly or weekly payment as appropriate payout. It should have a termination clause ("either party may terminate the contract on immediate written notice for any reason or for no reason"). It is also a good idea to cover invoices and payments ("invoices must be submitted with 14 days of month end and payments must be made within 14 days of invoice receipt"). That will remove a lot of stress from the relationship so both can concentrate on the work at hand.

I've always done hourly because the clients were not able to specify upfront exactly what they wanted, and priorities would keep changing. Additionally they would find that I'm good at other things and can help in ways they didn't anticipate. Everyone benefited.

If you can accurately specify exactly what needs to be done, and know you won't change things then ask for fixed price bids. Contractors will know how to respond. There is no perfect way of protecting yourself from below expectations work, but contract limits mean you know the worst that can happen. (eg if you say you won't pay for more than 40 hours a week then they can't suddenly surprise with 120 hours of work after the first week.) Being able to immediately terminate also means you can cut your losses early if you need to.

I always end up spending a lot of time on the intellectual property parts of the contracts since they are usually egregious land grabs written by lawyers. It is really tedious getting that fixed up. Know up front what is happening with the copyright (you can retain it exclusively, or give the contractor their own copyright on a copy) and licensing. I'd certainly give discounts for open source work, especially something that I can freely reuse elsewhere - it helps as a reference and it helps future work.

TLDR: you can't perfectly protect yourself, but be optimistic and plan on good things happening


I've always done hourly because the clients were not able to specify upfront exactly what they wanted, and priorities would keep changing. Additionally they would find that I'm good at other things and can help in ways they didn't anticipate. Everyone benefited.

I would second hourly until both of you know the relationship. A fixed price contract has so many ways that it can go bad and a good contractor will be fighting you on any scope that you try to introduce. Unless you know for sure that you have ALL scope buttoned up I would go with hourly or daily rates. If not the relationship can become adversarial very quickly.


I wrote a pretty well-received guide for exactly what you're doing here: http://gun.io/blog/how-to-hire-a-programmer/

If you're already a technical person, you're probably 75% of the way there. The rest of the challenge is defining a scope early on in the project.

I realize it's not very tactful to plug my own product here, but I run http://gun.io , which I think is exactly the right place to find the type of person you're looking for. We specialize in short-term gigs from the open source community, and there are thousands of talented open source programmers there waiting for new gigs to be posted.

Shoot me an email if you'd like to know more! rich@gun.io


I realize it's not very tactful to plug my own product here

I have always found HN to be the place to plug your product if it is relevant. My experience has been given the entrepreneurial nature of the site, that if a product is relevant and it's not a total marketing pitch then have at it. I just found out about StackMob the other day from a member plugging it, and I am happy he did, I found a backend provider that supports Clojure through his plug. I would say that I discover half of the cool stuff going on through plugs by people working on them on this site, the other half comes from the articles.


:)

Well, now I feel less guilty!

[Do people really run Clojure in production? That's pretty sweet, I thought it was just an experimental/AI language.]


Don't want to side track too much, but yes, given that it is on the JVM and can bind to Java libs it's not too risky for production, that being said Clojure is slower than Java on the JVM so I would not use it where performance is critical (it's not that slow though). But for the majority of use cases it works just find. By no means is it experimental Clojure has the reputation of being the practical Lisp given it's ability to use the wealth of Java libs.


Sivers has some good advice on this, though it may not answer your last questions:

http://sivers.org/how2hire

TLDR:

1. Reduce your big idea to “Version 1.0”.

2. Write a simple overview of what it does.

3. Write a detailed walk-through of every click.

4. Break it up into milestones.

5. Make your first milestone a stand-alone project.

6. Post it at elance, guru, odesk, vworker.

7. Hire one from each.

8. Continue with the one you like best.


This advice is moderately good advice for someone that has an idea, only a small amount to invest and no technical knowledge. For an organization that already has technical talent it is a waste of cycles to deal with 3-4 independent teams working on the same issue. This advice relies heavily on lucking into the diamonds in the rough by increasing your surface area on those sites. Generally that talent does not stay there very long.


I followed his advice, nearly to the letter, and have had some small success. The Version 1.0 worked well, but it's too early to see how well it will work as I go forward.


Below a few nuggets from what we have observed at GroupTalent: 1- Hire a freelancer based on work performed not on CV. Not only we do this by allowing our teams or single devs creating portfolios (which is privileged information displayed only to interested employers) but also by asking them to show us the code or design they are most proud of. 2- Have them come up with an overall plan for the project but commit to only the first sprint. Creating the overall plan for any project will allow you to see how the dev thinks about solving the problem while paying only for the first sprint will limit your risk and allows you to see a bit of his work at the time. 3- Limit the sprints to 1 week at most - and make sure at least a feature is developed in the sprint. Short sprints will help you a- prevent cost overruns, b- cap your risk of working with a bad apple and c- allow you to see features developed early on. 4- Try to manage the whole thing through github. Great programmers hate to add additional layers of estimation, communication, tracking, etc. yet you as a project owner need insight into the work. Make sure you agree to some schedule of commits with the dev so that you get to see progress along the way.

Feel free to ping us at grouptalent.com if any additional questions. otherwise - happy building!


Speaking as a contractor, you hire/fire/manage just as you would any other employee. You are the ones who define "finished", based on a set of defined requirements, not the contractor/employee. And just as you don't do in-house development by locking an employee in a room for two months and then checking out what they've done, you don't send away contractors to do stuff and report back when they are finished. You do the usual code reviews and status updates, etc.

In short, manage contractors like employees, with the added bonus that they are much easier to fire and they are generally cheaper in the long run.


> In short, manage contractors like employees ..

Actually you have to be very careful about that in the US. In particular if you control how the work is done then they are legally an employee. All sorts of nasty things can happen.

http://www.irs.gov/businesses/small/article/0,,id=99921,00.h...

> ... they are much easier to fire ...

This always amused me. My contracts always say I can be terminated at a moment's notice and without reason. But I'm in an at-will state and the employment agreements and state law have exactly the same provision. Despite that most companies treat employee termination far nicer than law allows.

http://en.wikipedia.org/wiki/At-will_employment

> ... they are generally cheaper in the long run

Also more productive. As a contractor I don't have to get involved in corporate politics, can avoid many meetings and can focus on the work at hand. It is also simpler to deal with me - pay the amount on the invoice. I deal with my own taxes, healthcare, benefits etc. I also have a reputation to maintain so I can't be an underperformer.


Hmm, good point about US law. I am not in the US so I wasn't aware of that.

Agreed about the other points. It's funny how complicated people make this, like hiring contractors is a dicey thing to do and are somehow less "loyal" (whatever that means) than employees.


I work for a B2B software consulting company, here's a tip: For one-off projects, you want an hourly rate with a not-to-exceed. Always.

Neither side gets a good deal with fixed-price contracts, no matter how nice they sound when you're thinking about throwing money at strangers. The contractor has to always throw in a significant amount of 'padding' on a fixed-price contract to account for the unknown problem that occur in every project.

The number one goal of a contractor: never, ever get stuck in a situation where you're working unbillable hours. So under-bidding a fixed-price is a big no. Which means over-bidding is required.

With fixed-price, we will also demand that the whole contract be renegotiated if anything changes. Anything. Oh, oops, you want one extra quick little feature that should only take a few hours? Fine, but the contract is being rewritten to include it and we're all going through the trouble of formalizing it.

Paying hourly is frightening when you don't know who you're hiring, but that's where a NTE comes in. We still do the schedule estimation that we would do with a fixed-price contract. We give you that as the estimate, and something like 1.5x that as the not-to-exceed price. We bill hourly, and you stop paying when the project is done. Often that is before the original estimate, and you save money. If we hit a snag, or if you decide to add a few small things, it can be handled smoothly without changing the contract. You can elect for a higher NTE, if you trust the contractor, and get more room for 'agile' development.

You define 'finished' extremely specifically, up-front, before letting them start. If you don't know what 'finished' is for your own project, there's something wrong, and you need to think about it harder. All software and documentation, delivery format, media, copyright assignment, etc should be specified.

Here's something that absolutely, absolutely critical: define at least a few milestones, at least one a week for the first month, and make sure you get them and verify they work. If their output looks good and they've been professional for the first month, you can let the frequency fall off if you wish. I have worked with tons of companies who were screwed over by contractors who took payment for 6+ months without producing anything.


For your exact specified needs what you could do instead is just offer a bounty. That way you don't need to deal with contractors, worry about budgeting, interviews or anything similar. Do make sure it is clear how acceptance/the winner is judged. This possible due to the open source nature - require submissions to be on github. If you want things to be closed too then you'll have to do it the hard way.

You can point to the other language versions as a template for the solution.


When you're talking about some work as discrete as "write (or clone) an API Client library in [the contractor's language of choice]" Most of the advice here is overblown. It's a small amount of work, you probably already have acceptance tests for your other libraries (which can be copied verbatim), and documentation is minimal.

Just get a recommendation from somebody else who knows the language you're looking for well and pay whatever they ask, presuming that what they deliver passes whatever tests you already have.

Make sure that the contract says that you own the copyright when you pay/they deliver. the fact that it will be OSS doesn't really matter much either way.

If you're worried, agree on a deadline before you sign a contract and put in a positive or negative incentive around that.

I've been a consultant for several years. The ones you want aren't spending their time on oDesk and elance, and they're not cheap. I've tried to be that guy, you can't compete. I've tried to hire that person, and you can't get repeatable results. You guys are hackers, you have a strong network. somebody somewhere knows someone with C# experience who has read a decent blog post on REST.


The answer is it really depends. In my experience both in hiring and working as a contractor, I tend to do a day-based rate when the contractor is working essentially as an extension of the in-house team, that is they don't have a project with explicit requirements and timeline, they're just going to be delegated tasks as they come up. A library for a REST API seems like a task that can be fairly well defined upfront. Assuming that you can define what you want in a fairly tight spec, I think most contractors would be willing to give you a fixed price for a project like that.

Defining 'finished' goes hand in hand with the spec. Write up a document with some basic design reqs, the classes you want, the methods they should have, include examples of what you API outputs or at least have links to your docs, and call out any edge cases. Additionally, I find it hugely beneficial to ensure that contractors right unit tests, then as you're QAing the code and find bugs, you can add failing tests for them to fix.

In the case of 'finishing' maintaining a good relationship with your contractors throughout the project goes a long way. Most people are happy to deal with a handful small issues that you might have forgotten to add to the spec, if they're enjoying working with you. If you've been adding new features and constantly changing things throughout, they're going to be a more interested in getting rid of you as a client than helping you out at the end.

Not sure exactly what you mean by project overrun. But one key is work with the contractor to put together a timeline of milestones. And be sure to include time you to QA and then for them to resolve any issues. Once you have that, immediately understand that the deadlines will most likely be blown. Also, obviously make sure you have a contract that references the spec and the timeline, so in the event of a failure to deliver on the contractors part, your not stuck still footing the bill.


OP here - If it helps, you can find an example of the kind of library that we're looking for at https://github.com/gocardless/gocardless-ruby/


Rob Walling recently shared some tips for using oDesk (about 17 minutes in): http://www.startupsfortherestofus.com/episodes/episode-64-hi...

Screencasts are highly recommended!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: