4a. How much you need to know

How much do I need to know for the technical interview?

The technical interview is often what worries candidates the most. How technical do I need to be? What kinds of crazy computer science questions will they ask me? Will they make me write code?

While the technical part of the PM interview is often the most variable from company to company, it is still something you can understand and prepare for.

What is the goal of a technical interview?

The ultimate goal of a technical interview is to see if you have enough technical knowledge, or if you can think in a technical enough way, to be able to talk to engineers. Why is this important? One of the primary roles of a PM is to decide on tradeoffs, and the most common form of tradeoff a PM encounters is deciding what parts of a feature to build given how long each part will take. In order to make this decision, the PM not only needs to understand that a certain part of a feature is hard to build, but also why.

In a healthy PM-Engineering relationship, the Engineering team will explain why a certain thing is expensive to build.

Side note: when we use the term “eng cost”, it refers to how long it takes for engineering to build something. Thus, an “expensive” project is one that has a higher eng cost. Eng cost is usually measured in time. For example, if a project’s eng cost is “3 Eng weeks”, that means it will take one engineer three weeks to build, or perhaps three engineers one week to build if the tasks are fully parallelizable.

Sometimes, these estimates will be too conservative, and in those cases it’s useful for the PM to be technical in order to question the original estimates and have a discussion about whether the estimates are actually lower.

More often than not, however, it’s useful for the PM to 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 originally desired 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 user need.

Different companies expect different things

Remember that PMs at different companies fit into the organization in slightly different ways. Some companies are more driven by the business org, which means that perhaps they expect PMs to work more on the business side as well. In these orgs, PMs probably do not need to be as technical.

However, if a PM is working on something academic in nature (e.g. machine learning) or something relating to an API or which is developer-facing, it would help immensely for the PM to be on the more technical side.

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.

Coding skills for the technical interview, or “Do you need to know how to code?”

This is the most common question relating to the technical interview. The answer is, generally, no.

Will you be asked to code a very complex problem in your interview? No – you’re not interviewing for an engineering role, so this shouldn’t happen.

Will you have to write working code for a simpler problem? Most likely not – again, you’re not interviewing for an engineering role.

Will you have to write pseudocode to solve a simpler problem? This should happen rarely, but is within the realm of reason. This can be viewed as more of a basic test of technical thinking or abilities.

Note that different factors about your resume and conversation will impact the chances that you actually have to write code. If you were a software engineer in the past, for example, that might slightly raise the chances of having to write code, because the interviewer might believe this is just in your wheelhouse. If you have absolutely no technical background, that might also slightly raise the chances of having to write pseudocode, because the interviewer is worried that you aren’t technical enough. If you’ve boasted on your resume about a small side project you’ve coded yourself, that might also raise the chances of being asked to code slightly.

In general, don’t worry too much about having to write actual code in your interview. If you’re taking some of the online courses recommended in this guide to learn the basics of a coding language, you’ll probably be fine. If it’s been a few years since you last coded, brush up a bit on the basics, and you’ll probably be fine. Otherwise, remember that it’s always better to be honest – don’t claim to know more than you actually do, and if you get asked a coding question but don’t know at all how to code, admit that, and do your best to address the other parts of the question.

Practical skills for the technical interview

What’s more important for the technical interview is to know practical technical knowledge. This includes topics like how you would actually build a website or a modern web app, or how you would actually think about tradeoffs that you would face as a PM.

Basically, this category of technical knowledge fulfills the interviewer’s goal of figuring out whether you can actually carry on the kinds of conversations with Engineering on the job. 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)?”, but these can take on many forms:

  • Let’s say you’re on Google.com. You type in a search query. Describe the sequence of events that occur from the point you hit enter to the point you get results back.
  • How would you generally architect a simple version of Twitter?
  • Let’s say your company’s website is, all of a sudden, loading really slowly. What might be some causes for this?
  • Your website hosts and streams videos, and you want to save on bandwidth costs. What are some ideas to address this?
  • You have a moderately successful and growing website. Now you’re considering building a mobile app version of your product. What are some considerations you’d want to think through?

These kinds of questions are very easy if you’ve ever worked at a web-enabled tech company, big or small. If you’ve ever built a product yourself, these questions will also probably be easy. But, even if you haven’t had that kind of experience, it’s still possible to just study this material – the next chapter will have some tips and additional resources that you can look into.

Theoretical knowledge for the technical interview

Theoretical computer science knowledge is a rarer topic for technical interviews, but might still come up. This category of topics includes ones like algorithms, data structures, sorting, graph theory, etc…basically, all the stuff a CS major would learn in college.

If you’ve never taken a CS class, it would be good to flip through some materials to get a high-level understanding in each of the major theoretical areas of CS. If you did study CS in college, it should be a simpler task of refreshing your memory of this kind of material.

One infamous topic in this category which might come up in interviews is sorting. Sorting algorithms talk about how you take an unordered list of items, and get them in some kind of order (e.g. alphabetical, numerically ascending, etc.). You should know what the different kinds of sorts are, how they’re accomplished, and the big O time of each kind of sort. You should definitely also know what the more optimal kinds of sorting algorithms are. This is a very common theoretical CS question that has a lot of online resources written about it – start off with the Wiki on this topic and go from there.

Another infamous topic is big O notation. Big O notation is a way to roughly state how long an algorithm should take. It’s usually expressed in terms of “n”, where n is the number of items you’re dealing with. This topic is a bit more advanced than sorting (and is, in fact, a core topic in the world of algorithms), but again there are lots of online resources about this. The Wiki is again not a bad place to start.

The final infamous topic to raise here is recursion. In CS, recursion is when a certain chunk of code executes itself in the course of running. It’s a somewhat simple concept to learn, somewhat difficult concept to implement, and a clear indicator of basic technical knowledge. The infamous question on this topic is “Can you explain recursion to a five year old” (I don’t know when a five year old would need to know recursion, but oh well, that five year old will be well-prepared for a future PM interview). For a starting point, take a look at the answers to this Quora question.