Jonathan Heiliger, VP Technology operations for social networking giant Facebook, has come a long way from his first hire, in his teens: "In my late teens I was working at Stanford University. I hired a student to replace me in my job as a network 'gopher' after I had worked there a few months. This was back before the Internet was commercialized. The job was pretty simple. We built routers and burned e-proms and woke up in the middle of the night to do troubleshooting for places like Apple and UC Berkeley and other large schools. We were their Internet connection. "
Today, Heiliger's challenge is to find people who understand the scale and complexity of the Facebook product, he says.
Facebook's user community has been growing rapidly, not just in terms of raw number of users but also usage on the site., Heiliger says. So the company has been hiring a 50/50 mixture of technical people who write software and build infrastructure and people for departments including business development, sales, marketing, finance, platform, and public relations, he says.
"I inherited an excellent team of about 40 people when I joined Facebook. In the last year, my team has more than doubled in size," he says. 'I have a little over 100 people in my organization and in the total company we are about 700 people."
Heiliger's responsibilities include running the infrastructure that is Facebook.com, including the server and network infrastructure that keeps the business running, plus the software and intelligence that sits on top of that, keeping the service performing well for users.
You are on a crash hiring spree. How do you avoid making mistakes when you have to move so quickly?
Everyone makes mistakes. No matter how hard you try, there will be some percentage of hiring mistakes you make. Where the management test hits metal is not just in hiring employees, but in retaining and motivating them, and in fostering some collaboration and innovation inside the company. When that does not go well, we deal with it by either helping the employee improve or helping them find a better organization to be a part of.
We try to avoid making mistakes by spending a lot of time screening candidates. We have a pretty large staff of in-house recruiters, coordinators and facilitators. We pass off all the candidates to recruiters so that employees can get back to their day jobs. We let the professionals run the process. The candidates go through the screening process and the recruiters coordinate bringing in people for interviews, figuring out if someone is a fit, selling the candidate on the company and lining them up with jobs, setting expectations, etc.] The ratios between the résumés we receive, the number of people we screen, and the number of candidates we interview is around 15 to 1 at the first step, and 10 to 1 between being screened and being interviewed, so there is a pretty big drop off.
We also depend on employee referrals quite greatly. We have been very fortunate to hire a number of great people from other companies in the Valley and even outside the Valley. We also spend a lot of time vetting people on college campuses and really trying to find people that are not just smart, intelligent and bright, but are also passionate about Facebook as a product and where we are going as a company.
One of the things we have done for new grads or people who are trying to choose between two teams is to have them join an interim team (we call it the Engineering Hiring Team) and for the first four to six weeks at the company, they report to an interim manager. They get to fix bugs, become familiar with the code base and work on a variety of teams in different parts of the organization and technology stack so that the teams can continually interview the person even after they have been hired. Then the person can figure out if they are better suited or prefer to work in one area or another. We just started that program. We do not have a lot of data on how good or bad the experience has been other than some early anecdotal feedback, which has been very positive. We will be able to retain those good 'Sathletes' by giving them those opportunities.
What is the biggest hiring mistake you have made, and what did you learn from it?
The worst hire is what is called a high beta hire, which is someone who has a lot of potential and could totally knock things out of the park or who could burn out and fail miserably. The person I hired did the latter. It was at a start up company, and things were so hectic that I was not able to spend a lot of time with this person. This person was also a manager, and there were a fair amount of unhappy people, which caused a lot of resentment in the team. The significant lesson I learned is that you want to spend time with people who are management candidates no matter how busy you are or how high up or low down you are on the ladder. To this day, I still do high beta hires for manager jobs, but now I spend 30 to 90 days in fairly intensive therapy sessions with any new manager in my organization.
What types of positions do you recruit for now and what types of people do you actually interview for the IT function?
We are hiring across the board in IT functions: software developers, infrastructure experts, program managers and product people who help define the scope and extent of the product.
What qualities do you seek in candidates for those jobs?
We need to find people who can "turn the big ship on a dime." The ship keeps getting bigger because there are more lines of code, more people using the product, more features in the product, etc. When it comes to a type of person, I am a big believer in hiring team players, but really hiring athletes-people who can play multiple positions and who have varied skills. That means you end up hiring a mix of inexperienced but bright people. I look for people who are clever. There is an adage that says "a smart person solves the problem, but a clever person prevents it from being a problem in the first place."
From the other end of the spectrum, I look for experienced people. People who have done it before, but are often set in their ways. That creates a natural tension between people who are solving a process or technology problem for the first time and want to reinvent everything, and the people who have seen the problem before and want to follow an exact pattern. Somewhere in the middle is actually the solution we want, which requires blending the two approaches. Let's not make the same mistakes we have made in the past; let's try to actually innovate and do it better, cleaner, faster for ourselves, rather than saying "We did it the HP], IBM or McKinsey way."
Are there certain candidates who just aren't a good fit with Facebook?
The lowest "hit rate" through interviewing are people who come out of large IT organizations because their mindset tends to be very reactive and process driven rather than figuring how to deliver excellence. For example, we are interviewing for a help desk manager-someone who is going to run our global help desk that services all of our employees. We have interviewed a number of people who have fantastic résumés and come out of extremely high-pedigree companies. When they interview, they say the help desk can only be run so well, that it is impossible to run a help desk 24/7 at a low cost or that it is impossible to have users satisfied with the help desk and meet these other cost objectives or time objectives. When you try to test their assumptions by asking them how they would scale a help desk to support 1,000 or 2,000 people while providing better service than the Apple Store that's across the street from our office (which is our standard for excellent customer service), people choke on that question. They cannot wrap their head around why you would want to do that or how to approach solving that problem. The people we hire have to be reasonably comfortable with the unknown and be willing to put some amount of structure around it.
How do you go about interviewing candidates for IT positions?
It varies by team across the company, and in some cases by position. We generally do one-on-one interviews; sometimes two-on-one. Panel interviews have not worked as well for us. We generally do two rounds of interviews with people. Where it is not an obvious decision, or where it's a senior position, we may go deeper than two rounds, particularly if the interviews include people from other functions.
How do you determine whether a candidate has the needed skills and will be a good fit with your IT group?
There is a set of intuitive things I go through as well as what I call a standard set of checkboxes. Unfortunately, I cannot articulate the intuitive things very well other than to say, for example, I personally look for people who are "athletes" who can play different roles. I look for people who are smart, fundamentally clever, who I want to work with, who I think I can learn from and who I think will teach others in the organization. That is a combination of culture fit, aptitude and communication style. For all these things, you can have a list of attributes. For example, we have our company values. You then look at candidates and ask how they will work in the company value of Move Fast? How will they work in the company value of Choosing Leveraged Problems? Is their frame of a leveraged problem correct or not? If it is incorrect, can you guide them through the thought process of why it is correct and get them to see that? Obviously, you only have a couple of minutes to do this in an interview, so every interviewer does not necessarily cover the entire spectrum of questions. That is why we divide it up, so different interviewers focus on different aspects of the interview process, such as technical depth, background and culture fit.
What three interview questions do you always ask and why?
In no particular order:
1. Do you use Facebook? I want to know if they use the product.
2. I ask them to dive into some technical detail on their résumé, typically from their past and maybe frame it in terms of explaining a generic problem. For example, if I am interviewing a network engineer, I will ask them to explain how TCP/IP works. If I am interviewing a developer, I will ask them to code a problem or answer a math problem or will ask an algorithm-related question.
3. I like to explore their critical thinking and analytical abilities. There are a couple of ways I do this. One is, again, using a math problem. The thousand locker problem is a great one, mostly because there was a [2 quart/3 quart problem that got very popular in a Die Hard movie<, so most people know that one. Or if I'm interviewing a product person, I will ask them to dissect the market for me. For example, I was interviewing a recruiting person who had a big brand/advertising background. I do not like asking people questions that are Facebook-specific because candidates do not have the context of Facebook that I have, so it is very difficult to gauge their capability in answering. Instead, I will ask them about the automobile industry and have them compare the brand decisions those companies made. I will ask them to walk me through what they would have done if they were in a strategy role for either of those companies. The question is not specific to Facebook or necessarily to the job, but it's very relevant to their background. I use it as common vernacular that we can both relate to.
Do you ever interview candidates for positions outside of IT, such as a finance position?
Yes, we do many cross-functional interviews here. The IT group at Facebook supports the sales, engineering and customer service organizations, so people from those teams participate in the interviews. You do not necessarily want only infrastructure people to interview an infrastructure person if they are going to have to work with the search team or the front-end team. I would argue that in any size organization, it is hugely valuable to interview people in different parts of the company because you get different perspectives. When there is a customer and vendor relationship inside the company or customer/supplier relationship, it is even more important because then the customer can feel like they participated in the hiring decision.
You have been a hiring manager in different industries. As an IT executive, do you hire differently for different industries?
Not really. Regardless of industry, I want to find people who are passionate about the product and the mission of the company. I was fortunate enough to work for Wal-Mart for a couple of years, and there were people who were passionate about retail and what the company was doing and they found themselves there, whether they were in IT or product jobs. Similarly, in high tech, I look first and foremost for people who are passionate about the company or product. Then I dive into aptitude, raw skills and experiences. Other subtle differences I look for are people who can fit into the culture, or at a young company, I look for someone who can help define the culture.
Is hiring instinctive, or can you teach people how to make good hires? Do you believe that you are an instinctive hiring manager, or that you have gotten better over the years through experience and training?
I think it is something you can train people to do, but fundamentally, it's about being able to quickly figure out people and quality. That is something that is instinctive and not trainable.
Have you changed the way you make hiring decisions since you first started hiring staff?
It has been a continued evolution and refinement. I think I am better at hiring today than I was five or 10 years ago. As you mature in the workforce as a technical or non-technical person, in particular as a manager, the best way of moving yourself forward is trying new things. Hiring is an area where I constantly try new things depending on the candidate and the situation. I even try unconventional things to see what happens because it is partially for the education of the candidate and to make them a better potential employee and also to make me a better manager and better hiring person.
Have you ever had a case where you really liked somebody you interviewed, but your team didn't? If so, did you hire that person, and did the person work out?
Absolutely. In some situations, I've hired the person, and in other situations I've not hired them. In the cases where we hired them, the argument was, Let's make this a high beta hire. Let's test this person out and see how things go. Let's monitor them closely for 90 days and see if they can pick up the slack and overcome whatever issue it is, whether they were lacking the exact right experience we were looking for or they were just culturally different.
I find the best hires are ones that are accepted by their peers. People hire people similar to them both in cultural ways and in terms of experience and aptitude. That can be both good and bad. The commonality makes the induction process and likelihood of success much higher when the team is on board with hiring a particular individual, particularly in a technical role where you have to delegate projects to them. One of the most difficult things for managers to do is to delegate their day-to-day work to people they hire. So their immediate response is to have a bar that is at least as good as they are. That becomes their hiring bar and if the candidate does not pass that, they may not hire them or be willing to delegate to them.
Do you have any pet peeves during an interview?
Not really. I am pretty easing going and willing to accept a lot things about people's interviewing styles. That being said, I am a difficult grader. I usually suggest we hire somewhere between 20 to 30 percent of the people I interview. That is a fairly high bar.
What advice can you offer candidates about their résumés, thank-you notes and cover letters?
A résumé does not have to be more than two pages to do a good job of summarizing who you are, what you stand for, and what value you are able to bring to the business. Speaking of pet peeves, having to review a 10-page résumé can be a bit cumbersome. I have seen attention drop off beyond the second or third page for most interviewers. I would ask the candidate to put themselves in the shoes of someone who is being an interviewer for that position.
In terms of follow up notes, they are always nice to see but not necessary.
What advice would you give someone interviewing with a CIO?
First and foremost, know about the company's business. Do some research. Read the company's recent press releases, understand what is going on with the company and what is being reported about the company in the press or blogosphere. Ideally, if you know the panel you are going to meet, try to do some research on them.
Personally, I like direct, high-energy interviews where answers are direct and there is not a lot of posturing when you are engaging in a discussion. I also really like interviews that are more discussion-oriented where you can instantly find a connection with the person and you have a conversation instead of a question and answer scenario, which can be dry and often leaves me wondering what the person thought about me.
Wear a helmet, prepare to get dirty and show both what you know and how you can lead a team of people. Also be presentable to the management team or board and be able to provide guidance and insight that is beyond just technology. At an Internet company like Facebook, technology is our business so we spend a lot of time talking about products and product implication to cost, whereas at a steel company, the chief information officer is there as a service function, but the chief information officer can help inform business decisions through better analytics, better systems, better tools or actually make the business run more efficiently through that same technology. Framing things in a context that both a businessperson can understand as well as a technology person is very important.
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.