Disclaimer: The process outlined in this post reflects my personal approach. Please consider this as a helpful insight into what it takes to get a hiring recommendation from me. As always the law and corporate policy applies.

This post has three purposes. First, to save me the need to explain every time how I interview and hire people. Second, to inspire others to break away from the conventional and ineffective hiring process most companies use. It’s a process that fails to identify non-conforming great talent. And third, when the time comes for me to look for my next adventure, I can point hiring managers here to know how I’d like to be treated.

TL;DR

If you don’t have time to read this, we are not a good fit.

What Not to Do

In 2006 I was looking for a new job on Wall Street. I wasn’t happy at my job, but not yet ready to do my own startup. At the time I was a VP of engineering at Citi managing about 35 people. I was looking for a similar role with a smaller team and more hands-on opportunities. I was not looking for a primarily coding role. I got invited to interview with Credit Swiss for a lead role. When my first interviewer spent half an hour asking me about the order of initialization of static variable in C++, I played along. But when the second guy came in, put a laptop in front of me and said “We’re going to write some code now”, I got up and said “I’m going home now”. I didn’t get that job.

Later that year, I had an interview at Bloomberg. The interviewer greeted me at the entrance, then purposely walked me through their showy floors and world-famous curved escalator as if that’s going to motivate me. We’ve spent the first 10 minutes going over my financial products experience and then followed with 20 minutes asking me questions specifically about everything I just said I don’t have experience with. The next interviewer asked me about my coding experience which at the time was all C++, then followed up with only C questions. The last interviewer asked a riddle (“4 members of U2 are trying to cross a bridge”) which I’ve spend the entire half hour passive-aggressively not trying to solve. I didn’t get that job.

In 2009 I was approached by Google at the recommendation of some people I collaborated with. The conversation didn’t go very far when they made it clear that they will not be able to tell me what I will be working on, and more importantly, who I will be working with and for, until I start. I had serious doubts about passing their interview process, or even fitting in at Google, but I was willing to give it a try. What I wasn’t willing to do is consider a job where the only known parameter is the name of the company. I didn’t get that job.

I’m purposely focusing on companies that got it all wrong. This is not at all about settling scores. Over the years I’ve interviewed at companies like Twitter and Facebook, which resulted in offers I turned down, and companies like Mozilla and LinkedIn which did not result in offers. The point is, I don’t judge the quality of the hiring process based on my personal experience or whether an offer was extended.

I judge it based on how much I enjoyed the process and respected the people on the other side.

I – Screening

The key to a successful hiring process is a good screening filter. I look for at least one of three things when considering engaging a candidate:

• a record of open source, standards, or other public work,
• a recommendation from someone I respect, or
• a cold call with an attitude

I don’t phone screen. I don’t read resumes.

The first two are self-explanatory but apparently not obvious. Too many people rely on their resume for engineering roles. I don’t care about your resume. What I’m looking for is code to look at, specifications to read, or products to play with. Nothing showcases your skills better than actual code, especially code written to satisfy your own standards and not an employer.

Without a public record or a recommendation, I’m not likely to have much interest. Which means, you need to find a way to get my attention. Sending a one line email (or a tweet) asking for more information is not going to accomplish much. I’m looking for some attitude. If you want me to spend time learning about you without having easy access to a sample of your work, you need to make it fun for me.

The obvious ways are to engage me on something I care about. Google me – it’s not hard to figure it out. Send me comments about a blog post or an open source project I published. Tell my why I’m wrong, why my project sucks, how I can make it better, or why you want to work with me. If you put an effort into it, I will do the same.

II – Greeting

Great, you got my attention. Now I am going to get yours.

Engineers are most comfortable talking to other engineers. It is always frustrating when looking for a job feels like looking for a date. We should strive not to turn the interview process into the rules of dating, making candidates think about how “needy” they might look or being afraid of asking questions that can make them look bad.

To address that, we start by assigning the candidate a buddy. This is a member of the same team the candidate is being interview for, who is not part of the decision making process. The buddy’s role is to guide the candidate through the process, offer intentionally biased opinions, relay questions, and in general be a contact person the candidate should never feel bad about reaching to. Your buddy will never fill a form saying you “seem needy”.

Our first call or meeting is going to be all about you. My job is to sell you the company, the team, and the role. The sole purpose of our first interaction is to make you want the job. To give you all the information you need to make an educated decision. After all, in the next step I’m going to make you work for it, so it’s only fair you have all the information you need before I waste your time.

III – Homework

If you made it here, it means your background is exactly what we want, and this is the job you are looking for. Now let’s write some code!

I suck at writing code on demand. I can’t really code outside my controlled environment. I got my chair, and desk, and big monitor, and IDE, and color scheme, and… you get the idea. I also do my best work when I get to “sleep on” a problem. Some people are great at writing code on a whiteboard. It’s a great interview skill to have. It’s also an idiotic skill to test for. I am also not a fan of pair programming which would be the only valid reason to live code during an interview. So no live coding.

Instead, I will present you with a few problems the team is working on right now. I’m not going to make shit up. These are all actual problems we need to solve or have solved recently. The advantages are many: you get to experience what the job is really like and we get to work with you on a problem we have been looking at recently. More often than not, these are pending items that we have not solved yet. Looking at our open issues on GitHub is a great way to get an idea what you might be tasked with.

The guidelines are simply – pick a problem and come back with something that best showcases your abilities. It can be code, a pull request, a written proposal, or an email analysis. Whatever you feel is the best way for you to shine. You can use any resources you want – the web, books, friends. You know, just like you do at work. To get an idea what past hires submitted, check out some of these proposals (some are actual answers from interviews posted with permission after a successful hire).

You also get as much time as you want. There is no deadline.

There is only one catch. Once you send your response back, we’re going to chat about it. We’ll challenge your analysis, your assumptions, your solution. We’ll try to put sticks in your wheels, introducing new constraints or share our experience if we already tried that. In other words, we’ll have an educated discussion about the problem, now that you had as much time as needed to study it. No surprises.

The homework follow up can be a 30m phone chat or part of the in-person interview. It mostly depends on your location, availability, and how blown away we are with your submission. On occasion we are left speechless.

Funny story. during my time at Citi, leading a C++ shop, I gave this homework to people: “Build a car in C++”. Most people created a set of classes and put them together to construct a car object with some methods and state. One guy sent this (actual submission!):

class Car {

private:

  void top () {
    printf("                         ________________________");
    printf("                        /             |          \");
    printf("                       /              |           \");
    printf("                      /               |            \");
    printf("                     /                |             \");
    printf("                    /                 |              \");
    printf("                   /                  |               \");
    printf("                  /___________________|________________\__________");
    printf("     ____________/                                                \");
    printf("    /                                                              \");
    printf("   /                                                                \");
  };

  void bottom () {
    printf("  /                                                                  |");
    printf(" /        ,---------,                     ,-----------,              |=====");
    printf("|        /  ______   \                   /   ________  \             |=====");
    printf("|       /  /         \                 /   /        \  \___________/");
    printf(" \_____/  /           \_______________/   /          \");
    printf("         /          |                     |            |");
    printf("        |           |                     |            |");
    printf("        |          /                      \           /");
    printf("        \         /                        \         /");
    printf("         \_______/                          \_______/");
  };

public:

  void drive () {
    top();
    bottom();
  };
};

Needless to say, he was invited for an interview. He didn’t show.

IV – Interview

The goal of the in-person interview is to evaluate the following areas:

• Cultural fit – are you going to be a good addition to the team and work well with others? Will we enjoy working with you? Will we want to go to a conference with you? Also, as a team with remote members, evaluate your compatibility with our style and process.
• Adaptability – we work in a mixed environment where we have control over our systems but little control over the services we consume. Working in this environment, with many legacy systems isn’t for everyone.
• Passion – everyone should have something they are passionate about. What are you? We’ll try to find yours and chat about it a bit. It doesn’t have to be super relevant. The goal is to see how deep you dive into topics that excite you. My 2 hours interview at Yahoo! included an hour discussion about water gardens. It was awesome.

The on-site interview is usually 2-3 hours long with 3-5 team members. I usually ask each interviewer to focus on one of the areas above. I also provide them with the following list of do’s and don’ts.

The DOs:

• Know what you are interviewing for (you’d be surprised).
• Begin the interview describing your role in the team and allow the candidate to ask questions.
• Ask questions based on actual team experience.
• Focus on architecture, design, and approach to problems more than the fine details of the solution.
• Let the candidate explain the process if their answer isn’t what you were expecting – a wrong answer can still demonstrate solid thought process.
• Any coding question must be a follow up on the homework submitted.
• Make it fun. Find ways to make the candidate feel at ease and enjoy the conversation.
• Leave at least 5 minutes at the end for them to ask questions and unwind. Ending poorly sets the tone for the next interview.
• Offer them a drink or a restroom break.

The DON’Ts:

• Don’t ask those who interviewed the candidate before you what they think. Form your own first impression.
• No whiteboard coding or any live coding during the interview. Some people do well coding on the fly, most don’t. It is not a skill we care about. It also takes too much time that is better spent talking.
• No riddles, logic, trick questions, or puzzles. This is not the SAT.
• Don’t ask questions about stuff they claim not to know. This should be obvious but sadly its not to some people. Ask them about what they know and claim to be proficient in.
• Talk, don’t interrogate.
• Don’t read their resume during the interview. In fact, don’t bring their resume to the interview at all. If you did not read it ahead, focus more about technology in general and our work. It is obvious when someone is interviewing you who has no clue who you are.
• Don’t ask one long question in multiple parts. If they get the first part wrong, it sets a bad tone for the rest of the interview. Give them a chance to reset and start over with another topic. Ask and move on – don’t get stuck on getting them to reach the right answer.

V – Decision

That’s it. We meet as a team and get everyone’s feedback. We should have an answer the following day.

Final Thoughts

Like most people, I don’t like going to interviews where I don’t know the team and I am asked to “perform”. The interview should adapt to your level. Architects should not be asked to solve short algorithms, the same way managers should not be asked to write code. Your references and past work is what we should really rely on for verifying your claims. The interview is mostly about personality, compatibility, and due diligence.

A job interview goes both ways. We interview you, and you interview us. We want great talent and respect is the first step.