From Technical Hiring to Culture Fit
By

December 1, 2015

From Technical Hiring to Culture Fit

Read more interviews with some of the world’s best developers on * or follow us on or follow us on .*

“Cultural fit will trump all technical skills,” says Rothman. When we think about what we’re looking for in a technical candidate, “we often think about this laundry list of technical skills that we need.” But that’s the wrong approach - “our ability to collaborate with each other or to problem solve together or alone… are the things that really matter,” says Rothman. She recommends a focus on cultural fit first, where culture is “not about Foosball. It’s not about the color of the walls. It’s not about the desks that you have. It’s about what you can and cannot say in the organization, how people treat each other, and what you reward. That’s the culture that you’re hiring into.”

To understand the key elements of your culture, Rothman suggests that you “look at a successful project or even a series of successful hires. What do they have in common? Did they problem solve together? Did they ask each other for help? Did they say, ‘we’re going to use this particular tool for this?’” So you can begin to understand your culture by considering “what success has looked like in the past,” says Rothman, and then thinking through the people you need to deliver that going forward.

When it comes to culture fit and diversity, Rothman says that “the biggest thing is to acknowledge that we are all human and we like people like ourselves.” But she says that we shouldn’t just “leave it at that” as “the best products come from diverse teams”. It’s all too easy to say “‘I’m only going to recruit from schools I went to or schools I know about and I’m only going to recruit from my little, tiny circle of friends’, but then “you’re never going to get the diversity that you want. You have to open up your recruiting, your sourcing, and say ‘where am I likely to find people, great people that I want?’”. Otherwise Rothman warns that we can be “insular in our hiring”, and suggests that “it’s time to expand horizons a little”.

When it comes to hiring for a new technical role, Rothman suggests starting by “doing an analysis of the problems that you want to solve with a new hire”. After all, “if you’re not clear on what the problems are, you’re not going to be able to solve those problems.” After that “do a job analysis,” this “is essential in understanding what you really want. What are the essential non-technical qualities, preferences, and skills and what are the essential technical skills?” However, she stresses that when it comes to this, “you really need to think about what’s essential versus what’s desirable.” You want to avoid ending up with a “shopping list of many, many technical skills.”

What’s more, according to Rothman, “the idea that people can only learn one language and we have to have this emphasis on ‘if they don’t have three years of Ruby’ or something, then we cannot hire them. That’s just nuts.” Your time is better spent “really thinking about what kind of people do I want in this role”.

Then you can move on to writing “a job description from the job analysis. You can develop your phone-screening questions. You can decide if you want an audition first, second or third, and you can set up the interviewing”. But regardless of what you do, Rothman cautions, you should “always check references.”

“I really like behavior-description questions,” says Rothman. An example being something like, “tell me about a time that you had to choose between these tools”. In that example Rothman says it’s important to get the candidate to “tell you about the project, and tell you about the context. That actually gets you the detail that you need.”

She also recommends avoiding “hypothetical questions, or you asking irrelevant questions like, ‘tell me about your weaknesses.’” Instead, Rothman suggests a better question would focus on “giving me an example of, or telling me about a time when” as these will give you “a really great foundation for a conversation.” She remarks that she’s also received “very surprising answers and a lot more insight into what the person can do” by asking the question “what have I not asked you yet?”

Beyond questions, Rothman says — “I like auditions also. That’s where you actually see people doing the work”. They don’t have to be very long, “twenty-minute auditions” work well, but “if you’re hiring technical people, watch them do the work and that’s all you need to know”.

Finally, once you’ve actually hired someone, Rothman says that “the first day is so, so important.” However, “I cannot tell you how many people I know who don’t have a desk on their first day, don’t have a computer, don’t have a login, don’t have a password. There is no way for them to contribute.” So Rothman suggests having a checklist of those little things to get people started.

“The other thing I really like is this buddy system. The team has some level of productivity. When you have a new person, the productivity level dips because that person’s asking questions, they don’t know what to do.” So “one of the things you can do is have a buddy system where you have someone whose job it is to shepherd this person through the next couple of weeks or a month”. It’s basically their job to “tell the new hire where the bathrooms are, how do I compile, where do people go for lunch.”

Finally, she also likes “what Arlo Belshee calls ‘promiscuous pairing’”. That’s where you “pair with somebody for twenty minutes or forty-five minutes… and then I go and pair with somebody else”. This is a great way to “learn how everybody uses the tools and technology and… to learn that really, really fast.”

Read more interviews with some of the world’s best developers on * or follow us on or follow us on .*