WINNING AT TECHNICAL HIRING WHEN EVERYONE IS PLAYING THE SAME GAME

by LOREN LARSEN

Loran-Larsen

Loren Larsen is responsible for guiding HireVue’s product direction through the product management, user experience, and engineering teams.  Larsen is an award-winning technology veteran with more than 20 years of engineering and research experience. Prior to joining HireVue, Larsen led the development of innovative mobile device applications and video relay services for the deaf as director of Engineering and Mobile Products at Sorenson Communications. Earlier in his career, he served as Vice President of Engineering at Move Networks – where he was responsible for development of the Move online HD video player, which was deployed to over 50 million users – and as Chief Software Architect at World Wide Packets where he architected carrier-grade ethernet platforms.

Larsen was previously co-founder and board member for Pepun.com, which enables independent filmmakers to market and monetize their films online. He has earned both a master’s degree and a bachelor’s degree in Computer Science at Clemson University and the University of Utah, respectively.

Webinar Transcript

Announcer: Hello and welcome to the Tech Talent Summit. We have assembled an array of sponsors and speakers for you today that will cover topics such as measuring unconscious bias, winning at technical hiring when everyone is playing the same game and the top three mistakes to avoid when hiring an engineer, and many more. I would like to thank our sponsors for helping to make this online event possible. Glassdoor, Textio, IBM Watson, University of Phoenix, HireVue, Career Crossroads, Recruiting Toolbox and Paired Sourcing. To open our event today, we will hear from Loren Larson. He is the Chief Technology Officer for HireVue and is responsible for guiding HireVue's product direction through the product management, user experience and engineering teams. Loren is an award winning technology veteran with more than 20 years of engineering and research experience. Prior to joining HireVue, Loren led the development of innovative mobile device applications and video relay services for the deaf as Director of Engineering and Mobile Products at Sorenson Communications. Join me in welcoming Loren.

Loren: Thanks. We are glad everyone could join today and this session is really to kick things off and talk about some of the challenges that we see people having when they are trying to build technical teams and maybe some ways to sort of change the rules, so that you can get an edge in the market. So really we've got a wide ranging group here today. We've got engineering leadership and talent professionals and they come from tiny startups all the way to Fortune 100 organizations. So trying to present a general set of rules and guidelines that can be helpful for everybody.

So let's kind of define what some of the usual rules are and these are broad generalizations but when you want to hire for a new position, generally you start by writing a job description. Then you do some kind of sourcing, you post it to job boards, you post it to LinkedIn. You might have some other sort of more modern, hip, sourcing tools. Then you might have an employee referral program. It's either very informal, like just sort of posting it out to an email list of the company or a more formal employee referral program. Most time it's pretty ad-hoc for most companies that we've seen and then you start the interviewing process. So let's talk about some new ways to kind of think about this.

And the first thing, and we'll call it the sort of new rule. New rule number one is question hiring in the first place. So hiring is never an actual business goal. I mean, it is a goal for some people in the organization but you're not doing it for the sake of hiring. You're doing it to build a new product, to go after a new project, to go faster on a current project or be responsive to customers, or get some other tangible measurable business results that your board of directors or investors care about. So hiring is just a means to achieve all of that and it sometimes, because hiring is hard, let's take a little bit of a step back and think about some alternatives. Many organizations, especially ones with big hiring demands, also have a lot of waste. And so maybe you have an opportunity to automate testing or deployments of code, or maybe you've got customer service or customer success or your sales team interrupting your technical team with questions, or you've got customer directly reaching in. And as we all know, interruptions are extremely disruptive to productivity of a technical team.

So we see teams, including our own team at times, gets interrupted 20% to 30% of their time with just interruptions. So maybe the solution here is get that 20% to 30% back by putting a sales engineer or dedicating some engineers on a rotational basis to sort of shield the team and you get 10% or 20% of that time back sometimes, without having to hire new people.

We also see organizations that haven't invested in hardware for their team. So they are running on old laptops and they're spending 5 or 10 minutes waiting for a build or some task to complete and while they are waiting they go off and look at the web or they walk around, get a snack, they go talk to somebody and half an hour later they are back at their desk. And you are seeing hours in a day disappearing, which you could get back by providing better hardware, which is relatively cheap in the whole scheme of things. So those are some things that you can look at in your organization to kind of get productivity back of the people you do have, so you don't have to go out and hire more people, because that's hard. Then of course every time you add new people, you've got to have managers to manage them and the other advantage is the people who are there are going to be more engaged and you're going to have higher retention because they are happier or more engaged in their job. So that's one alternative.

The next thing that we see is, do people really know what it is that they need? And sometimes a new project comes out and the goals are not clearly defined. Do you really know the skills that you need for the project? Do you really have the definition right? Do you need business analysts and product managers to validate the concept first? If you're in a lean environment, you want to make sure you have really nailed that business case before you start ramping engineering. If you ramp too early, you get people sitting idle when you could have invested in other projects. Maybe you need engineers up front to go and not business analysts and product managers to go validate and prove that the project is possible and get the risk out before you build the team to go after something that isn't feasible.

So that's a big challenge and we see customers sort of miss on that and they end up with a team that's kind of misshapen or over-hired or they've got too many front-end developers when they really needed back-end developers or they hired mobile developers but that isn't the place to start on a project once it gets defined. So getting really clear up front with what is it that you need is supercritical.

So the next thing is, let's assume that all that's out of the way and you've decided you really do need to hire fast. So new rule number two is, it's not about ninjas and rock stars. And we hear this a lot in organizations where it's really about we need ninjas and rock stars, we need superstars and do you really need that? And not every organization is caught up in this, but in the startup world it's particularly prevalent when you read job descriptions. Do you need an all star team or do you need a team with one superstar, like a Michael Jordan, with some pretty good supporting players and some utility players? What is the shape of the team that you need? Getting clear about what positions you need on the team, what the caliber of the people are helps you focus your sourcing efforts because there are a lot of different places to get talent today and you can create a mixture of people from different sources.

So examples, you can go off and you can hire offshore teams. Everyone is familiar with building a team in India or China or South America and there are great ways to do that and it works really well if you are doing things that that works really well for. The newest trend that we see is developer boot camps where you take somebody who used to work at hospitality or aerospace or retail, and they might have an engineering degree, they might have a high school diploma. And they take 8 to 16 weeks, and they go take a 4 hour a day or 16 hours a day class depending upon the program and they learn to be a web or mobile developer and when they come out of school, there are things that they can do and they might be just perfect for what you need. Or you might need to take some, you might be able to go get people from a non-traditional program like an ITT Tech or University of Phoenix. There are great veteran hires that are coming out of those kinds of programs. There's great people who have been in one field and wanted to learn IT, or you might need somebody from a more traditional university, computer science or engineering program.

But again being very clear about what do you need? Do you need ninjas and rock stars or do you need a ninja and four junior people from boot camps and that will be a perfect choice for you? I think it's pretty easy for people to sort of assume they need to get all people from one place. We've got a customer that is doing maintenance, they have an old legacy application. It's written in a really old language that nobody knows and for the most part, it's pretty hard to hire people to do that work. There is not a lot of IT people today who are clamoring for that job. So they interview people who might have been overlooked by the traditional system and they give them an aptitude test, sort of around logical reasoning and thinking skills. If they pass that aptitude test, they bring them into an internal boot camp where they train them to be developers in this language on this application to maintain it and evolve it. So that's another option that companies can pursue when they have specialized needs.

So the third thing is what I call, "Why over everything." And one thing when you are hiring is you really want to start with the "why", why are you doing the things that you do? And when you start with "why" rather than, "This is what the job is. Here are the skills that are required." You want to tell people why they would want to sign up to be part of your mission, your vision, your dream. When you start with that, it creates a very compelling reason that's going to engage people. Maybe your company was set up because you saw a market opportunity to start a company and sell it to a bigger company and have a quick exit. And you might not actually have any passion for that business at all, it's just about the money. But that's okay, as long as you align with other people with similar goals you'll get a group of people who want to work together. Or you might be doing something like medical billing and there is a story in there about making life better for people by sending them simple medical bills that anyone can understand and that are accurate. And think what a relief that would be for a family going through a health crisis. If you tell that story to a candidate, a good number of them are going to resonate with that piece.

They've been in that situation. They know someone who's been in that situation and being part of that and solving that problem, would be really compelling to them. I used to build basically metal boxes with cables coming out of them that delivered network services, which at some level sounds incredibly dull. But looked at in another way, we were building a superhighway for bits of information that let people communicate all around the world in ways they had never been able to do before. And that's a completely compelling story for many people to be a part of. If you are a larger company, your story might be simple, it might be you are a rock solid part of our economy, provides a relatively stable job with a good balance in work and the rest of life. And that might be the exactly the story that the talent you need is looking for.

So when we started HireVue, the story was about...well the first thing I thought of when I heard of HireVue before I joined was, "Well they do video interviewing. They help people interview with video." That didn't sound that exciting, and it was HR software, which didn't sound that exciting to me. But then I got the story and the story was about how hiring hasn't changed in the last 2000 years. It's always been about somebody having to meet another person face to face and figure out what questions to ask, and being awkward and time consuming and spending a lot of time with people who weren't the right people. And HireVue is going to simplify all of that and give people a way to tell their story beyond a resume. Where they weren't just a piece of, a bunch of words on a page but they can come to life in a video and really be seen in a way that they never got to be seen before. That was a really compelling story and got me to join the company.

So putting out your message and your "why" of why it is that your business does what it does and why you get up in the morning every day to do it is an incredibly powerful...I call it a technique and it is a technique in a way, but it's very engaging. It helps people understand if they want to be part of your organization or not. And if you've got that story, and if you've come up with that story, you got to tell it. And it's got to show up somewhere inside of your interview process. So we had a customer who was the head of HR of an international company and they had just recorded a video as part of the interview process that every candidate would see and it was very simple. It was basically, "Welcome to our company, we are looking forward to getting to know you through this process. And now let me tell you why I joined this company and why you should, too." It was just an honest, direct message from a senior executive to every single person whether they were going to drive a truck or they were going to be in accounting or in IT, and it was incredibly effective.

So you don't have to record a video but make sure that the people in the process at some point are telling the "why", why they are part of it, why it matters to them, why they get up and do what it is they do every single day. And that will be incredibly engaging to candidates.

So the fourth one, is about culture. And I'm not a big fan of the word culture because it's so abused and it usually gets shown with cheesy stock photography of people in glass rooms, smiling like they couldn't imagine being anywhere else but at their job. But let's just define it as the way things get done around the place. But really that defines, like any good marketing campaign... A marketing campaign helps people understand whether the message that you're putting out is for them. Whether they want to become a customer, become a part of whatever your company is offering or not. So it's going to attract people to your message and it's going to repel people and that's okay. You want to figure out who are the people who are attracted to what you're doing and not spend your time with the people who are going to be repelled by your message.

And when I say, it's the way things get done around here, culture is a sort of this aggregation of the way you do things in your organization. I'll give you an example from HireVue, when we first created the organization, especially our engineering organization, we were very conscious about deciding how are we going to do things and what do we expect from the people who are going to join? So a couple of examples of that are we wanted to create a customer culture which meant every single person we hired in the technical organization had to have some kind of a passion for customers and what customers do. They wanted to see their work get used in some way in the real world. They wanted that pay off, they wanted the feedback. Not everybody who is in tech cares about that. Some people, they just enjoy the process of doing the work. They want to be left alone, they don't want to be bothered with customers. Well, we wanted people who care about that. There's nothing wrong the people who don't, we just want consistency around that.

We also wanted what we call a DevOps culture. We also want what we call a non-QA culture. What that means is we didn't want a big division between our engineering organization and operations organization. We wanted people who built it to be responsible for operating it. Not everybody is interested in operating anything. They want to write code and they want to write more code. But we wanted people who were going to write code, make sure that it worked, we weren't going to hand off to a QA organization to test it for them, they had to be responsible for it working and we do as a practical matter offer some QA help to facilitate that so people use their time effectively. But ultimately the developers are responsible and then developers are responsible for deploying that code and making sure it works in operations. And there is some help but the fundamental responsibility goes back to developer. That's not for everybody, but we wanted to make sure that everybody who came into our organization felt that way.

We advertised that in the process, we talk about it publicly, we talk about it in our job descriptions and people are either attracted by that, they think that's wonderful or they think that's horrible and they walk away. And that's okay, they wouldn't be a good fit anyway. So a couple of other things that we see about culture, people often define their culture by the perks. What's your vacation policy? Do you have free food stocked? Do you have, sometimes it's about the call and the benefits, what's in it for them? But if that's all that people are interested in and they don't have these other pieces then you end up mercenaries who are going to jump the next time somebody has a better perk for them. So you wanted to define your culture holistically and not just focus on perks because they're kind of a double edged sword.

If somebody hears that you have video games in your office and that's all they care about because that makes them cool, they are going to probably spend their time playing videos games, which isn't really the purpose. It should be about you have the video games so that people feel part of something and there is time to relax and balance work and play. So you really want to advertise those things clearly so that people know whether it's a fit for them or not. And it's an incredibly useful thing for people who are looking for a position because if you put all this out there it's easy for them to decide if they want to be part of it.

So the next rule I'll call take a position, and this is really closely related to what we have just talked about. But take a position is again kind of taking a position on certain things that you believe in. The first one, as an example, would be like Yahoo! has recently, in the last couple of years, taken a shift from let's have distributed teams, let's have people work from home to we want people working in offices together because we believe that creates the best sense of collaboration. That's a position. There are people who really want to work in an office, at their house every single day with other people around the world in their offices and there's companies out there that have no offices at all. Their entire teams are spread around the world in different time zones, in different locations and that works wonderfully for them.

But again, kind of defining your position helps people decide, "Do I want to be part of that, or do I want to be part of something else?" Open floor plans is another one. We personally don't believe in open floor plans. We believe engineers need quiet spaces to get work done rather than being interrupted and not everyone believes in that, some people love the open floor plan but that's not our position. But we have seen people who have interviewed with companies with open floor plan and they select our company and one of the deciding factors is because they like our position on this. So even if you've got a cube farm with cubes everywhere, take a position like, "This is how we do it. This is why we do it, this is why it's okay." And that will attract the people who that's okay for and it will repel the people who it's not. And as you're kind of sifting through your talent pools, that's a really important thing to do so the people you do hire are the right people.

We know that the supply of technical talent is really short and you want to cast your net as widely as possible. So why not open up your hiring to a more diverse pool? And so I'm really talking about diversity here. And it sounds completely logical, of course you want to cast your net as widely as possible but there is a lot of talk right now in the tech community about the lack of diversity in both gender and race, and Facebook's put out studies about their work pool recently. This is another thing to, like, take a stand on. Think about consciously about where you want to be on this. Kieran Snyder from Textio is going to talk later about some ways that unconscious bias shows up that can limit your ability to attract a diverse workforce and cast that net widely. But think about that. Think about are you doing things that's keeping women from applying? Are you doing things in your workforce, in your talent process that's keeping African Americans from applying? How do you reach out to those groups? This is a place where you want to take a stand.

There are a lot of companies out there who, apparently, haven't given this any thought. They haven't taken a stand about, "We want to be diverse, we want to be inclusive, we are going to create the behaviors and processes in our company to do that." And, you know, women are running out of tech because it's not friendly. It's not a place where they feel they can succeed in the way that they want. So that's another place to take a stand and I would encourage you to give that quite a bit of thought because I think it really opens up the possibility to build incredible great teams if you get that right.

So the next rule is evangelize. And this is one that's been a little bit difficult for, sort of, me as an engineering leader because it means you're going to put your people out there. And you're going to put your brand out there which means you're also saying, "We have an awesome team, we are great." And that makes you a target for every recruiter in the world. So it pays off but the things that we see work, you sponsor local events, you buy some pizza every once in a while. Those are good, they get your brand out there. Hosting events yourself, getting people into your office space for things to meet your team. You can sponsor local Meetup groups like Google Developers Group or you can host your own events around let's have a watching party for the next time Apple does an event to announce new iPhones or the new iOS release and you get developers to come in, you serve some pizza, you have popcorn and drinks and people kind of come watch and talk about it with each other. They meet new people and they have been in your office so they've met some of your team.

And they don't forget that and then people, they go back to their, wherever they were working and people go, "Well where were you this morning?" And they go, "Oh, I was over at such and such a place," and it gets your name out there in the community and [audio skips]. And then in terms of diversity, you can again sponsor Meetups but you can focus on groups like Girls Who Code or Pi Ladies or Closer Bridge and you're getting new, young developers from diverse groups in your office, in your space knowing your team and you are sponsoring a great cause. That will definitely help you in building up your reputation in your talent market.

Another idea that we've had, that I frankly never thought would work, are what we call office tours. And when you're going after passive candidates, you often get, "Oh, I'm not interested." And our recruiting team has been really good at saying, "Well, we know you're not interested but, you know, maybe you just want to come by for lunch once one day. Swing by the office, we'll introduce you to some people, tell you a bit more about what we are doing and, you know, no pressure. Just come take a look. Is there any harm in that?" And I am surprised so many people take us up on that offer. They come by, they are really passive and then after the end of lunch, because have met with some people, it's become personal. A few people have shared the "why" of what we do. Why they're passionate about being a part of it. And they turn from passive candidates to active candidates. And it's just a casual interaction to get people in but it works really well.

The third thing about evangelize is your candidate experience. Every time you talk to a candidate, whether it's an email off of a response you've gotten from a LinkedIn inmail or if it's a phone interview or a video interview, how fast do you get back to people, if it's the experience of being in person. How do the team treat them? Were they kept in a room locked up for six straight hours with nothing to drink and no bathroom breaks? All of those things that you are doing with candidates are going to end up showing up in your reputation and what gets broadcast in your talent market. So be very conscious about those things.

A great candidate experience will ripple. Somebody who interviewed, even if you don't like them, will talk well about at the next family gathering. And their brother and their sister-in-law and their brother's friends who happen to show up might all be people you would want to have join your company and everything you've done in the candidate experience will show up there and determine how likely they are to do that.

The other thing that has been really successful for us is getting our people to go out and speak. Go to Meetups, go to local conferences, put out what you're doing. And every time they are out there they are an ambassador for your brand and for your company and for your culture, which means people are making this decision about whether they want to join or they don't want to join. And it takes a while to sort of build up enough of a, you know, once people see somebody once and then a second time and a third time, that might be what it takes for them to act. Or you get them on a day when they've had a bad day and they go, "Wow, I just saw that guy speak, I should probably should look into that company and apply." Over time, you start to see all of these things stack up and it becomes easier and easier to attract people into your local talent market. So I would encourage you to think about some of these things and get your team out there. Sponsor events, bring people into your office and it will really help you build your teams.

So the next thing we want to talk about is job descriptions, which again is part of evangelizing. In a way it's part of your public message about what you do and who you are and why people should join. And it explains your culture and you're going to put it out there, you're going to put it out on social media and job postings and LinkedIn etc. You want to capture how someone can help if they were to join your mission. And they bought into your why, what would they do to contribute? And what would it take for them to be successful? Those are really the basics of a great job description plus what's in it for them? What is the call, what are the benefits what are the perks? If you cover all of those things that are just job description you've got a very compelling thing that people will find hard to resist. And again Kieran Synder from Textio will talk about some things that are critical in job descriptions later and what attracts and what repels inside of a job description to get at different talent pools. So I won't belabor that point but again it is part of how you are evangelizing yourself and putting yourself out there.

So the next thing is doing great interviews. And surprisingly, or maybe not surprisingly, people complain about interview processes a lot. If you listen to candidates, you know, internal people often tell you, "I have no idea how to interview, I don't know what to ask." People aren't consistent. So I thought I would just share with you what we've found to be very successful in doing in interviews and I think it cuts out a lot of the things that create problems.

So the first thing that you might want to look for is can people just think, can they think through a problem? And then can they think through that problem in code? That's a really important thing. And then do they have mastery, do they have mastery of anything? Have they ever mastered something in their life? If they've mastered one thing, there is a good chance they can master something else. If they have never mastered anything, there is a good chance they will never master anything that you do. Maybe that's okay, maybe it's not, just be aware of it.

Are they curious, are they a learner? Do they care about what you are doing? Do they care about your vision? Do they care about your direction? If they have no passion for what you do, they probably won't stay that long. And then the last part is do they fit with your culture? Are they willing to do things the way that you do them? I had a candidate once tell me like, "Well I didn't do so well at my last job because I didn't want to use Source Control." Well, if using Source Control is part of your culture of how you do things and they refused to do it, they are not a culture fit. So look for those things. And then standardize. If you've got a lot of different people asking a lot of different questions, which we see happen quite a lot, if you can just standardize and take variance out of that process, your decision making gets more accurate and more reliable. Even if you have different people interviewing different candidates on different days, they will get some level of consistency and you can see where a candidate ranks.

So the last thing that I want to cover is just kind of what are good interview questions. We don't have a lot of time. And really I think we can all probably agree that puzzles and brain teasers are pretty much out of fashion. Asking people how many golf balls fit in a school bus or why a manhole cover is round are probably not the best questions to really assess a candidate. But they do get at something interesting, if you do them right which is, they create a conversation about how someone thinks and approaches a problem and how do they handle when they're stuck. So again the coding interview on a white board is often maligned as well, which is that's a totally unrealistic way to write code. And in an interview setting that may not be the most important thing to assess but you want to create a conversation and the coding interview on a white board creates an opportunity to begin a dialogue about can they think? Are they willing to play with something intellectually?

I have a question I've used for years that looks like a basic simple question of sorting some numbers and then I put a few twists on them that makes it seem impossible. And so people see the question and they go, "That's not possible." But are they willing to play or do they give up? Do they demonstrate curiosity? Do they ask good questions about the boundaries of the problem? Do they want to make sure they understand it before they just jump into it? Do they immediately go back to algorithms that they learned in school and if they do that, do they actually know them? That's a big split, you see people reference algorithms they learned in school 10 years ago. And some people know exactly how they work still and other people have no idea. They may not even know the names of what the algorithm were, they just know they learned some once. That tells you something. Or do they just start fresh and they feel, "This is a new problem. I'll start from first principles and figure it out." If they get stuck, what do they do? Do they proceed to keep trying the same solution over and over again or do they generate three new alternative ideas and pursue those systematically?

It gives you great insight even though it isn't a realistic coding solution but it tells you enormous amount of how somebody interacts with you. Do you like interacting with them? Is it fun to interact with them? So I'd encourage you to focus on solutions that are, that create that level of dialogue with a candidate and of course you do want to see can they code, do they feel fluent with it? Is it simple for them? Do they struggle with basic things like syntax even though they said, they are a master of C++ and they've used it for 10 years? Incredibly revealing if done right.

And the last thing I'll just talk about is sort of Hackathons and design challenges. I think it's in terms of your candidate's experience, it's good to be wary of things that take many, many hours of a candidate's time. If you're going to interviewing 10 people to hire one position or three people to interview to fill position, that is going to be a lot of waste of time for candidates. And they may not see you in a positive light afterwards which may impact your sourcing down the road. So the more efficient and fun you can make this process for people, the better off I think you're going to be in the long run.

So let me just wrap up here with a quick summary of sort of these seven new rules. Many of you have probably been using these, or some of them, but hopefully there have been some things in here that have been helpful for you. So question hiring, look for opportunities to avoid in the first place, that makes it easier. Don't always look for all stars, ninjas, rock stars. Look for how can you piece together a team with varying skill sets. Focus on why, start with that, explain to people with why it matters. Culture is going to attract and repel people. Define your culture clearly, message it well. Take a position on things that matter, it helps people understand where they want to fit and whether they want to be part of your organization. Put this out there into your community, over time, it will pay big dividends. And then think about your interviewing process, make it better. There are a lot of ways to improve your interviews and all these things will really improve your ability to build great technical teams.

So I want to thank everyone for joining. This is the opening keynote. There are some great sessions that follow, so I hope you will stay tuned for those and have a great day.