[jacques_chester]

Here's how I was assessed for my job at Pivotal:

1. I did a simple tech screen (the RPI). 1 hour. My interviewer had a laptop and asked me questions about what to do next in the scenario.

2. Hey, come pair with this engineer on this real code on a real project on a real task.

3. How about lunch?

4. Hey, let's have you pair with this other engineer on real code on a real project on a real task.

5. Get offered a job on my way out the door.

I know from feedback that we don't always do this right, that we sometimes drop the ball, that many people find the RPI or the pairing to be frustrating, intimidating, or uncomfortable.

Most importantly, many people find that they just don't want to work the way we prefer. Which is good! It saves them the unhappiness of committing to a situation that won't enjoy.

But the core insight is: the best way to see if someone can work alongside us on a real problem is to ask them to come in to work alongside us on a real problem.

It's the best proxy we have short of hiring you. When it's available as an option to do this, I don't understand why anyone would choose a less accurate proxy.

[retreatguru]

I really like this approach and I reading about it here makes me inspired to try it on our next hire. We do pair programming, so it would work well for us.

What I've been doing which is similar is hiring the dev on contract for a short term to see if it works out. But I think this approach is much more efficient. Do you get and check references?

[passiveincomelg]

I suggested a try-before-you-buy contract to a few companies that I applied with and none of them were interested. Maybe it is because the company is afraid of the contractor saying "What is the upside for me to join you as an employee? Just extend my contract if you want to keep me around." :-P

[jacques_chester]

So far as I'm aware, we don't go into references. If not, I don't know whether it's because we don't like to or don't have the bandwidth available.

[matthewowen]

Pairing for interviews is a good idea if you pair. But it's not a good idea if you don't: I don't like pairing, and I don't really want to work somewhere where it's a big part of what they do. I won't perform as well in an interview pairing, which ksbisfil info of you do pair, irrelevant if not.

[jacques_chester]

Engineers like yourself, who don't want to pair, self-select out before applying.

Which is fine! There's plenty of variety in this industry to find preferred practices, peers and environment.

[raverbashing]

You are right.

I like pairing. Once a week.

Being obligated to pair and doing it every day is No Way Jose for me

[0xmohit]

It's also a fantastic way to see how one thinks, one's problem solving approach, debugging skills and the like.

[jacques_chester]

It is!

I hasten to add that it isn't perfect. We hire across the intro-extraversion spectrum, but there's an ongoing concern that we're biased towards extraverts. Especially in Labs, which is the consulting wing.

Another problem is that many candidates are just plain nervous. We do our best to set people at ease and to be upfront that there's no right or wrong or trick answers. But interviewing is just scary. I expected to fail and so felt no pressure -- had I felt that more was on the line, maybe I'd have done worse.

The third -- this is a very common negative opinion -- is the argument that we don't give candidates a fair opportunity to show their expertise.

We will usually try to assign one project where their résumé claims expertise and another one that they're unfamiliar with. The former to take a sounding of their expertise, the second to get a feeling for their approach to the unknown.

It's not always possible to do this, simply because it's a vast field and candidates come with very varied backgrounds. And those candidates who are declined often feel that we've denied them a fair chance by throwing them into an unfamiliar technology.

These are all fair criticisms. My best answer is: we are not trying to trick or exclude anyone upfront. Ultimately the hiring decision is made by future peers, so we want to be fair but firm.

Hiring is just hard.

[passiveincomelg]

FWIW, I had a very positive experience with the Pivotal Labs interview process last year. Really enjoyed the pair programming sessions and got a very good idea what the job would be like day to day.

[greenyoda]

"Hey, come pair with this engineer on this real code on a real project on a real task."

I don't understand how I could pair-program effectively on a code base that I'm seeing for the first time and don't know the first thing about. What would you expect me to be able to contribute?

[jacques_chester]

> I don't understand how I could pair-program effectively on a code base that I'm seeing for the first time and don't know the first thing about.

Nobody expects you to magically know anything about code you've never seen before. That would be absurd.

The point is to get a sense of how you think and work as an engineer. We deliberately say that there are no "wrong" answers, that it's impossible to fuck up.

We want to know about the candidate. The decision is about hiring a person, not a list of codebases.

(Sorry for the slow reply, I was rate-limited.)