When people talk about work, they often use language like “that sounds like a good job”, without mentioning for whom, as if the job was something that existed on its own, without someone working it. What makes a job good is that it is a good fit, a match of employer and employee. This is something that is lost not only in language, but in the job interview as well. At the very least, an interview should:

  • Allow the company to ascertain if the applicant would be successful at the job in question
  • Allow the applicant to learn about what it would be like to work at the company

The standard format for product managers - four to six one-hour one-on-one interviews with current employees - seems to do a decent job at the former. However, from my experience being interviewed, I can say that it doesn’t do particularly well at the latter.

I recently interviewed for a position as a Product Manager at a small start-up in San Francisco called Gigster. They used a different format which felt like a much more straightforward and effective way to judge a candidate. The interview consisted of two short one-on-one interviews, and then a 3-4 hour practical.

The Interviews

The night before the on-site I had a short phone call with one of the founders who described the interview process to me for the first time. He also gave me access to the company’s Git repo, slack channels, and customer feedback data. I had until the next morning to absorb as much as I could, and also sleep a little. The next day, I had a one-on-one with each founder for 30-45 minutes each. They asked mostly design based questions, e.g.:

  • What is a product you like? Describe how the UI works and how you would change it if you worked there? I picked Snapchat.
  • What are the metrics that would define the success of the Google Search Page? How could you make it better? How would it effect those metrics?
  • One of our product goals is maintaining customer satisfaction (actual question was more specific, but I don’t want to talk product specifics publicly). Here’s part of the product - does it do a good job of achieving that goal? How can we make it better?

Both founders were focused on keeping things conversational, and so we ended up discussing my experience and how it prepared me to contribute without explicitly prompting it. It would be hard to say that my one-on-one interviews at other companies were interrogations, but they definitely fall on a spectrum from friendly to adversarial. These fell firmly on the friendly side, and in doing so gave me a better opportunity to ask questions and learn more about the founders and the company. This is actually similar to some of the better one-on-one interviews I’ve had - thought the length (60-90 minutes) was much less exhausting.

The Practical

For the practical, I was given a few hours to put together a pitch on two prompts:

  • For a product area, analyze the current solution and provide a prioritized list of product improvements.
  • For that same area, pick a specific piece of the UI and design an improvement.

I actually thought the 4 hours I was given was going to be enough time to do this, but this was a little naïve. Since I hadn’t really gotten a chance to use the software too much before the practical session, I had to spend a lot of time just gathering information from customer satisfaction reports and trying out various parts of the product. I ended up not quite finishing both questions, and the visuals couldn’t have been more crude. However, I got to talk through the deck I made with the founders, and we got into a long discussion about success metrics and analysis that covered a few of the things that I couldn’t get to in my deck.

Why is this better?

I can’t really speak for the founders who interviewed me, but I felt at the very least that my ability to demonstrate my effectiveness was as high or higher in this interview format. I don’t think it is necessary for a job interview to try to emulate the day-to-day of the position, but it seemed like a really effective way to achieve the two goals I mention above - especially the second. The practical problem gave me a feeling for the day-to-day of my job unlike any interview I had done before. I got to learn what kind of problems I would be solving, and then in the review of my practical, the product thinking of the company I would be working for.

Preparing for the Practical PM Interview

So, in case you were wondering, I got the job. Here are some things I did to prepare that I thought were effective. Some of these things are not specific to the practical interview, but were helpful nonetheless.

  1. Use the product as much as possible beforehand. As well as competing products. Everything you know about the product helps make you ideate improvements faster and more confidently. Being familiar with competitors helped me understand what was unique about Gigster’s value prop and what differentiators were important to focus on in the product. Still, this is something I could have done more of. I felt familiar with Gigster and where it fit in the market, but I still wasted a lot of time in my interview poking around in the UI.

  2. Try to guess what the practical work is and do it ahead of time. I guessed that I would have to put a deck together analyzing the product. This ended up being sort of true, but the focus was less on the state of affairs and more on how to improve it. This got me thinking about the company and the product, loading my mental cache for the next day. One part that was surprisingly helpful is that it got me used to using the tools I would be using the next day. I made a few diagrams in Powerpoint and I definitely felt more comfortable with it the next day then I did the night before.

  3. Write down well thought-out descriptions of your contributions to previous products. In a lot of my interviews, I have been asked questions like “Tell me about a time when you had to make an engineering decision and how you made it”. I was not asked about my experience during my interview at Gigster. It was still useful to have these contributions at the tip of my tongue. At one point, I wanted to make the argument that was important for Gigster to make improvements that helped both their developers and their customers. I easily tied in my experience working on Windows APIs where I had the same dual mandate, helping reiterate my qualifications.

Finding a good fit

The practical interview felt like a real improvement over past interviews I have done. It was a straightforward way for me and my future employer to evaluate how I fit in the role. I’m sure there are a lot of ways you could prepare for a practical interview, but the three methods I mention above worked well for me.

The last time I started a job was in August 2010. I start work in two weeks. Wish me luck.