Example: “In my last role, I was responsible for creating a new feature on our website that allowed users to create their own custom gift baskets. To do this, we needed to integrate a third-party API into our website so that we could use its basket building tool. This process took some time, but once we integrated the API, it made adding new features to our website much easier.”
Example: “I’ve worked primarily with Java in my previous roles as an API product manager. I find it to be a very useful language for creating APIs because it’s object-oriented and has many libraries that make coding easier. I’m also familiar with C++, JavaScript and Python, although I haven’t used these languages as often.”
Example: “I would start by researching potential markets that have similar demographics to our current customer base. I would then research each market’s digital landscape to see if there are any opportunities for us to enter. If so, I would determine whether we could provide value to those customers through our product. If not, I would look into partnering with other companies who already serve those customers.”
Example: “I think it’s important for an API Product Manager to listen to developer feedback and respond in a timely manner. Developers are often the ones who know best when something isn’t working properly or if there is a better way to do things. I always make sure to take time to read through any issues they report and offer solutions as soon as possible.”
API product managers need to have a strong technical background, as well as experience in product management and customer relations. They also need to be able to effectively communicate with engineers and customers.
What are some best practices for creating developer documentation
Out of date and disorganized documentation is the bane of existence for any product manager or developer relations manager for a developer community. Here, you’re looking for ways to automate some of the generation of documentation while staying customer-centric. Are they familiar with tools like OpenAPI spec and Postman Collections? Do they prefer documentation to be written in open tooling like Markdown or in a specific helpdesk software like Zendesk? How do they handle duplicate information that may exist in GitHub README.md, API reference, and developer docs located on the company’s domain. Are there different types of documentation with a a target persona in mind?
How do you handle API feature deprecation?
Unlike a consumer application, API products require careful planning when breaking any functionality. Almost always, the best answer is to not introduce any breaking changes and never remove a field. For example, your API response has a single JSON field called name, and you wanted to split it up into first_name, last_name, and username. Then, the the correct way would be to add the new fields while maintaining the old field going forward.
There are rare situations such as fixing security vulnerabilities or sunsetting an entire product where breaking changes are required. You should follow up with the candidate on how to handle such scenarios. This may include sending personalized emails to developers who accessed the API with specific details on which version they were using and when they last accessed the deprecated API. Other strategies include brownouts where functionality is turned off for short durations during off hours such as 1pm on a Sunday.