3 ms·

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 Ca

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.

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.