How do you interview API product managers?

Good API Product Managers are hard to find. As a VP of Product, I’ve interviewed hundreds. Here are the questions I ask for a mid-level position, let’s say a Senior API PM:

Let me start out by saying all the great API PMs I’ve worked with have had a technical background. They were either engineers by training or had previous engineering experience. I’m not saying it’s impossible to do the job without it, but here’s why it’s good to have:

a. Your customers and users are all developers, so you’ll need to have the technical chops to speak to them and understand their problems

b. Requirements will be very technical in nature; you’ll need to talk to your delivery team on that level and gain their trust.

For this writeup I’ll skip the basic questions I ask when I start the interview around their work experience and Product Management: what products they worked on, who is the user or what problem the product solves. I’ll usually start with these and then will jump into PM skills like prioritization, stakeholder management, customer conversations & discovery, interface with Sales & Marketing etc.

There are many sources out there on non-API PM interviews, but hit me up in the comments on the original LinkedIn post for links or if you think I should a do post focusing on that.

I find these are topics that candidates prepare for and it’s a good way to break the ice and get a conversation going.

I’ll spend first 10 minutes on these, to figure out the candidate’s PM chops and then I’ll launch into API-specific topics:

1. Discuss your experience with API Design and Delivery

A good API PM will have been involved in the design of the product and the user experience. They may not execute the whole process, but they will have had a hand in it and should be able to understand good and bad API design.

If they haven’t done it, or have delegated it 100% to others, they cannot be effective. So, I’ll look out for things like: “I left it to Engineering” or “we did not design it”.

I’ll may dive briefly into the design process and tools used, but don’t expect to see cutting-edge know how. Just a general understanding will suffice (unless I’m hiring a PM for API Design tooling, in which case I expect you to be at the bleeding edge).

I’m looking for a sense that they know what a good API looks like and that they can have an intelligent conversation on the topic.

2. Dive into Developer Experience with specific examples.

I’ll ask them to bring up an example of an API they have delivered in the past, browse to the dev portal and share their screen. If they can’t share for some reason, I’ll ask for the URL and share mine. Or, if they only worked on internal APIs, I’ll ask them to bring up an API they think is good and we’ll talk around that.

Once we have a dev portal up, I’ll start picking out parts of the experience and will ask them what they think, why they did it that way or how they would improve it.

This could include signup, authentication, documentation, examples, specific format choices and so on, down to the selection of a specific status code, media type or data structure.

I’ll ask questions as if I’m a consumer of the API and will focus on both good and bad experiences.

I may give them feedback or pointers where they have gaps, so that they get something out of the interview. I may also learn something I didn’t know. during this discussion!

What I’m looking for is not necessarily that they’ve made all the best choices - lots goes into these decisions - but that they are able to discuss the thought process and weigh alternatives.

3. Dive into API Specs

I’ll ask them how they have used API Specs such as OpenAPI, JSON Schema, GraphQL Schema or Proto in their work. I’ll also check into what tools they’ve used for editing, consistency and testing.

This is fairly advanced stuff but can help judge the depth of their experience.

If the engineers at their previous job didn’t let them touch any artifacts, it’s a smell - I’ll dig into why.

I will not look for arcane knowledge of a spec or any gotchas - unless of course it’s part of the job to implement tooling for these specs.

I’m looking for an ability to use artifacts as requirements, to test if those requirements have been implemented and ways to ensure a good Developer Experience is being delivered.

4. Running and Evolving an API Product

Here I’ll ask them how they meter (or price) and get feedback on an API Product. How they have use tooling to ensure users have a smooth experience with onboarding and accessing the API.

And also, how they deal and react to availability and security issues.

Finally, I’ll ask how they use data and analytics to determine when and in which direction to evolve the API and if they’ve actually experienced launching a new iteration of the product.

We’ll have now spent around 50 minutes on the topics I want to explore. In between these I’m also looking for stories and anecdotes that illustrate real-world experience of these concepts. And I’m especially interested to hear where things went wrong and what you learned from it!

I’ll close by leaving 5-10 minutes for the candidate to bring up their questions, which to me is the most interesting part of the interview. Please let me know in the comments on the original LinkedIn post if you’d like me to go deeper on this last part.

If the candidate makes it through, I’ll schedule to them to speak to at least 3 more team members to dig deeper, for example:

Another PM or marketer to back me up and check for Domain experience
An engineer to figure out how they interface with others and,
An architect to dig into technical chops.

Let me know if this article resonates with you, especially if you’ve done this before.

And please reach out to me if you need help setting up and conducting a search for API PMs.