How to effectively find, hire and work with contractors?

Question

I know there are some questions that are sort of similar to this one, but I don't think any of them really ask or answer my set of questions.

A bit of background:

Approximately 6 mos ago, I went from working for a large, bureaucratic, process-driven software company to a very small start-up. I wanted to work for a smaller, faster team and company -- note: be careful what you wish for! :) Although I have a much fancier title, I am mostly a dev manager (and part-time software architect and technical lead).

One of my biggest challenges in my career has always been hiring. On average, I probably get 1 good dev for about every 5 I hire. It's a huge waste of time and money. I find that I still struggle with it, but that now that I work primarily with contractors, the challenges are a bit different (the good news is that contractors are easier to fire than full-time US based employees).

First things first... Finding, interviewing and Hiring:

What sources do you use?

What questions do you ask?

Do you ask for references?

Do you ask for them to work problems/submit code samples? Note: I never want to risk someone submitting someone else IP, but I have had potential employers in the past ask me to create an app for them to solve a problem, etc.

I don't want this to be a cultural thing, but do you ask different questions based on country of origin? Again, I don't want it to turn into don't use contractors from this or that country because they are crap... there are good devs everywhere, but a lot of bad ones, too.

Do you find it better to work with individuals or contracting companies? I guess I've spent a lot more time working with larger companies.

Once hired, how to effectively work with them?

What technologies do you use? For example, I can't imagine trying to do this kind of work without a DVCS. I don't think I'll ever go back to SVN! :)

What collaboration tools/websites do you use?

Have you had better experiences with fixed priced or hourly contracts? I've managed both and I understand some of the pros and cons of each, but I swear I still haven't figured out which is the better "bet" (and yes, it's pretty much a bet in my opinion). I think for me, I need to start hiring hourly because I don't like the control that I seem to give up over the code when it's fixed priced?

Do you demand to have access to the code during development so you can review and see if you feel like you are getting quality work? How do you handle poor code?

What SLAs do you demand in the contract? For example, unit-test coverage? etc.

Finally, I know that most people could take any one of these things and write a bunch on the topic. Please feel free to answer just one part of the question. Or provide a link to a blog post where you think someone has answered a similar set of questions.

Answer 1

Well not sure if my answers are the perfect solution you might seek. I will try answering them with the limited knowledge I have.

What sources do you use?

Well I think LinkedIn might be a very effective tool for starters. Where you can post about ad requirement in a local programmer group in LinkedIn. For instance if you're seeking a Sr.Level C# Software Engineer contractors posting them in C#,LINQ Groups on LinkedIn might be a good place to start. Plus LinkedIn has the paid option which has more privileges than the free version which most people sign for. In addition to LinkedIn you can use Stackoverflow careers. Well I have seen really cool jobs listed out here when I was job hunting which I couldn't find even in LinkedIn.

What questions do you ask?

I am not sure if you have read this post by Jeff Atwood. Well I think there are plenty of questions like the ones listed by him which can filter out candidates quickly. It's very easy to find out if a person can backup their claims to what they listed on their resume from those sort of questions.

Do you ask for references?

A Strong yes. Once again you can use LinkedIn for that purpose to see if a person has any recommendations but a more traditional way would be to ask the person to list at-least couple of professional contacts who had been their supervisor/manager in the past. I think all companies do that right now. Some even have third party consulting sites who they hire to do this stuff for them.

Do you find it better to work with individuals or contracting companies?

I would recommend you to talk to candidates in person because I have had bad experience with contracting firms. There are some good firms out there and then there are tonnes of them who charge you a lot which they cut short it and end up paying very little to the contractor which may result in getting poor performance results. It's more of a grey zone than than other earlier questions I would leave it up to you to decide it for yourself.

Once hired, how to effectively work with them?

I think this can be sorted day one on the interview to see if the person whom you're interviewing and ask them about their expertise on source control and their choices and why they prefer their choices. I was a hardcore SVN fanatic until i realized migrating to DVCS has more privileges and branches are pretty cheap. :)

Do you demand to have access to the code during development so you can review and see if you feel like you are getting quality work? How do you handle poor code?

Have code reviews in place. That's one of the reasons DVCS can come in handy. Every time you push code into central repo make sure its peer reviewed quality code. Its a process we use in our company every code from an Entry level Engineer to an Architect has to be peer reviewed by minimal of 2 people before its pushed to the repo. Trust me you will love this if you start incorporating it.

So that's my take on your questions. I have more than 4 years of Enterprise implementation with Major Firm, Startups, Now Major firm again and I have answered it with limited knowledge i have i think most gurus out here would give better pointers than me.

Answer 2

There was a recent article on FORBES about the 3 questions you need... and only need: http://www.forbes.com/sites/georgebradt/2011/04/27/top-executive-recruiters-agree-there-are-only-three-key-job-interview-questions/

The only three true job interview questions are:

1. Can you do the job? - You can’t tell by looking at a piece of paper what some of the strengths and weaknesses really are…We ask for specific examples of not only what’s been successful but what they’ve done that hasn’t gone well or a task they’ve, quite frankly, failed at and how they learned from that experience and what they’d do different in a new scenario.

Not only is it important to look at the technical skill set they have…but also the strengths on what I call the EQ side of the equation in terms of getting along and dealing or interacting with people.

1. Will you love the job? - …younger employees do not wish to get paid merely for working hard—just the reverse: they will work hard because they enjoy their environment and the challenges associated with their work…. Executives who embrace this new management style are attracting and retaining better employees.

2. Can we tolerate working with you? - A lot of it is cultural fit and whether they are going to fit well into the organization… The perception is that when (senior leaders) come into the firm, a totally new environment, they know everything. And they could do little things such as send emails in a voicemail culture that tend to negatively snowball over time. Feedback or onboarding is critical. If you don’t get that feedback, you will get turnover later on.

Worth reading the article.

Answer 3

I've worked a number of times as a contractor so I can give you some insight from the other direction. Most of the time I've worked through an agency as a W2 employee. This allows them to handle billing, taxes and so forth as well as group benefits and such.

I've also done 1099 independent work a few times and the arrangements have been different every time, depending on the policies the company had in place. I also had to handle taxes and billing which was often a pain in more ways than one. All of these jobs have come from people I knew in some way or from word-of-mouth from someone I knew.

As for working as a contractor through an agency, it's not that much different than being an employee at the company. The company pays the agency an agreed upon hourly rate and the contractor gets a percentage of that. There's typically a manager, such as yourself, who assigns work and approves hours worked. In some cases, there are contract-to-hire arrangements where you can hire the contractor as a perm employee. There is usually a fee to be paid by the employer in this case but it can be worth it to retain a skilled person.

As for interviewing, it's not that much different than regular hiring interviews. They'll vary in scope based on the particular company and personalities involved. I've been brought in as a contractor based on single 10-15 minute interviews as well as grueling half-day marathon interviews. I wouldn't recommend bringing some into your team without an interview like you would give a regular applicant.

References can be from the agency, which has been common in my case since I've mostly worked through the same one since the mid-1990's. A reputable agency will recommend people they've vetted to some degree but there are a lot of "body shops" who'll send you people who aren't a good fit for you. So, you want to check out the agency's rep as well.

The day-to-day work is done on whatever the company has in place. Generally the company will provide a PC (usually a cast off from a perm employee) although I've had to provide my own a couple of times. The contractor is essentially another team member and should fit within your team structure.

In some cases, you may bring in some outside of this kind of team structure but I think you increase the risks when you do. For example, one place I contracted had a project held up for several weeks because an outside web designer put our project on hold while he finished a more lucrative one. This would be less likely to happen in a more controlled situation.