The technical PM interview is often what candidates fret over the most.
How technical do I need to be? While this type of question varies from company to company, there is helpful context to learn and helpful ways to prep for it.
The goal of a technical interview is to see if you have enough of the technical knowledge to communicate and collaborate successfully with engineers.
This is important because one of the primary roles of a PM is to decide on tradeoffs, and the most common form of tradeoff is deciding what parts of a feature to build given how long each part will take. In order to make this decision, the PM works with the engineers to understand which parts of a feature are hard to build and why.
It's important to remember that the PM is not the one in charge of knowing all the exact technical tradeoffs, nor do PMs need to know exactly how a feature is built technically. All of that is why PMs work closely with engineers. The "eng cost" of a feature is usually measured in time, such as "two weeks of one engineer's work" or "a quarter with two engineers".
It's useful for the PM to be technical, because then she can have an intelligible conversation with the eng team on how to scope the project down. Perhaps taking away some of the bells and whistles in the original spec will cut down the engineering cost substantially. Or, perhaps the bells and whistles aren't really that expensive to build, but it's a different assumption underlying the spec that's creating the higher eng cost. The PM needs to work with engineering to figure out what can be scoped down given the overall desired timelines, while still accomplishing the goal of the project.
The product manager role at different companies can vary significantly. Some companies want their PMs to be more on the business side and less technical. Others may want the opposite. Culture also plays a big part in this. For example, Google is notorious for being an incredibly engineering-driven culture; they also have one of the highest technical bars for hiring PMs. In contrast, Amazon is known for hiring more business-minded and less-technical PMs, while Facebook and Microsoft are somewhere in-between.
It is generally difficult to know from the outside how high the "technical bar" is for PMs in the interview process. Companies seem to be moving away from having a high technical bar for PMs, though it's still important that a PM can have a fruitful discussion with an engineer. There are exceptions to this. For example, some companies are known to be quite engineering-driven in culture (e.g. Google, Stripe), so they seek more technical PMs. Other PM roles specifically cover more technical products (e.g. the PM overseeing a company's API), so they'll require a more technical background. Your best bet is to ask others who work there or have interviewed there, or to ask the hiring manager or recruiter.
You will definitely not be asked to code a very complex problem in your interview. You will very likely not have to write code for a simpler problem either. You will most likely not have to write pseudocode, but this is where the line gets fuzzy. It'll all depend on the company and the interviewer but, for most companies that do a technical interview at all, the questions tend to avoid code or pseudocode.
Note that different factors about your resume and conversation will impact how high the technical bar is. If you were a software engineer in the past, for example, that might slightly raise the chances of having to write code or answer more technical questions. If you have absolutely no technical background, then chances are you'll be asked more basic technical questions, but a company that has a higher technical bar might actually ask you slightly harder questions out of the worry that you aren't technical enough. If you've boasted on your resume about a small side project you've coded yourself, then you might be asked about the technical details behind that.
What's more important for the technical interview is to know practical technical knowledge. The company likely wants to see that you know what goes into building a modern website or web app, or that you know how to think about tradeoffs that you would face as a PM.
Most of the time, the company just wants to know if you can carry on an intelligible conversation with an engineer you're working with. The most prototypical questions in this category are "How does the internet work?" and "What is the rough structure of a modern web app (i.e. website)?".
These foundational questions can take on many forms. Here is a handful of common PM interview questions testing practical technical knowledge:
These kinds of questions are very easy if you've ever worked at a web-enabled tech company or if you've ever built a product yourself. Even if you haven't, you can still learn and study this material.
💡 Got a PM interview? Our PM interview drills help get you in top form
Aside from the practical technical knowledge, there's a small chance you get asked about theoretical computer science topics. These topics include ones like algorithms, data structures, sorting, graph theory, and other topics that might be covered by a CS degree. But, generally, you don't have to worry about these kinds of academic topics unless you receive some indication from the recruiter that you should know them. (At the end of the day, practical technical knowledge is more, well, practical for the job.)
If you've never taken a CS class, you could flip through some materials to get a high-level understanding of each of these theoretical topics. Or, you could find some summaries online of these topics, especially ones geared towards interview prep.
There are a few more notorious theoretical topics that you should get a bit of exposure to. One is sorting. Sorting algorithms are different ways to sort an unordered list of items. You should know what the different common kinds of sorts are, how they're accomplished, and the big O time (the efficiency) of each kind of sort. There are a lot of online resources on this topic - start off with the Wiki on this topic and go from there.
Another infamous topic is big O notation, which is a way to roughly state how long an algorithm should take. It's expressed in terms of "n", where n is the number of items you're dealing with. This topic is a bit more advanced, but again there are lots of online resources about this. The Wiki is again not a bad place to start.
A third infamous topic is recursion. With code, recursion is when a certain chunk of code executes itself in the course of running. It's somewhat simple to learn, somewhat difficult to implement, and a clear indicator of basic technical knowledge. The prototypical question here is "Can you explain recursion to a five year old", i.e. can you explain it simply and describe it with an analogy. This Quora question is a good start.
"How would you describe an API to a non-technical person?"
This is a reasonable question to expect at a company that has a technical bar for PMs, but not one that's very high. It's on the easier side for a company that is known to have a higher technical bar, like Google.
High-level, an API is how two websites can talk to each other. There are lots of examples of API use cases in all kinds of websites. For example, a lot of websites let you do something like "log in with Facebook", and after you do, they get various information about you from Facebook. Yelp, for example, lets you connect your Yelp account with your Facebook account, and after you do so, Yelp will show your Facebook profile photo and also show you your Facebook friends. [Note - I'm not sure if this is actually a feature of Yelp, but seems prototypical enough to use here.]
In this case, how does Yelp get your information from Facebook? Theoretically, Yelp could do it manually - when a Yelp user says that they want to connect their account with their Facebook account, Yelp could somehow get the user to log into Facebook, manually save their Facebook profile photo and friends down, and then upload it into Yelp's database to show on Yelp's website. Yelp obviously has a way to do this automatically though, and that way is through APIs.
Websites like Facebook have an API, which is basically a standardized way that other websites can talk to Facebook and get Facebook data. If a company like Facebook decides they want to offer an API (and not all companies do), they'll publish documentation with steps and instructions on how other people can use the API. Facebook will also define what data can be accessed via an API. For example, Facebook lets other websites see a user's friends, but it might not let other websites download all of a user's photos - just their profile photo. This is all within Facebook's control, and they give their API whatever capabilities they feel comfortable with.
With the documentation of Facebook's API, other websites like Yelp can write the code to communicate with Facebook's API properly. Just like your browser communicates with the Yelp servers to load a page from Yelp, so too can Yelp communicate with Facebook's servers via the API to get the information it wants.
There are a few details to note here. The first is that APIs usually require some kind of "authentication". It wouldn't be good if anybody could get any Facebook user's information. The Facebook API thus requires some kind of user-level authentication - it has to make sure the user knows about this information sharing before it gives the information to a party like Yelp. Also, Yelp is pretty well-known, but Facebook probably doesn't want to work with any random website out there that makes a request out of the blue. Rather, most sites like Facebook require another website to register with it somehow before it will respond to any request. This way, Facebook can identify who's making each request.
Why would a company offer an API? For one, users like integrations. Think about how many tools out there work well with other tools - this is especially notable when it comes to productivity tools. All these touchpoints between products are likely built on APIs. So, a company might offer an API to respond to users' desire to have a product work well with others. Second, a company might use an API to grow its own userbase or to establish market share. The fact that Facebook has an API, for example, makes it more valuable for users to have a Facebook account, so that they can easily "log in with Facebook" on other sites, among other reasons. This capability makes Facebook more attractive for users. Third, companies often charge for their API. On one hand, responding to API requests is not free - it requires computing resources. On the other, some companies have very valuable data - Yelp for example has lots of high-quality data about local businesses. They can monetize this data by charging others for API usage. It's a scalable way for other companies to tap into the Yelp data they want and how they want it, rather than Yelp trying to manually fulfill each individual request for data.
This answer shows that the candidate has definitely heard of APIs before and knows at least roughly how and why they're used. Answers with concrete examples are always helpful - here, the example of Yelp using Facebook's API may or may not exist in real life, but it seems like a very plausible feature that would be powered by an API. A good analogy can also be very powerful.
With a broad technical question like this, it's also useful to go into the next level of detail. Here, the candidate also addressed the question of authentication. They also took the opportunity to explain why a company would even offer an API - a good way to demonstrate some business thinking.
This answer could have gone in different directions as well. For example, the candidate could have dug deeper and talked through an example of a specific API call. Or, the candidate could have talked through the tradeoffs between calling an API live versus savings its response. Or, the candidate could have talked about how it's possible to have APIs internal to a complex product and why it might be advantageous to architect an app that way. With such a broad starting question, the interviewer might also steer the conversation in a specific direction.
Real interview questions. Sample answers from PM leaders at Google, Amazon and Facebook. Plus study sheets on key concepts.