4 ms·

It turns out, the answer to whether someone can do the job you'll hire them for is to do a little of the job you'll hire them for. (Carpenters don't whiteboard

It turns out, the answer to whether someone can do the job you'll hire them for is to do a little of the job you'll hire them for. (Carpenters don't whiteboard bridle joint solutions for cabinetmaking, prospective chefs don't solve biochemistry problems, etc). I work for Pivotal. For engineering hiring is done in two parts. The first part is "Rob's Pairing Interview". This is a simple technical screen -- essentially, if you have some programming nous, you will pass. Takes about 30-60 minutes. The second part is to bring you in for a pairing day. In the morning you pair with an engineer on one team. In the afternoon, on a different team. A different group of folk take you to lunch (we try to have a mix of disciplines and divisions for the lunch). When you're pairing, you will work on real code, for a real problem. We usually try to put you into two teams with different stacks or problem spaces, ideally matching one of them to something you cite on your résumé and the other one to something you don't. I think it works pretty well (obvious bias: I did well enough to get hired). Folk who really don't want to pair self-select out, usually even before applying. Everyone I work with is capable and personable, which goes a long way to making it a great place to work. So if you have a way you actually work, see if you can just try that.

dozzie 9y ago
The problem is that you're also filtering out the candidates who are not interested enough in the company yet to take a day off from their current job. And most of the good programmers probably already have a job that's comfortable enough.
- jacques_chester 9y ago
  This is one of the two most common objections I see raised when I describe what we do, the other being the pairing thing. Of the two, the fact that we preach and practice TDD and pairing probably shrinks our applicant pool more than any other factor. For people who can't get the time to do a pairing day, it sucks. We miss out, they miss out. There's no dressing things up: we know it costs us good applicants. But for people who just aren't feeling it, it's actually a good thing. As you note, it's a seller's market. Why would you apply for a job you feel only "meh" about? Why would we want you to?
  - dozzie 9y ago
    > Why would you apply for a job you feel only "meh" about? Because I don't know yet. You're not that famous that I would know work conditions at your place from hearing your name only. You need to convince me that you're a good company. (Too many people forget that interviews are not only for company to assess the candidate, but also for candidate to assess the company.) > Why would we want you to [apply for a job I feel only "meh" about]? An employee doesn't need to be all cheery and enthusiastic about the field to do a really good job there. For instance, I couldn't care less about TV, I don't watch it for a long time, but since I started my current job in IPTV, our infrastructure got much more robust, easier to manage and monitor, and easier to extend. And why would you want me to apply? Because I'm a good craftsman, I bring to the table a perspective unusual among the programmers, I like to share my knowledge with colleagues, and I like writing (technical) documentation. It's a ridiculous thing to expect a candidate to be enthusiastic about you before he even got a chance to talk to you. This idea needs to die out.
    - jacques_chester 9y ago
      I feel like we are talking past each other; that you're getting the impression that we're looking for cheerleading rah-rah types. That's not what I intended to convey. What I wanted to convey is that we want people who want to work the way we work: TDD, pairing, sustainable pace, balanced teams, mutual trust. People who hear "Do what works. Do the right thing. Always be kind" and think it shouldn't need to be mottoised in the first place. > Too many people forget that interviews are not only for company to assess the candidate, but also for candidate to assess the company. Absolutely. I've known folk who did great, enjoyed their time, but got the chance to taste the actual job and decide that it wasn't for them. Expanding on your point: wouldn't you want to know what the job is actually like? Because it's not as though trivia contests are a daily part of engineering life. What you see is exactly what you'll get. I got an offer in October of 2013 and I started in February of 2014 (immigration, yay). I spent the first few weeks waiting for the shoe to drop. "This is just like the interviews", I thought. "When does the real job start?" It took a while to realise: this is the job. This is the actual job. There were no surprises. I came in, I interviewed, I had a fantastic time and I've wound up in the best job I've ever had. > And why would you want me to apply? Because I'm a good craftsman, I bring to the table a perspective unusual among the programmers, I like to share my knowledge with colleagues, and I like writing (technical) documentation. Again, I think I gave the wrong impression. It may seem that I am standing in judgement of people who don't want to apply, or prefer not to work the way we prefer, or who think the process is ridiculous. That is not the signal I mean to convey. Let's go back a step. The discussion here is: "how do you conduct coding interviews?", with the assumption that we've reached the coding interview in the first place. Pivotal does that with pairing and frankly it works really, really well for us. Getting to that point is difficult, but we wouldn't do it if we didn't think the net results were terrible.
Geekette 9y ago
So, you/Pivotal are saying you require an entire day after 1st interview to deduce whether an applicant can work for you? Seems you're initially screening by who can devote that amount of time before anything else. I also assume the shortage/difficulty of finding tech staff doesn't affect the company, given the insistence on this. Do you declare this time requirement in your job ads? I imagine candidates would appreciate knowing this so they wouldn't bother applying in the 1st place.
- jacques_chester 9y ago
  > Do you declare this time requirement in your job ads? I checked, we don't. You're right that we ought to at least flag it as a possibility. It's worth bearing in mind that it's the last stage. By the time you reach it we've done a résumé review and a recruiter has rung you to describe the RPI and pairing day. There's no up-front time commitment beyond submitting your CV. I imagine lots of people say no at this stage. That's fine. It's actually as it should be, if you think about it. > I also assume the shortage/difficulty of finding tech staff doesn't affect the company, given the insistence on this. It affects us sharply because of this. We do it because we would rather choose colleagues carefully than quickly. Hiring is not a sprint. Every hiring decision is strategic. There are no shortcuts. We pay a heavy price in lost opportunities and we pay it gladly.
greenyoda 9y ago
"When you're pairing, you will work on real code, for a real problem." Do you pay them at least minimum wage for this real work that benefits your company, as required by federal law?

dozzie 9y ago

The problem is that you're also filtering out the candidates who are not interested enough in the company yet to take a day off from their current job. And most of the good programmers probably already have a job that's comfortable enough.

jacques_chester 9y ago
This is one of the two most common objections I see raised when I describe what we do, the other being the pairing thing. Of the two, the fact that we preach and practice TDD and pairing probably shrinks our applicant pool more than any other factor. For people who can't get the time to do a pairing day, it sucks. We miss out, they miss out. There's no dressing things up: we know it costs us good applicants. But for people who just aren't feeling it, it's actually a good thing. As you note, it's a seller's market. Why would you apply for a job you feel only "meh" about? Why would we want you to?
- dozzie 9y ago
  > Why would you apply for a job you feel only "meh" about? Because I don't know yet. You're not that famous that I would know work conditions at your place from hearing your name only. You need to convince me that you're a good company. (Too many people forget that interviews are not only for company to assess the candidate, but also for candidate to assess the company.) > Why would we want you to [apply for a job I feel only "meh" about]? An employee doesn't need to be all cheery and enthusiastic about the field to do a really good job there. For instance, I couldn't care less about TV, I don't watch it for a long time, but since I started my current job in IPTV, our infrastructure got much more robust, easier to manage and monitor, and easier to extend. And why would you want me to apply? Because I'm a good craftsman, I bring to the table a perspective unusual among the programmers, I like to share my knowledge with colleagues, and I like writing (technical) documentation. It's a ridiculous thing to expect a candidate to be enthusiastic about you before he even got a chance to talk to you. This idea needs to die out.
  - jacques_chester 9y ago
    I feel like we are talking past each other; that you're getting the impression that we're looking for cheerleading rah-rah types. That's not what I intended to convey. What I wanted to convey is that we want people who want to work the way we work: TDD, pairing, sustainable pace, balanced teams, mutual trust. People who hear "Do what works. Do the right thing. Always be kind" and think it shouldn't need to be mottoised in the first place. > Too many people forget that interviews are not only for company to assess the candidate, but also for candidate to assess the company. Absolutely. I've known folk who did great, enjoyed their time, but got the chance to taste the actual job and decide that it wasn't for them. Expanding on your point: wouldn't you want to know what the job is actually like? Because it's not as though trivia contests are a daily part of engineering life. What you see is exactly what you'll get. I got an offer in October of 2013 and I started in February of 2014 (immigration, yay). I spent the first few weeks waiting for the shoe to drop. "This is just like the interviews", I thought. "When does the real job start?" It took a while to realise: this is the job. This is the actual job. There were no surprises. I came in, I interviewed, I had a fantastic time and I've wound up in the best job I've ever had. > And why would you want me to apply? Because I'm a good craftsman, I bring to the table a perspective unusual among the programmers, I like to share my knowledge with colleagues, and I like writing (technical) documentation. Again, I think I gave the wrong impression. It may seem that I am standing in judgement of people who don't want to apply, or prefer not to work the way we prefer, or who think the process is ridiculous. That is not the signal I mean to convey. Let's go back a step. The discussion here is: "how do you conduct coding interviews?", with the assumption that we've reached the coding interview in the first place. Pivotal does that with pairing and frankly it works really, really well for us. Getting to that point is difficult, but we wouldn't do it if we didn't think the net results were terrible.

Geekette 9y ago

So, you/Pivotal are saying you require an entire day after 1st interview to deduce whether an applicant can work for you? Seems you're initially screening by who can devote that amount of time before anything else. I also assume the shortage/difficulty of finding tech staff doesn't affect the company, given the insistence on this. Do you declare this time requirement in your job ads? I imagine candidates would appreciate knowing this so they wouldn't bother applying in the 1st place.

jacques_chester 9y ago
> Do you declare this time requirement in your job ads? I checked, we don't. You're right that we ought to at least flag it as a possibility. It's worth bearing in mind that it's the last stage. By the time you reach it we've done a résumé review and a recruiter has rung you to describe the RPI and pairing day. There's no up-front time commitment beyond submitting your CV. I imagine lots of people say no at this stage. That's fine. It's actually as it should be, if you think about it. > I also assume the shortage/difficulty of finding tech staff doesn't affect the company, given the insistence on this. It affects us sharply because of this. We do it because we would rather choose colleagues carefully than quickly. Hiring is not a sprint. Every hiring decision is strategic. There are no shortcuts. We pay a heavy price in lost opportunities and we pay it gladly.

greenyoda 9y ago

"When you're pairing, you will work on real code, for a real problem." Do you pay them at least minimum wage for this real work that benefits your company, as required by federal law?