Here is how our interview process goes:

1. HR phone screen
2. Software Development Directors phone screen
3. Onsite interviews with the Software Development Directors
4. Onsite interviews with two XP teams
5. Lunch with our VP and XP Coach
6. Pairing in with one or two XP teams

Steps 1 - 4 all include a scripted set of interview questions. By the time we
get to step 6, we know if we are going to make an offer.

Step 6 is mostly about letting the candidate learn about us and what it is like
to work in a large open space with 5 XP teams. We get rarely get any value
from the pairing session.

Gary Brown



Quoting geoffrey_slinker <geoffrey_slinker@...>:

> --- In extremeprogramming@yahoogroups.com, Larry Brunelle
> <brunelle@i...> wrote:
> >
> > Steven Gordon wrote:
> > > I wonder how much of the code produced by pairing with candidates
> could
> > > actually be leveraged. Would there be an obligation to pay the
> candidate
> > > for an hour of work if the code developed in the pairing session was
> > > actually used?
> >
> > You bring up an interesting point. Several corollary
> > questions suggest themselves.
> > o Would some employers use this approach in bad faith
> > to gain expertise into the organization?
>
> Yes, anything is possible.
>
> 1) I wouldn't let a candidate into the real system. There are two many
> reasons not to let them in. (e.g. if you system stores customer
> information then that is confidential to employees only).
>
> 2) It seems easy enough to come up with "interview projects" that are
> similar to the work at hand. The interview project can start at any
> point, that is you could cover the tasks necessary at project
> conception or the design of an existing project, what ever you want.
>
> 3) If a candidate were to write code that was useful to the company
> (and since the company is hiring) then it would be expected that the
> person be hired. If not, delete the code and be done with it. If the
> candidate came up with a design that you want to use, then hire the
> person because the candidate came up with something your team couldn't
> and since you were hiring it is the right thing to do. Otherwise, I say
> you have to forget it and let it go. With those two options I feel most
> will hire and hiring is the best thing IMO.
>
> 4) Do the "team" fit test before you do the technical test. It is more
> important to match team fit for most projects. (some projects need a
> person that is expert in some special branch of technology and it
> doesn't matter if they work well in a larger team.) If you do the team
> fit tests first then when you get to the technical test and someone
> creates something you would like to own it is easy, hire them.
>
> Geoff
>
>
>
>
>
>
> To Post a message, send it to: extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com
> Yahoo! Groups Links
>
>
>
>
>
>