4 ms·

I kinda like this one. The "what to expect" is really well done. I also like the do-a-real-thing step. We do something similar at Pivotal. Once you pass the ba

I kinda like this one. The "what to expect" is really well done. I also like the do-a-real-thing step. We do something similar at Pivotal. Once you pass the basic tech screen, we invite you to work with us for a day. We pair program, so this is easy to do: take the candidate, drop them (usually) into a real project with a real engineer working on a real problem. Then they work together on the real problem. That's it. Assuming nothing goes drastically wrong: One project in the morning, then lunch, then a different project in the afternoon. If we agree that you know what you're doing and that we want to work with you, you're hired. Every engineer at Pivotal has passed the test of "do you want to work with this person?" In the quest to work out "can this person do the job?", I personally continue to be amazed at the gymnastics companies will engage in to avoid just ... trying folk on the job.

praneshp 10y ago
I hope I was the only person to have had a bad experience with Pivotal ever. Their recruiter straight up lied to me (told me on the phone that they'd schedule a phone screen, went on radio silence, and claimed they had emailed me about moving on). From my personal experience, I don't think Pivotal belongs in a thread discussing great hiring practices.
- jacques_chester 10y ago
  I'm sorry. We had a period where we had many candidates and not enough recruiters (hiring good recruiters is actually really hard). Some of the recruiters would get stressed out and quit. Some would, as you say, simply drop candidates on the floor without telling them. We also had a lot of trouble with our previous candidate management software. We switched to Greenhouse 2 months ago, it seems (touch wood) to be doing much better. If you like, you can contact me by email and I'll follow up for you. This offer extends to anyone else.
sethammons 10y ago
Hi Jacques! One thing I can't wrap my head around: how do you compare candidates when you have them working on different projects? How do you protect against Candidate A finding themselves pairing on a relatively easier project than Candidate B? How do you deal with pairing on things that are complex and require time to spin up to understand the system architecture, the code base, and the problem at hand? If you only expose smaller problems to candidates, how do you ensure that on any given day there will be an appropriate problem to pair with a candidate? Thanks!
- jacques_chester 10y ago
  It's less about "do they know this tech stack?" and more "do they have a knack, regardless of situation?" plus "do we want to work with this person?" In dividing the day, we always try to pick one project where hopefully they will feel somewhat at home. Good at Ruby? Here's a Rails app. Java person? I hope you like Spring Boot! Then for the other project it's usually something unfamiliar. Our goal is not to trip you up. It's not to play gotcha. It's that dealing with unfamiliar languages, toolchains, ecosystems, coding styles, testing frameworks etc is a big part of life for pivots, especially Labs pivots. This might sound like we only want generalists. This isn't quite true. We respect deep expertise -- deep knowledge of some stack or subject. But we also like comfort with the unknown. These are distinctive things. One is about knowledge held, the other about holding on in the face of the unknown. You do however bring up the problem of projects with high rampups. The answer is that these are the hardest to schedule and assess. In these cases we focus on picking stories out of the backlog which are as self-contained and low-context as possible. In very (very) rare cases, it will be impossible to find such a story or project able to take candidates. In those cases we have a collection of "canned" projects. Since it's not a real thing, we only use these as a desperate, no-alternatives, final, last resort.

praneshp 10y ago

I hope I was the only person to have had a bad experience with Pivotal ever. Their recruiter straight up lied to me (told me on the phone that they'd schedule a phone screen, went on radio silence, and claimed they had emailed me about moving on). From my personal experience, I don't think Pivotal belongs in a thread discussing great hiring practices.

jacques_chester 10y ago
I'm sorry. We had a period where we had many candidates and not enough recruiters (hiring good recruiters is actually really hard). Some of the recruiters would get stressed out and quit. Some would, as you say, simply drop candidates on the floor without telling them. We also had a lot of trouble with our previous candidate management software. We switched to Greenhouse 2 months ago, it seems (touch wood) to be doing much better. If you like, you can contact me by email and I'll follow up for you. This offer extends to anyone else.

sethammons 10y ago

Hi Jacques! One thing I can't wrap my head around: how do you compare candidates when you have them working on different projects? How do you protect against Candidate A finding themselves pairing on a relatively easier project than Candidate B? How do you deal with pairing on things that are complex and require time to spin up to understand the system architecture, the code base, and the problem at hand? If you only expose smaller problems to candidates, how do you ensure that on any given day there will be an appropriate problem to pair with a candidate? Thanks!

jacques_chester 10y ago
It's less about "do they know this tech stack?" and more "do they have a knack, regardless of situation?" plus "do we want to work with this person?" In dividing the day, we always try to pick one project where hopefully they will feel somewhat at home. Good at Ruby? Here's a Rails app. Java person? I hope you like Spring Boot! Then for the other project it's usually something unfamiliar. Our goal is not to trip you up. It's not to play gotcha. It's that dealing with unfamiliar languages, toolchains, ecosystems, coding styles, testing frameworks etc is a big part of life for pivots, especially Labs pivots. This might sound like we only want generalists. This isn't quite true. We respect deep expertise -- deep knowledge of some stack or subject. But we also like comfort with the unknown. These are distinctive things. One is about knowledge held, the other about holding on in the face of the unknown. You do however bring up the problem of projects with high rampups. The answer is that these are the hardest to schedule and assess. In these cases we focus on picking stories out of the backlog which are as self-contained and low-context as possible. In very (very) rare cases, it will be impossible to find such a story or project able to take candidates. In those cases we have a collection of "canned" projects. Since it's not a real thing, we only use these as a desperate, no-alternatives, final, last resort.