Best practices in interviewing contractors for rails projects

[Yasith Fernando]

Hi All,

Recently i've been tasked with conducting short interviews with potential contractors who would help our team with some rails projects. I am limited to a ~30min interview via IM (most of the time the guys are located in a different country) and i have to tell my manager wether the contractor seems OK for our project or not.

I know there are tons of great articles on how to conduct interviews etc. However i only have 30mins of IM to determine whether a contractor is a good fit for the project or not.

Right now i usually ask them about:

• some ruby fundamentals
• some rails fundamentals
• what projects have you worked on
• what are some gems you are familier with and what do you think about them (pros and cons..etc)

But i feel that i am not getting a true sense of their experience and abilities through these questions. And most of them don't have any open source contributions..etc for me to take a look at. 

So i wonder what others do when they are looking to get some external help? how do you see if a specific contractor is a good match for your general rails project?

Thanks!

[Andy Marks]

Is the "30 mins of IM" really an immoveable constraint?  It's a very short period of time and over a very poor medium to ascertain coding skills.  If the developers you're looking to hire will be working remotely, then it might be of some value as you can gauge their communication skills over IM, but I doubt you'll be able to explore any conversations deeply in 30 mins.

+1 to pairing (even remote pairing using screen sharing), but - again - you won't get far in 30 mins.  It might help to use a standardised pairing question/problem so you can compare experiences across the different people you interview.

How long is the term of their contract for?  If it's for any decent period, you can usually put together a case for investing more time into recruitment, given the benefits associated with getting great devs and the downsides to getting bozos.

Cheers,
Andy

Andy Marks

Technical Principal

ThoughtWorks Singapore

email: ama...@thoughtworks.com

mobile: +65 9788 0259

web: www.thoughtworks.com

--
You received this message because you are subscribed to the Google Groups "Singapore Ruby Brigade" group.
To post to this group, send email to singap...@googlegroups.com.
To unsubscribe from this group, send email to singapore-rb...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/singapore-rb?hl=en.

[Carl Coryell-Martin]

Pair with them on a Simple Matter of Programming in the language of
choice in a skype screensharing session.

You should type, they'll talk and think and tell you how to solve the problem.

use the same problem on each of the candidates so you get a decent
cross comparison.

30 mins is short for this, I usually have 45 mins of pairing and 15
mins of conversation about what we just did.

-ccm

[Bas Vodde]

Hiya,

30 minutes is really short. I'd look for open source contributions and past work before talking to them.

Then perhaps use the code they have written and contributed to talk about...

Hope that helps?

Bas

[Paul Gallagher]

..but they also say that most interviewers make the hiring decision within the first 5 minutes of the interview. So the difference between a 30 minute and a 1 hour interview is probably just that you wasted half an hour (x2, including the interviewee).

However that does not mean that the hiring decision made within the first 5 minutes is a good decision.

In general, I think you should be highly skeptical about your own ability to "spot talent". The truth will only be know after the fact.

Of course, that means hiring contractors is much easier than permanents simply because you do not need to make big up-front commitments, and parting ways is much less traumatic.

Personally, I look to evidence of capability (portfolio, open source contributions, blogging and general net presence) plus a short interview/discussion/pairing. Make a decision based on this, but don't believe it was perfect. Engage for a short scope, maybe just a week. And then extend based on how things work out.

... I'm trying to remember the name of the US-based company that is quite famous doing this for all permanent hires too. They have an exponentially increasing engagement process  (i.e. they first offer a 1m contract, then a 3m, then a 6m, then a 12m etc .. and everyone in the co. is on the same terms)

[Keith Bennett]

Wow, only 30 minutes...how many minutes do they give you for
regretting the wrong decision? :)

That seems like a false economy to me. Not knowing anything about
your company, it raises questions in my mind as to the general level
of management wisdom. My gut feeling (though it may not be correct)
is the sense that the nontechnical managers are pretending to know an
area they know not, and not respecting and appreciating the
craftsmanship nature of software development.

- Keith

[Yasith Fernando]

Guys,

Thanks for all the responses. I think the 30 mins is a major limiting factor here as most of you pointed out. May be i'll try to stretch this to 45mins.

And to give a little more background to the process. These developers are working for a another consultancy (most of the time). So unlike, say when you are hiring a freelancer most of these developers do not have a portfolio or any open source contributions. The closest thing to this is a resume outlining what projects they have worked on. So there is no code to look at.

However If we feel a contractor is not a good fit for us we can ask for a replacement at any time. So its a bit flexible. And the replacement cost is not too high. However if we do choose to ask for a replacement we have to loose some time since the new guys needs to get used to the code base...etc. So there is nevertheless a replacement cost.

My manager has a technical background and i think that he is just willing to take a bigger risk with these guys because the replacement cost is not too high.

As Andy and Carl suggested i will try to do a small paring exercise (with say 40mins) and see how it goes. The next contractor will be my Guinea pig :)

Thanks again for the insightful responses!

[Wong Koi Hin]

Hi Yasith,

On 14 March 2012 16:36, Yasith Fernando <yas...@gmail.com> wrote:

> However If we feel a contractor is not a good fit for us we can ask for a
> replacement at any time. So its a bit flexible. And the replacement cost is
> not too high. However if we do choose to ask for a replacement we have to
> loose some time since the new guys needs to get used to the code base...etc.
> So there is nevertheless a replacement cost.

Surely this is not an insubstantial cost unless your project is
trivial which I am guessing is not the case. It seems more logical to
spend more time hiring the right person, perhaps even from outside the
consultancy you mentioned, paying a higher fee which translates to
time saved and cost savings in the long run.

My 2 cents,

cheers,

Koi Hin

[choonkeat]

Hi Yasith,

Harping on 30mins seem like a lost cause to me.

Pairing, 30mins, 90mins, face to face, or skype, etc are all tactics & not fruitful if the strategy is wrong. The flaw i see in your first post is that you're asking for *opinions* on technology. Isn't it possible you have folks acing your interview but can only wax lyrical about rspec shoulda paperclip dragonfly gems all day?

Unless that is truly their job (to opine on tech), you should try to see/hear them in action, working on problems. Whatever tactic you end up choosing, as Carl mentioned, "use the same problem on each of the candidates so you get a decent cross comparison."

Cheers & good luck
-- choonkeat

--

[Matthew Rudy Jacobs]

On 14 March 2012 16:36, Yasith Fernando <yas...@gmail.com> wrote:

Guys,

Thanks for all the responses. I think the 30 mins is a major limiting factor here as most of you pointed out. May be i'll try to stretch this to 45mins.

I'd suggest, if you have 5 candidates,

you allocate 30x5 = 150 minutes in total.

Set a bar at 10 minutes in,

if they haven't shown their strengths by then,

politely end the call.

Say you like 2 of the 5,

you'll have 120 minutes to spend on those 2.

I suggest you arrange a 45 minute pairing session for each of them.

See how it goes.

Decide on the successful candidate.

60 minutes is probably enough to make an informed decision.

[Fer Martin]

In my experience, the problem is tackled from the wrong angle here. Most of the solutions presented fall under one big assumption: the guy you are interviewing is actually going to code for you. And more often than not, all this consultancy agencies have the rockstar programmer as sales.

The reality later on is that you will be working with a team, and they may not represent the quality of what you asess in the interviews in any way. This truth multiplies itself on project length and complexity.

My advice is to choose the one who give you a better gut feeling and got better customer reviews from people/companies you trust, and engage them in a short-term project (max 2 weeks). Try to interact with the team members as much as you can, especially with the less capable members in the team.

Hope it helps ;)

Regards,
Fer Martin

+65 9856 8891
http://www.linkedin.com/in/fermartin

http://vizualize.me/nvmwDHEkea

--

[Matthew Rudy Jacobs]

I should say that my last contracting gig was won in the following way.

• they sent an email over a mailing list
• I replied, said I'd contact them in a few days
• I arrived back from Chicago, gave them a call, arranged to meet in a cafe
• a few hours later I chucked my bags in a corner and got a coffee
• the project manager and CEO came to meet me
• we chatted for half an hour
• I followed them back to the office
• I chatted with the dev team informally
• I offered to come in the next day, and do a "trial day"
• That day came and went
• We agreed to carry on for a month

[Pete Kim]

+1 for looking at open source contributions in github

[Andras Kristof]

For me , what matters is how they think, how they interact with others and how they solve problems. The candidate's mindset and drive is more important than the technological wizardry they might possess. Not knowing our technology is not a deal-breaker. I've hired people who didn't know ruby and rails before, and it turned out to be a very good decision.

For Viki, the process is a 30-60 minutes talk and a 2-3 hours programming task, working together with one or more of the existing team members. (Pair programming)

Anyone can veto the hire. 

We work as a team, interact all the time, solving problems and getting things done. If I see any signs that anyone is uncomfortable, I probably pass on the candidate, even if he is very strong technically.

-- Andras

On Thu, Mar 15, 2012 at 4:26 PM, Pete Kim <rain...@gmail.com> wrote:

+1 for looking at open source contributions in github

[Andy Marks]

Given all the interest in hiring recently... http://www.tawheedkader.com/2012/03/how-to-hire-a-hacker-for-your-startup/

p.s.  Yes, this came from HN, so you've probably all seen it already.

Cheers,
Andy

Andy Marks

Technical Principal

ThoughtWorks Singapore

email: ama...@thoughtworks.com

mobile: +65 9788 0259

web: www.thoughtworks.com

[Jason Ong]

On Fri, Mar 16, 2012 at 9:00 AM, Andras Kristof <akri...@gmail.com> wrote:

Anyone can veto the hire. 

Me thinks that's great for keeping the company culture intact. :)

--
Cheers,
JasonOng

---
web: http://bit.ly/jasonong

[Patrick Haller]

On 2012-03-16 09:47, Jason Ong wrote:
> On Fri, Mar 16, 2012 at 9:00 AM, Andras Kristof <[1]akri...@gmail.com>

> > Anyone can veto the hire.
> Me thinks that's great for keeping the company culture intact. :)

It probably only keeps the firm small, and since the group isn't
changing, the culture usually remains intact.

Culture preservation probably requires identifying/documenting the
behaviors/methods/preferences/expectations of the group.

That write-up can become like the 10 Commandments with all the
associated group behavior: praise for virtue, condemnation for sins.
Penance. Purgatory. Absolution. Or if you're lucky, it becomes like
Bridgewater Associates or old Nordstrom.

Just documenting culture can weaponize it... so be careful. ;)