Hiring in 2018 — Revisited

Hiring in 2018 — Revisited

This year, we hired a People and Operations (PoPs) Manager (we think we’re cute). Our PoPs Manager oversees all things HR and most things Operational. It’s a great role and we’re learning so much, having a dedicated professional paying attention and being pro-active. Armed with Google surveys, she set out to take the temperature of the people on a wide range of topics: culture, diversity, inclusion, belonging, and hiring standards. These are all topics I hope to explore but for now I would like to talk about how we changed our hiring processes in 2018.

My interviewing techniques have served me very well. I have built teams for 30 years, honing my interviewing style as I learned more about people and figured out how to apply what I always thought was my useless linguistics degree. I rarely care about technical skills or aptitude, I care more about a growth mindset and grit. It’s backfired on me a few times. I once sold a company and had to hire my replacement. My primary job at this company was reverse engineering databases and I ended up hiring someone who talked a great game but could not write a SQL statement to save his life. Needless to say, you can’t reverse engineer a database without understanding how data relationships are maintained. I learned from that one. Here was my solve: I ask a candidate to pick two of their top languages and compare them for me. It shows me how much they have thought critically about the languages they have used and if they have pushed the technical limits of those languages. You can’t fake your way out of this question. You either know your language well, or you don’t. Either is fine, I just need to understand where you are in your career and what you think you’re capable of (Growth Mindset). Though I am well versed in a lot of popular languages, I don’t speak Bocce (#starwars #nerd #alert). I find it actually most effective when I don’t know one of the languages and their explanations have to account for my lack of understanding. I get a great sense of their communication abilities and style.

I get it right more often than I get it wrong. But, yep, I get it wrong sometimes which is frustrating for someone of my career age. When you run the Technology Team at Eight Bit Studios, it can frustrate others too. But, I can and do learn!

Our new PoPs Manager put together a framework to help us focus and normalize our interviews across the company. We’ve recently come to understand that we will Always. Be. Hiring. In light of that realization, this framework and its attending processes are hugely important. I’ll hold off on the details of this framework and see if I can get her to write about them but I would like to talk about the structure of the onsite interview.

We interview a single candidate using a panel format. This is not uncommon and it’s something I have done many times before. The difference now is, our panel is made of people both inside and outside of that candidate’s domain of expertise. A developer may be interviewed by a designer and someone on the user experience team. I used to bristle a bit at this kind of configuration, not seeing the value, worrying about the cost, and it slowing the hiring process. Having seen it in action, it’s amazingly effective! Each person on the panel is assigned a certain vector of concern (I just made that term up!). Let’s say we have a team of four people on the interviewer panel. One person may be client focused, asking questions about client relationships, etc. Another person may be process focused, while a third might ask questions about culture and a fourth asks domain specific questions. Each person comes up with a core set of questions along their assigned vector and those core questions are asked in every interview. It’s really amazing to watch and observe.

I am keenly tuned into the topic of Failure. It’s how we learn. We can’t correct unless we’ve failed. If we succeed initially, it’s hard to replicate that success because there is nothing to nudge or correct. I am a firm believer in learning from failure. It’s also a huge part of our culture. My technology team gets it. The younger developers take some convincing that no one will be coming after them with pitchforks if they screw up and that, indeed, we will have their back with support and feedback.

During the freestyle section of the interview, when all core questions have been exhausted, I started inserting a new question. I usually ask people to tell me about an occasion when they’ve screwed up; how they handled it, or if they didn’t handle it, what they would do differently. I find it extremely revealing. If someone can’t come up with an example, it shows me that this person either lacks the skills to communicate failure OR has never truly experienced failure, which as we all know, is not possible. I have experienced failure three or four times in the last week alone! My new twist on this is to ask the candidates: how would you screw this job up? Imagine you’re a month into this job, how do you fail? I began asking that question just recently but it’s paid off already. Most people hone in on what they think they’re supposed to say and what they think I want to hear. It’ s very obvious when that happens and it might take some practice to spot it so rely on your interviewer peers to help sort out the answers. Sometimes they’re just afraid to answer the question but can’t articulate why. When someone nails the question, it will feel like: “wow, yeah, that’s exactly how you can screw this up.” The key here is not to ask about how they would fix their speculative missteps. It’s not a fair question and really gives you nothing to think about. Pay attention to their original answer and see if anything surprised you about the content or the fidelity.