#produc manager

(My personal view and approach of how to hire, may not apply to others at all; in fact I think that's not how most everyone hires at MTV/Viacom...)

Background: I have not done a survey, but will bet $1 that most interview processes in the world remain boring and unthorough for both the interviewees and the interviewers. Wordy resumes/CVs with PR like phases, series of one-on-one interviews with same type of questions, etc. don't really help me understand the true skill sets, thinking process, personality, and eagerness in most cases.  While matching and market design have long been hard problems that are tackled by very smart economists [1], fundamentally as an individual I just want to maximize my chance to find a candidate that will work out long-term by getting more "private information" so to speak...  Why?  It sounds obvious but firing the wrong person (quickly) turns out to be a very difficult task for me (and most people) to master.  The longer the wrong person is taking up payroll and "holding the seat," the longer my team can fill that seat with the right person and do great work. To avoid having to fire people, I have to learn to hire people well.

The following are my typical steps:

I) Screen: When resumes are received, I forward them to most of my team to have them vote which ones stand out. I am shocked how many places do not involve same level peers to engage deeply (if at all) in the hiring process -- they will be teammates!

II) Samples: I make the short list of candidates that literally look good on paper at this point -- I then email them each asking for a bunch of samples -- portfolios, wireframes, product documentation, sketches, etc. Whatever they can supply to show what they really produce are key. Surprisingly, I do not hear back from over 60% of the candidates consistently! It is a great way to filter out the talkers -- the remaining ones, some might take a few days/a week to send me the materials -- my gut feeling is (unless they tell me otherwise) that many people in product still do not maintain a "portfolio" like designers do. But it is a great sign that they hussle and get it done -- they want the job at least.

III) Phone: The team members look over the materials, debrief (usually just via emails), and pick the ones that we want to talk to -- we set up a few 30-minute phone screens with about 3 or more folks. note that this third step is probably the first step of hiring at most places.

IV) Presentation: If a candidate gives everyone a good first impression, we invite her/him in for a 1-hour presentation. I want to see how s/he go about thinking product problems, if s/he can lead a conversation and excel under pressure. This is *THE* main test in my opinion that helps us find the top matched candidates. Usually I give them 3 exercises to prep, so about 20 minutes each including constant disruptions by the team (of product people, as well as designers, and production/editorial folks).

The questions are along these lines:

Pick a favorite (digital) product of yours and add a feature to it.  Explain benefits to the users, to your company.  Now take away one feature and explain why.

For one of our marquee TV event shows, if budget is NOT a concern, what would you do for the upcoming show on our digital platforms (e.g., websites)?  Think out-of-the-box, think big to come up with a great and engaging user experience.

For our show X, come up with a [trendy front-end topic of the time, such as "mobile" or "responsive design"] solution that further allow our fans to engage deeper, anytime and anywhere.

I always ask the candidates before we start if they enjoyed the exercises.  So far all of them say "yes" (they seem truthful when saying it : >) and many said they prefer doing the exercises than to have more 1-on-1 sit down interviews.  It lets my team to learn how to listen and critique as well, so it's a win-win situation.  It's very similar, frankly, to how academic talks are -- speaker presents a research topic and his/her results/contributions, the audience listens and often challenges (mostly nicely, but there are heated debates as well) so everyone learns something.

V) (Optional) Mini-Hackathons: Usually, the very few people who ace step IV may just get an offer.  However, often times there are other dimensions that we want to see more out of candidates.  While the presentation is "take home" assignment and about public speaking, it doesn't fully reveal for most candidates how they might interact with various people.  For MTV it's particularly important because aside from peer product folks, we need to interact people in 7-8 departments constantly.  It simply takes a certain type of personality and approach.

In such cases, we will invite them back to do our mini-hackathons (I plan to write more about that at MTV in the near future, but in a nutshell I started a culture of having multiple people to do rapid brainstorming / low-fi prototyping/sketching / ranking ideas, etc., see d.school @ stanford [2] for these design thinking techniques).  We usually try to give them a real problem we are facing, and have them pretend they are a consultant / team member and work with a few of us (usually 3-4 top, to not overwhelm the candidate) however s/he wants -- some prefer to do lots of Q&A with those folks and talk through the approach; others (though few so far, but I would love this choice) may wanna pair smaller teams up and have them come up with different ideas.  

This process is really helpful to see how they think on their feet and how they really might do their job for real.  

Summary: Nothing really eliminates every uncertainty about candidates, but personally the above gives me enough stuff to see about and interact with the candidates.  Hiring someone is like saying "I'll find a date and propose to her in a few weeks." Nothing beats looking back 6 months after making an offer to someone that the person excels above and beyond what you expected (of course I have my own share of folks not working out).  Finally, I am not the only one who believes in these project-based hiring [3].

REFERENCE

[1] Wikipedia entry on Alvin Roth: http://en.wikipedia.org/wiki/Alvin_E._Roth

[2] d.school at Stanford: http://dschool.stanford.edu