In my work, I come across a lot of great startups. A common question I get asked is "do you know someone amazing that we can hire?" Similarly, I get pinged by many colleagues, friends, and fans who are looking to find a job with a startup. I do my best to play matchmaker, but as those of you who have ever tried to fill a job in a startup know, the most important and elusive quality for a startup hire is fit. Unfortunately, as any good recruiter will tell you, this is not an easy thing to assess as an outsider.

So I used to wind up spending a lot of fruitless hours trying to play matchmaker, and generally having a hard time. Part of the problem is that I couldn't post a public link. Most of the jobs I come across are not listed in any directory, and most of the candidates are not officially looking - many don't even have a resume. Great startups are always hiring, if the fit is right. They may not have an open req for a specific job, but if the right amazing person walks in the door, they will always find something productive for them to do.

To solve this problem, I asked a friend to collaborate with me in building a new tool. It's incredibly simple, and it's called joblink.tw. Think of it as a bit.ly for jobs. Using it to recruit takes less than a minute.

joblink.tw lets you post a description of a job without having to reveal the name of the company who is offering it, or the contact information of the hiring manager. Who wants that stuff posted on the internet? Instead, each joblink has a form that allows anyone who's interested to contact the poster. The actual exchange of information occurs in private, in email.

The same process works for job candidates. Know someone who'd make a great engineer at a startup? Just write a few words about them, set their email address as the private recipient, and tweet about it. They can turn off these contacts at any time.

To see a list of the jobs that I've posted on joblink.tw so far, take a look at my joblink profile. joblink.tw also supports oauth, so you can log in with your twitter credentials. If you do, you can have your joblinks broadcast on the joblinktw twitter account. For updates about joblink.tw or to see joblinks that others have posted, follow on twitter.

So far, this tool has saved me countless hours, and made quite a few interesting connections. That means it's accomplished all of my goals for it. If anyone else finds it useful, too, that will prove a huge plus. And if anyone has feedback, please feel free to use our integrated uservoice forum or just post a comment on this post. I'd be happy to make it better (regular readers will recognize joblink as a minimum viable product).

Read More »

This is one of those startup tips I'm a little reluctant to share, because it's been such a powerful source of competitive advantage in the companies I've worked with. But I'm going to share it anyway, because it feels like the right thing to do. Here's the short version: hire people from the online communities that develop free software. (Yes, you may be more familiar with the term open source, but let's give credit where credit is due, at least for today).

Especially for a startup, not taking maximum advantage of free software is crazy. The benefits are many and much-discussed, and so I'll mention only one in passing. It's one of the easiest ways to get leverage in your development process, amplifying the power of your team by letting you take advantage of code written by thousands of others. It's obvious that can lower your development costs, but I think it's even more important that it can reduce your time to market. It can benefit your team in other, more surprising ways as well.

This approach gives you an edge in hiring. Most of the best programmers I've known are been active in at least one free software project. It's a wonderful filter for people who are intrinsically motivated by the art of programming. Beyond the quality of the candidates themselves, I've noticed three big effects of hiring out of free software communities:

1. You can hire an expert in your own code base. I've had the good fortune to see this first-hand. I hired someone who was a key contributor to a library that was heavily used in our application. Although he didn't know much about our app when he started, he was able to be productive from day one, because we immediately put him to work extending our application's use of the library in question. He saw opportunities none of us could, because his point-of-view about what constituted "legacy code that I know well" and "third party code that some other strange people wrote" were exactly inverted from ours.
   
   
2. You can hire people who have worked together. Another unexpected benefit comes when you hire people who are part of the same online coding community. They share a common language, culture, and coding style. They have a certain amount of trust based on having been part of a common mission, and they share a passion for the project's goals. That's all helpful for recruiting, retaining, and ramping-up a new employee. You don't have to guess who their mentor will be.
   
   
3. You're not competing with every other company in town. This is especially true in Silicon Valley. The great programmers are already being headhunted by 10 other startups, and the cognitive overhead of trying to figure out which are actually unique opportunities is high. Free software contributors tend to be geographically dispersed, and so aren't part of the echo chamber. When you call, it's a more unusual occurrence, and you're more likely to get their attention.
   

If you want to successfully hire from a coding community, don't just barge in. Job posts almost never work; they're considered a form of spam. Instead, engage with the project. Submit patches. Make suggestions for how the project could be improved. Publish examples of how you use it. A surprising number of contributors to these projects have no idea how their work is used; I've often found myself in the position of being the largest single user of the software on the planet, without having ever talked to the people who wrote it. Talk about a reliable, low-maintenance vendor. This effort takes time, so this approach is not for the impatient. Still, the engagement itself is worthwhile, even if you never hire anyone. You're helping people who spend part of their lives helping you. It's basic self-interest.

Once you're part of the community, a big question is who to try and hire. As you get to know the contributors, it's evident who the real leaders are. Here's my heuristic for deciding who to approach. Ignore the famous people who are busy giving lots of speeches about how technology X will change the world. Find the person on the mailing list who patiently corrects newbies' mistakes. When someone writes in with a bad (but earnest) idea, who has the combination of in-depth knowledge and communications skills necessary to correct them without alienating them from the project? Communities that don't attract these kinds of leaders don't scale, so any successful project is bound to have some. It's worth the effort to bring them on board.

Once I've identified one of these superstars, here's what has worked for me. Approach them directly and privately. State your case plainly and be honest. I've found almost anyone will give you the time of day, if you tell them directly: "I am working on a company whose mission I profoundly believe in. We are heavy users of Project X, and are grateful to you for making that possible. Can I have a few minutes of your time?" Build up a relationship over time, find out what makes them tick, and try to make the case that your company is a great place to pursue that passion. If you're telling the truth, they'll come to see it your way eventually.

Given how many startups complain bitterly about how hard it is to find qualified programmers, I'm surprised more don't engage more fully with the people who make their technology stack possible. Try it, you just might like it. If you've never been a contributor to a free software project before, take a look at Contributing to Open Source Without Committing a Line Of Code.

Of course, if you're the target of one of these hiring calls, and not the company doing it, the perspective is pretty different. How do you evaluate a startup as a potential employer? As I promised over at Hacker News, I'll try and tackle that question in a future post. If you're interested in that topic, let me know in a comment.

Read More »

In preparing for the strategy series panel this week, I have been doing some thinking about costs. Fundamentally, lean startups do more with less, because they systematically find and eliminate waste that slows down value creation. Sounds a little abstract, though, doesn't it? I want to talk specifics, and when you come right down to it, most technology startups don't have a very interesting cost structure. Almost all of it is in one giant fixed-cost bucket: salaries. And all of that cost was caused by one activity: hiring.

Hiring is no different from any other company process. I've written previously about how to conduct a good interview, how to build a process to assess fit, and, most importantly, how to do root cause analysis to continuously improve. But hiring does have some special challenges, and today I want to talk about the one that drives almost all of the cost (and most of the mistakes): deciding when and how to hire new people.

In the startups I've been involved with, there are few mistakes I regret more than hiring too many people too soon. It's one of the hardest things to see while it's happening, and it's one of the hardest mistakes to undo, because of the human and emotional costs of layoffs. Much of what I have found effective is counter-intuitive, because it requires investing more effort in each hire - all in the name of efficiency. This can be especially challenging for HR professionals who measure their success based on the number of jobs they fill. This is another sub-optimization caused by incentivizing the wrong metric.

We should begin by clearing up one common misconception: that hiring more people means you can create more value faster. This is a variant of the time-quality-money fallacy, and it is not necessarily true. There are two complicating factors. One, which is described in great detail in the Mythical Man-Month (in finding that link, I discovered that today is coincidentally the exact 11th anniversary of my first purchasing that book: Jan 19, 1998), is that as you add people to a team or project, there is an increase in communications overhead that makes everyone slightly less productive. Second, a lot of work that you do is actually not value-creating - it's waste. Hiring people to do more of that kind of work can actually slow down your whole company. In fact, unless you are adding capacity to a bottleneck in your development process, you probably should not be hiring at all. For more detail on this second point, I recommend The Goal: A Process of Ongoing Improvement.

In any event, in order to hire effectively, you have to have a strong understanding if what the unit of progress is for your company. For additional thoughts on that topic, see
Lean startups vs lean companies.

When to hire
Let's start with deciding when to add a new job to the payroll. Here's my suggestion: don't hire for any job unless you have tried, and failed, to do it yourself. There are lots of bottlenecks in any company, but only a few of them actually are on the critical path of a startup's success. For example, let's say you don't have an operations team, and so you're still getting paged late at night when servers crash. Is it time to make your first operations hire? That depends. If you're coming in to work groggy and therefore are not spending time with customers, I'm willing to bet it is. But if it's just an inconvenience, then you should focus on figuring out how to mitigate the pain rather than hire to alleviate it.

The main drawback of this approach is that most people in most startups are already too busy. As a mentor of mine always says, "Startups don't starve, they drown." If you're already too busy, how can you afford to take on yet another job? Wouldn't it be faster to just hire a new person and delegate to them? Not in my experience. If you hire a smart, competent person, they will inevitably find ways to be productive and keep busy. But you still won't know if the work they are doing is on the critical path. They may be dong good work, but you must be able to evaluate its contribution to the company's overall success to know if you've made a hiring mistake or not. If you've done the job yourself, you'll know that it's important and you'll know what success looks like. Oftentimes, in my experience, you'll realize that you don't need to hire for it at all.

Insisting that someone inside the company take on every new job has other benefits, too. It's a way of making necessity the mother of invention, and taking advantage of your limited resources to help the company decide not to do things it doesn't need to do. This tool is often hidden in plain sight. I didn't truly appreciate its power until I saw how larger startups can lose it if they're not careful. Having too few people forces companies to focus on working smarter and eliminating unnecessary projects.

Hiring experts
In many situations, the goal of hiring is to bring in expertise that the team doesn't already have. This might seem like another time where delegating makes sense, but again I recommend trying to have an existing person take on the job. In fact, I recommend putting one of your best people on the new job, even though that's especially painful. In my experience, having a generalist try to emulate an expert's job will result in three possible outcomes:

1. The person will fail. This may seem wasteful, but it's actually very valuable. Having a star performer attempt it will give the expert you eventually hire built-in credibility. You'll also have someone on staff who understands the problem, and can help the newcomer get integrated into the team faster.
   
   
2. The person will succeed, and it will matter. In this case, you now have an expert on staff already. This gives you the option to still hire an true expert, or to back-fill the person who has taken on the new job. In fact, in many situations, you'll actually find that the job is not as big as you thought, and you don't need to hire anybody. Or the person you get to do it will know how to invest in infrastructure that makes one of their many jobs automatic - this is one of the advantages of hiring smart people and building a culture of continuous improvement.
   
   
3. The person will succeed, and it won't matter. This is surprisingly common, and is the greatest savings of all. In many situations, people invest experts with wished-for magic powers, thinking they will "solve all our problems" even when that's not realistic. By having an in-house person succeed, you can evaluate whether having an expert on staff is really shortening the critical path of your organization's success. If not, you can avoid making the hire with confidence.

Returning to our example of the beleaguered founder who still has the pager, before hiring an operations guy, try promoting someone from within to take on the job. If you find yourself now spending time with customers, learning and guiding the learning of your whole company, you were probably right that the pager was getting in the way. But, if you find yourself getting caught up in some other distraction, and not really adding value, then the pager was a red herring. You need to get your priorities straight and, until you do, you probably may as well carry the pager too.


Relentlessly pursue passive candidates
Once they've decided to make a hire, startups should specialize in hiring candidates who are not actively looking for a job. This requires dramatically more work than hiring active candidates, but it usually generates positive returns.

The best candidates are those you (or someone on your team) have worked with before. Hiring them has substantial benefits over strangers: lower risk (because you know their strengths and weaknesses ahead of time), faster team integration (because they know someone already and that person can mentor them), and lower communication overhead (because they are more likely to speak and undersatnd a common language).

Most companies I work with think they are already pursuing these already-known passive candidates. I disagree. I am willing to bet that, right now, you can think of at least one person who is not working at your company who is an absolute star at what they do. Even if you have a referral bonus program, even if you've talked to that person about your company, and even if you've sent a recruiter to call her, I bet you could do more. Ask yourself this question: have you really made that person an offer they can't refuse? No Godfather-type violence is required. Telling someone "I really believe you can change the course of my company's life, and I'm willing to do whatever it takes to get you on board" is surprisingly powerful. Every person who you could make that offer to but haven't is a lost opportunity. Multiply that across everyone in your organization, and every superstar they know, and that's a huge potential pool of talent.

Even passive candidates that you don't already know have advantages that make them worth pursuing. You learn much more from trying to convince them to join, because they are more likely to ask you tough questions. You want people to turn you down if your pitch is bad, so you have more opportunities to learn how to get better (and is it possible that the problem isn't just with your pitch?). Given that most recruiting channels are pay-for-performance, it's usually cheaper, too, because it has a lower conversion rate. If you want to expand your pool of available passive candidates, give a site like NotchUp a try. They maintain a huge database of passive candidates, by offering to pay them when they interview. Again, by requiring you to invest more in each candidate you see, you learn to be much more careful about talking to the right people, and more focused on closing those candidates. (They also have a pay-for-performance model that's much cheaper than your typical contingency recruiter.)



Hiring well requires a lot of introspection in order to do it well. You have to really understand your company and what it needs. You need to be able to communicate the value your company creates to others. And you need to be able to ask yourself the tough questions to continue to refine your hiring process as you scale. But in lean times like these, I don't see any real alternative.
Read More »

When I wrote earlier about how to conduct a good technical interview, I had only a few things to say about how to assess if the candidate fits in with the team, including this:

This responsibility falls squarely to the hiring manager. You need to have a point of view about how to put together a coherent team, and how a potential candidate fits into that plan. Does the candidate have enough of a common language with the existing team (and with you) that you'll be able to learn from each other? Do they have a background that provides some novel approaches? Does their personality bring something new?

A few commenters have taken issue with the idea that it's solely the hiring manager's responsibility to assess fit, arguing correctly that the whole team should participate in the evaluation and decision. I completely agree. Still, I do think fit is a quality that requires special treatment, because it is the hardest attribute to evaluate.

Unlike the other attributes we look for in an interview candidate (like drive, brains or empathy) fit is not an individual quality. It's caught up in group dynamics. Worse, it has a self-referential quality to it. The very team that is making the assessment is being asked to assess itself at the same time as the candidate. How else can they tell whether the new team that will be created by the addition of this person will be superior to the team as it is presently constituted?

I have found James Surowiecki's book The Wisdom of Crowds particularly helpful in thinking through these issues. This book is Tipping Point-esque, full of anecdotes and interesting social science citations. Its central thesis is that, under the right circumstances, groups of people can be smarter than even their smartest single member. I find his observations compelling, and I feel good recommending the book to you, even though I know there are many among us who find "argument-by-anecdote" irritating. You don't have to buy the argument, but the facts and citations are worth the price of admission.

Let me briefly summarize the part of the book I find most helpful (leaving a few out, which aren't germane to today's topic). Not all crowds are wise. In order to get optimal results from a group-based effort, you need three things: diversity, Independence, and an objective method for aggregating results. For example, we conduct elections with a secret ballot, which ensures Independence (since nobody can directly influence your vote); we let everyone vote, which ensures diversity (since even extreme opinions can be heard); and we use a numerical count of the results (which, recent experiences notwithstanding, is supposed to mean that everyone's vote counts equally according to an objective formula). Similar mechanisms are at work in the stock market, Google PageRank, and guessing an ox's weight at the state fair.

Remove any of these essential ingredients, and you can find examples of groups gone bad: the Bay of Pigs invasion fiasco, market bubbles, and pretty much every one of Dilbert's team meetings.

Anyway, back to fit. Surowiecki has helped me in two ways:

1. Assessing fit in the context of what makes a good team. In order to improve the performance of a team, it's not enough just to keep adding smart people. You actually need to find a diverse set of people whose strengths and weaknesses complement each other. The problem most teams have with fit, in my experience, is they confuse it with liking. Many great engineers I've worked with (especially the type I talked about in the hacker's lament) seem to think that if they get along well with someone in an interview, they'll be a good addition to the team. This kind of homogeneity can lead to groupthink.
   
   
2. Putting together a process for helping a team assess fit. Another dangerous group dynamic in fit questions is that people are very sensitive to the opinions of their peers when talking about the group itself. In order to make an informed decision, the team needs a process of gathering and combining their opinions without having anyone's voice stifled.
   

For example, let's say you are on a team that prides itself in its all-hands-on-deck-at-all-hours style of working. There are a lot of great teams that work this way, preferring a series of sprints and lulls to a steady pace. Now let's say you're interviewing someone who doesn't seem to like to work that way. They work steady hours, but not for lack of drive; their references say they have exceptional output. Now picture the group meeting to talk about this prospective candidate. First up, the alpha-hacker on the team says something like "we should pass, this candidate is lazy."

Now it's your turn. Even if you are convinced that this candidate would make a great addition to the team, how much courage does it take to say so? You might convince the group, but you might not. And if you don't, will it raise suspicion about how dedicated you are? Will you be implicitly calling into question the validity of the team's values? Will they then be watching you for signs of laziness in the future? What about that vacation you've been planning to take... and so on. In my experience, there are plenty of situations where dissenting voices simply opt out. There's a clear danger to speaking up, but a pretty murky benefit.

If you find this line of reasoning confusing (nobody on my team feels that way) or paranoid (let's just all be rational), you may be surprised what the other people in the room are thinking. Take a look at some of the social science research in this area, like the Asch conformity experiments. In those, a group of people are asked to answer a simple question about their observations, one at a time. The first few people are actually actors, and they all give the same patently false answer. The experiment measures the likelihood that the last person in the sequence, the real experimental subject, will conform to what the previous people have said, or dissent. Even though the answer is obvious, and the other people in the room are all strangers, a surprising number of people choose to conform. I have found the pressure is much higher in situations where the answer is unclear, and the other group members are coworkers.

Combating these tendencies is the real job of the hiring manager. If that's you (or you are on a team whose hiring manager abdicates that responsibility), here are three suggestions that have worked for me to take advantage of the wisdom of crowds in hiring. Each of these are based in changes I've made to my hiring process in response to five whys analysis of previous hiring mistakes.

• Before you meet the candidate, spend time thinking about the strengths and weaknesses of your team. Try to brainstorm some archetypes that probably would interview badly but actually be successful in filling out your team. Having been through this exercise in advance can help you listen carefully to what team members say about the candidate, and see if their objections are simply fearing what is different, or if they have a more serious concern.
  
  One experience I had was with a candidate who was absolutely convinced that our development methodology wouldn't work. He spent an inordinate amount of time grilling us on exactly how we work and why, asking smart but tough questions. He made us nervous, but we took a risk and hired him anyway. After we hired him, he spent weeks driving the team crazy with his critical (but, we had to admit, accurate) eye. Then, all of the sudden, a remarkable thing happened. Another new hire started to complain about the way we worked. Our former critic promptly set him straight, shooting down his complaints with the same ruthless efficiency he had previously devoted to analyzing our work. He had been converted, and from that point on acted as "defender of the faith" far better than I ever could.
  

• Maintain strict Independence for each interviewer. Our rule was always that each interviewer was not allowed to talk any other interviewer once their session was concluded. The first time we'd exchange any words at all was during the end of the day assessment meeting. This prevents a previous interview from biasing a later interview. For example, I've seen situations where even a positive comment, like "wow, that candidate is smart!" cause disaster. The next interviewer, armed with an expectation of brilliance, chooses harder questions or becomes disappointed by an "only above average" performance.
  
  
• Aggregate results carefully. When sitting in a room talking about the candidate, I have had success with two precautions. First, we would always share our experiences in reverse-seniority order. That meant that the most junior person would be forced to speak first, without knowing anything about what his or her manager thought. As the hiring manager, I would speak last, and I'd do my best to avoid giving any indication in advance of what I thought.
  
  We'd also have a structured discussion in two parts: in the first part, each person talks only objectively about what happened in the interview, without giving opinions or passing judgment. Others are allowed to ask "clarifying questions" only - no leading questions or comments. Only in the second round does each person give their opinion about whether to hire the person or not. This helps get the facts on the table in an objective way. If our team had ever struggled to do it, I would have insisted on written comments shared anonymously. In other words: do whatever you have to do to get an objective discussion going.

If you've been the victim of groupthink in hiring, or have suggestions for ways to avoid it, please share. All of us are team members, family members, coworkers and leaders. Tell us what you've learned in those different contexts. Maybe it'll help someone else avoid the same mistakes.

Read More »

I am incredibly proud of the people I have hired over the course of my career. Finding great engineers is hard; figuring out who's good is even harder. The most important step in evaluating a candidate is conducting a good technical interview. If done right, a programming interview serves two purposes simultaneously. On the one hand, it gives you insight into what kind of employee the candidate might be. But it also is your first exercise in impressing them with the values your company holds. This second objective plays no small part in allowing you to hire the best.

Balancing competing objectives is a recurring theme on this blog - it's the central challenge of all management decisions. Hiring decisions are among the most difficult, and the most critical. The technical interview is at the heart of these challenges when building a product development team, and so I thought it deserved an entire post on its own.

In this post I'll follow what seems to be a pattern for me: lay out a theory of what characterizes a good interview, and then talk practically about how to conduct one.

When I train someone to participate in a technical interview, the primary topic is what we're looking for in a good candidate. I have spent so much time trying to explain these attributes, that I even have a gimmicky mnemonic for remembering them. The six key attributes spell ABCDEF:

• Agility. By far the most important thing you want to hire for in a startup is the ability to handle the unexpected. Most normal people have a fairly narrow comfort zone, where they excel in their trained specialty. Those people also tend to go crazy in a startup. Now, we're not looking for people who thrive on chaos or, worse, causes chaos. We want someone who is a strong lateral thinker, who can apply what they've learned to new situations, and who can un-learn skills that were useful in a different context but are lethal in a new one. When talking about their past experience, candidates with agility will know why they did what they did in a given situation. Beware anyone who talks too much about "best practices" - if they believe that there are practices that are ideally suited to all situations, they may lack adaptability.
  
  To probe for agility, you have to ask the candidate questions involving something that they know little about.
  
  
• Brains. There's no getting around the fact that at least part of what you should screen for is raw intelligence. Smart people tend to want to work with smart people, so it's become almost a cliche that you want to keep the bar as high as you can for as long as you can. Microsoft famously uses brainteasers and puzzles as a sort of quasi-IQ test, but I find this technique difficult to train people in and apply consistently. I much prefer a hands-on problem-solving excercise, in a related discipline to the job they are applying for. For software engineers, I think this absolutely has to be a programming problem solved on a whiteboard. You learn so much about how someone thinks by looking at code you know they've written, that it's worth all the inconvenience of having to write, analyze and debug it by hand.
  
  I prefer to test this with a question about the fundamentals. The best candidates have managed to teach me something about a topic I thought I already knew a lot about.
  
  
• Communication. The "lone wolf" superstar is usually a disaster in a team context, and startups are all about teams. We have to find candidates that can engage in dialog, learning from the people around them and helping find solutions to tricky problems.
  
  Everything you do in an interview will tell you something about how the candidate communicates. To probe this deeply, ask them a question in their area of expertise. See if they can explain complex concepts to a novice. If they can't, how is the company going to benefit from their brilliance?
  
  
• Drive. I have most been burned by hiring candidates that had incredible talents, but lacked the passion to actually bring them to work every day. You need to ask: 1) does the person care about what they work on? and 2) can they get excited about what your company does? For a marketing job, for example, it's reasonable to expect that a candidate will have done their homework and used your product (maybe even talked to your customers) before coming in. I have found this quite rare in engineers. At IMVU, most of them thought our product was ridiculous at best; hopeless at worst. That's fine for the start of their interview process. But if we haven't managed to get them fired up about our company mission by the end of the day, it's unlikely they are going to make a meaningful contribution.
  
  To test for drive, ask about something extreme, like a past failure or a peak experience. They should be able to tell a good story about what went wrong and why.
  
  Alternately, ask about something controversial. I remember once being asked in a Microsoft group interview (and dinner) about the ActiveX security model. At the time, I was a die-heard Java zealot. I remember answering "What security model?" and going into a long diatribe about how insecure the ActiveX architecture was compared to Java's pristine sandbox. At first, I thought I was doing well. Later, the other candidates at the table were aghast - didn't I know who I was talking to?! Turns out, I had been lecturing the creator of the ActiveX security model. He was perfectly polite, not defensive at all, which was why I had no idea what was going on. Then I thought I was toast. Later, I got the job. Turns out, he didn't care that I disagreed with him, only that I had an opinion and wasn't afraid to defend it. Much later, I realized another thing. He wasn't defensive because, as it turns out, he was right and I was completely wrong (Java's sandbox model looked good on paper but its restrictions greatly retarded its adoption by actual developers).
  
  
• Empathy. Just as you need to know a candidates IQ, you also have to know their EQ. Many of us engineers are strong introverts, without fantastic people skills. That's OK, we're not trying to hire a therapist. Still, a startup product development team is a service organization. We're there to serve customers direclty, as well as all of the other functions of the company. This is impossible if our technologists consider the other types of people in the company idiots, and treat them that way. I have sometimes seen technical teams that have their own "cave" that others are afraid to enter. That makes cross-functiona teamwork nearly impossible.
  
  To test for empathy, I always make sure that engineers have one or two interviews with people of wildly different background, like a member of our production art department. If they can treat them with respect, it's that much less likely we'll wind up with a silo'd organization.
  
  
• Fit. The last and most elusive quality is how well the candidate fits in with the team you're hiring them into. I hear a lot of talk about fit, but also a lot of misunderstandings. Fit can wind up being an excuse for homogeneity, which is lethal. When everyone in the room thinks the same way and has the same background, teams tend to drink the proverbial Kool-Aid. The best teams have just the right balance of common background and diverse opinions, which I have found true in my experience and repeatedly validated in social science research (you can read a decent summary in The Wisdom of Crowds).
  
  This responsibility falls squarely to the hiring manager. You need to have a point of view about how to put together a coherent team, and how a potential candidate fits into that plan. Does the candidate have enough of a common language with the existing team (and with you) that you'll be able to learn from each other? Do they have a background that provides some novel approaches? Does their personality bring something new?
  

It's nearly impossible to get a good read on all six attributes in a single interview, so it's important to design an interview process that will give you a good sampling of data to look at. Exactly how to structure that process is a topic for another day, however, because I want to focus on the interview itself.

My technique is to structure a technical interview around an in-depth programming and problem-solving exercise. If it doesn't require a whiteboard, it doesn't count. You can use a new question each time, but I prefer to stick with a small number of questions that you can really get to know well. Over time, it becomes easier to calibrate a good answer if you've seen many people attempt it.

For the past couple of years I've used a question that I once was asked in an interview, in which you have the candidate produce an algorithm for drawing a circle on a pixel grid. As they optimize their solution, they eventually wind up deriving Bresenham's circle algorithm. I don't mind revealing that this is the question I ask, because knowing that ahead of time, or knowing the algorithm itself, confers no advantage to potential candidates.

That's because I'm not interviewing for the right answer to the questions I ask. Instead, I want to see how the candidate thinks on their feet, and whether they can engage in collaborative problem solving with me. So I always frame interview questions as if we were solving a real-life problem, even if the rules are a little far-fetched. For circle-drawing, I'll sometimes ask candidates to imagine that we are building a portable circle-drawing device with a black and white screen and low-power CPU. Then I'll act as their "product manager" who can answer questions about what customers think, as well as their combined compiler, interactive debugger, and QA tester.

You learn a lot from how interested a candidate is in why they are being asked to solve a particular problem. How do they know when they're done? What kind of solution is good enough? Do they get regular feedback as they go, or do they prefer to think, think, think and then dazzle with the big reveal?

My experience is that candidates who "know" the right answer do substantially worse than candidates who know nothing of the field. That's because they spend so much time trying to remember the final solution, instead of working on the problem together. Those candidates have a tendency to tell others that they know the answer when they only suspect that they do. In a real-world situation, they tend to wind up without credibility or forced to resort to bullying.

No matter what question you're asking, make sure it has sufficient depth that you can ask a lot of follow-ups, but that it has a first iteration that's very simple. An amazing number of candidates cannot follow the instruction to Do the Simplest Thing That Could Possibly Work. Some questions have a natural escalation path (like working through the standard operations on a linked-list) and others require some more creativity.

For example, I would often ask a candidate to explain to me how the C code they are writing on the whiteboard would be rendered into assembly by the compiler. There is almost no earthly reason that someone should know about this already, so candidates answer in a wide variety of ways: some have no idea, others make something up; some have the insight to ask questions like "what kind of processor does this run on?" or "what compiler are we using?" And some just write the assembly down like it's a perfectly normal question. Any of these answers can work, and depending on what they choose, it usually makes sense to keep probing along these lines: which operations are the most expensive? what happens if we have a pipelined architecture?

Eventually, either the candidate just doesn't know, or they wind up teaching you something new. Either way, you'll learn something important. There are varying degrees of not-knowing, too.

1. Doesn't know, but can figure it out. When you start to probe the edges of someone's real skills, they will start to say "I don't know" and then proceed to reason out the answer, if you give them time. This is usually what you get when you as about big-O notation, for instance. They learned about it some time ago, don't remember all the specifics, but have a decent intuition that n-squared is worse than log-n.
   
   
2. Doesn't know, but can deduce it given the key principles. Most people, for example, don't know exactly how your typical C++ compiler lays out objects in memory. But that's usually because most people don't know anything about how compilers work, or how objects work in C++. If you fill them in on the basic rules, can they reason with them? Can those insights change the code you're trying to get them to write?
   
   
3. Doesn't understand the question. Most questions require a surprising amount of context to answer. It doesn't do you any good to beat someone up by forcing them through terrain that's too far afield from their actual area of expertise. For example, I wold often work the circle-drawing question with candidates who only had ever programmed in a web-based scripting language like PHP. Some of them could roll with the punches and still figure out the algorithmic aspects of the answer. But it was normally useless to probe into the inner workings of the CPU, because it wasn't something they knew about, and it can't really be taught in less than a few hours. You might decide that this knowledge is critical for the job you're hiring for, and that's fine. But it's disrepectful and inefficnet to waste the candidate's time. Move on.
   

My purpose in elaborating these degrees of not-knowingness is to emphasize this essential point: you want to keep as much of the interview split between boxes one and two. In other words, you want to keep asking questions on the boundaries of what they know. That's the only way to probe for agility, brains, and the best way to probe for communication. In the real world, the vast majority of time (especially in startups) is spent encountering novel situations without a clear answer. What matters is how good your thinking is at times like those, and how well you can communicate it. (It's kind of like playing Fischer Random Chess, where memorizing openings is useless).

Let me return to my topic at the top of the post: using the interview to emphasize values as well as evaluate. The best interviews involve both the interviewer and the canddiate learning something they didn't know before. Making clear that your startup doesn't have all the answers, but that your whole team pushes their abilities to their limits to find them is a pretty compelling pitch. Best of all, it's something you just can't fake. If you go into an interview with the intention of lording your knowledge over a candidate, showing them how smart you are, they can tell. And if you ask questions but don't really listen to the answers, it's all-too-obvious. Instead, dive deep into a problem and, together, wrestle the solution to the ground.

Read More »