

Ask HN: How do you hire contractors? - tomblomfield

My company's main product is a REST API and we've just released a couple of API libraries in PHP &#38; 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)<p>We're starting to talk to contractors about paying for open-source libraries - I just wondered if anyone had any tips on this process?<p>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?
======
rogerbinns
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

~~~
kls
_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.

------
Mizza
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

~~~
kls
_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.

~~~
Mizza
:)

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.]

~~~
kls
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.

------
SkyMarshal
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.

~~~
kls
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.

------
mrmekon
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.

------
medinism
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!

------
mikeocool
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.

------
cgh
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.

~~~
rogerbinns
> 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...](http://www.irs.gov/businesses/small/article/0,,id=99921,00.html)

> ... 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.

~~~
cgh
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.

------
rogerbinns
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.

------
izak30
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.

------
tomblomfield
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/>

------
j_s
Rob Walling recently shared some tips for using oDesk (about 17 minutes in):
[http://www.startupsfortherestofus.com/episodes/episode-64-hi...](http://www.startupsfortherestofus.com/episodes/episode-64-hiring-
and-managing-remote-developers)

Screencasts are highly recommended!

