A test when hiring Product Managers?

A quick question here, hope some of you out there can help.

When hiring, many departments have tests for their potential hires. I’ve seen this most notably in technical positions such as software development where candidates are asked to either write, debug or explain some code that is presented to them. Another common test is a writing test that is given to candidates, such as in marketing or technical writing, to see if they can actually put a few coherent paragraphs together.

Testing has it’s merits. Aside from all the individual, face-to-face questions that are asked at an interview, having someone spend 30-60 minutes (typically) writing a test can provide some interesting data.

First of all, can the person answer the questions correctly? Do they have the requisite domain knowledge you are looking for? If the test is a long one — in fact one that is intended to take more time than you allot to the candidate — it becomes quite interesting to see how the candidates manage their time.

I’ve both heard and read about companies like Google and Microsoft who give tests to potential candidates. There’s even a Wikipedia entry related to Microsoft interviews that describes some of the questions someone might be asked.

Having said all this, I’m interested in seeing if there are any specific tests that you give to product managers during the interview process, analogous to the kinds of technical tests that are routinely given to technical candidates such as software developers.

I look forward to hearing from you.



4 responses to “A test when hiring Product Managers?

  1. I have used tests when hiring product managers. The ‘test’ I used was to write a set of requirements for a feature. I sat down with the candidates for about 1/2 hour and gave them a demo of our product and then showed them the specific feature. I picked a feature that was somewhat generic so that they didn’t need a bunch of domain knowledge to complete the task. In this particular case our product had a discussion board tool and the feature was to add the ability for users to edit their own discussion posts. I gave them a simplified version of our requirements template to use, a computer and I think about 30 minutes. I told them to focus on getting the breadth of the feature documented rather than depth in any one particular area.

    Information I was able to pick up from this exercise were
    a) did they follow my instructions and get the feature fully documented in light detail or get bogged down in describing where to position the edit button and not get onto the rest
    b) The types of things they chose to focus on really illustrated their strengths and thinking. For example, were they more focused on presentation and user experience type features or on technical type features.
    c) Overall writing skills
    d) You could clearly see who had experience with detailed requirements writing & who did not

    I had a discussion with the candidate after about the document, and questioned them on why they covered certain items, and why they left out certain things. That part of the discussion was very helpful as well. I found the testing very useful, but obviously time consuming to set up and execute !

    In this particular case requirements writing was a particularly important part of the job I was hiring for and so was my area of focus but I could envision doing other kinds of tests to suit the specific needs of the role. For example under the right kind of circumstances I think a requirements prioritization type test could be effective.

  2. Chloe,

    Thanks for the feedback. Sounds like you get a lot of insight into the person’s abilities with that test. How long have you been using that kind of test?

    Have you ever encountered any problems in the tests or the test takers? e.g. refusing to take the test.


  3. I always liked to focus on a PMs ability to grasp a market opportunity. Given a hypothetical need can they walk me through estimating the size of the market, methods of distribution and how they would enter a market. It’s more about how they think then getting the right answer.

  4. Our Engineering team regularly gives candidates a coding test, but I have never given or been given a test for a PM position. My interview style includes asking candidates about specific product situations or challenges that they have overcome in the past.

    Most candidates can talk their way through hypothetical questions, so I tend to focus on what they have done in the past or what they would do differently if they could do it over (to see if they learn from mistakes or even recognize that they made a mistake). I have also asked candidates about how they might manage other products (I have picked the product and let them pick the product).

    I like the idea of giving a product demo and then having the candidate write up a requirement for a specific feature. I might try that the next time I interview a candidate.