In this post, I’m picking up the popular “Interview Prep Deep Dive” series, and talk about one of the most unique components of the product manager interviews - Technical interviews.
As always, I’m going to cover it in the simple 3 parts:
🍭What is a Technical Interview?
🔍What Are Interviewer’s Expectations?
📘How Do You Best Prepare?
Now let’d dive right in!
🍭What is a Technical Interview?
The Technical Interview is designed to test, well, how technical you are as a product manager. What does that mean exactly?
Do you love technology? How’s your breadth and depths in technical topics? Do you work well with engineering? Do you understand how the sausages are made? Do you meet the minimal bar of being a “tech person”?
So here, the technical interview specifically refers to testing your engineering related knowledge and experience (software and/or hardware depending on the role). It’s worth noting that sometimes a “technical” interview generally refers to testing your “hard skills” as a product manager, which includes product design, execution, strategy etc. Don’t get confused, and make sure you confirm with the recruiter what that is exactly.
Different companies have very different approach to technical interviews. Google (disclaimer: opinions/info expressed in this post is entirely mine, and is not of my current employer) is known for having a much higher technical bar for it’s engineering-centric culture. Many companies do expect you to be able to speak to modern technical concepts and how your software products are architected. All of them will definitely evaluate how well you work with engineering.
Also, you might not necessarily have an interview specifically titled “technical interview”. It can even have no title at all, only the person/role you’ll be speaking with. So if you’re meeting with an engineering interviewer, you might expect it to be more technical.
So don’t make assumption, ask explicitly what to expect in a technical interview for each company.
🔍What Are Interviewer’s Expectations?
Again the expectations differ from company to company. Some companies have much higher expectations/bars, others primarily just want to make sure engineering likes to work with you. If we think of it as a technical expectation spectrum, let me explain in 5 levels, from the low to high. The higher level expectation would usually be inclusive of lower levels below it.
Level #1: Work With Engineering
I’m sure it’s obvious enough to you, that to succeed as a product manager in tech, you have to work well with engineering. What does it mean by “working well”?
Are you respected by them as a leader, and can you motivate them along the journey?
Can you effectively influence and align engineering to go the direction that’s going to positively impact the users and the business?
Do you understand engineer’s challenges and needs, and provide them what they need to do their best and succeed?
Can you face and effectively resolve conflicts?
Can you describe some of the technical issues your team/product have faced in the past?
At this level, the questions are highly behavioral like, so make sure you review my behavioral interview tips. But keep in mind that this is fundamentally still is a technical-centric interview, so not only should you prepare good examples of how you worked with engineering in different scenarios, you need to be prepared to speak more precisely about the technical terms and concept, and be ready to respond to follow up deep dive questions. Which potentially leads into the next level.
Level #2: Technology Concept
Can you comfortably describe the specific technologies that were used in your products? Did you pay attention and were you curious about these technologies when engineering discussed about them (or you simply zone out every time a technology term is brought up).
The expectation here is usually not for you to demonstrate how much an expert you are in specific technologies (unless your role is highly domain specifically and they expect you to be an expert in the field. E.g. an SEO product manager). The expectation is for you, as a role responsible for connecting technology x business, to comfortably speak to technology you’re exposed to everyday, and be liking it to some degree.
If you’re a chef (who connects raw ingredients to art and customer delights) who can’t speak to or like the ingredients, you can’t make great dishes.
Level #3: Architecture Understanding
Now, beyond knowing the terms and concepts, do you know how these technologies are assembled into your end products? (like how a chef assembled ingredients into dishes?) Welcome to level #3 expectation: can you describe the technical architecture behind your products?
To give an example: you know these terms: relational database, micro services, search indexes, REST APIs, React.js, etc. used in your product. How are these components connected with each other in a complete architecture? What role does each component play? Can you describe them in logical layers?
Level #2 + level #3 gives interviewer a good picture of how much you really know “how the sausages were made”.
Level #4: Architecture Design
Level #4 starts to get a bit more advanced, I’d say there are more companies that don’t have this level of expectations, than those that do. (Though it also depends on the roles, and things can evolve in the future!)
Having that said, the expectation still is not for you to really be an engineering architect. (Though you can be sure that any senior engineer / architect will go through the same interview, obviously with much higher bar to get right). The expectation is to see how proficient you are in architecture familiarity, by asking you to design the architecture to another product that’s not yours. (e.g. Design the technical architecture behind Twitter.com)
It might initially sound insurmountable. How is it fair to ask me to architect Twitter?? Calm down. It’s actually no different from, being asked “what would you do as a Microsoft CEO”, or “build the next generation Facebook”. The expectation is simply:
(Similar to other interviews) how you define scope, break it down, and communicate in structure
How you touch upon key architecture concepts at different layers of a modern software architecture, at a super high level
How you speak to engineering goals besides business goals like scalability, reliability, availability etc. And design to optimize for them.
Still hard to imagine how to handle it? I’ll speak to some prep tips below.
Level #5: Coding / Algorithm
Pinnacle of the technical interview expectation: coding and solving algorithm problems like an engineer. And because it’s at the top, it’s getting relatively rare these days. But it’s still worth mentioning, because it’s still a possibility.
In the much early days when the role of a product manager is even less defined, there were more frequent expectations for a product manager to fill in the role as an engineer as needed, including coding, check in code, and push to prod. Now the expectation is more for a product manager to focus on what engineering can’t and maximize the unique value as a product manager (like focus on users and define problems), rather than barely acting as a low quality engineer.
Obviously, if you came from an engineering background, or you simply are familiar with coding and algorithms, it’ll probably still help with your job especially in working well with engineering. That’s how the coding/algorithm interview (for product managers) was created.
Should you panic about it? I wouldn’t.
Could it still happen with some interviews? Probably. Again, confirm with your recruiting team for exactly what to expect.
📘How Do You Best Prepare?
Let me start with some general tips, before talking about preparations for each expectation level.
General tips:
Start with Level #1: start from the very basic and universal expectation level, and work your way up. Remember, the lower level it is, the more frequent you would expect it in technical interviews.
Don’t do this alone: use your engineering friends/colleague/ex-colleague. Ask them to help you refresh the concept and architecture behind the products. Especially colleague and ex-colleague. They helped you build your products didn’t they? Just ask them what technologies are used and how they would describe the architecture if you’re not already familiar. Or start with your description and ask them to validate it. Even with current colleague when you don’t want to disclose your interview status, it should be an easy sell by just saying you’re curious and love to learn more. Most likely they’ll be happy to explain it to you.
Don’t throw away your typical product management stuff: Remember, a technical interview still is a product manager interview. It’s to test you as a product manager not as an engineer. So like any other interview, be acting like a good product manager. Communicate well, work through ambiguity, tie it back to the bigger picture, all that good stuff.
Now some level specific tips:
Level #1: Work With Engineers: like in behavioral interview, think hard and prepare good number of examples for different anticipated scenarios. Again non-exhaustively you could expect:
How you motivated engineers
How you deal with challenges/conflicts with engineers
Describe a technical issues you participated, how you helped
Describe some technical trade off decisions you were involved in
Or just “how you work with engineering” at principle level
Etc. etc.
Level #2: Technology Concept: again, use help from your engineering connection. At least be familiar with the technologies used in your current/recent products you plan on speaking to. Anticipate some technologies that the specific company might care immensely about (e.g. crypto for a cryptocurrency platform company). Develop high level understanding of popular tech “buzzwords” like machine learning, block chain, etc. and think about how you would explain it in laymen’s term to a non-tech person.
Level #3: Architecture Understanding: once again, ask your engineering colleague to give you an overview. Ask follow up questions to make sure you full understand it logically, and rehearse describing it concisely. Use understanding the architecture behind your own product as the foundation to develop the general understanding of any modern software architecture, which preps you for Level #4.
Level #4: Architecture Design: Look up “system design interviews” at Google, you should find plenty of materials. Many of which were written for engineers (because again they go through the same interview), but you can pick ones that are higher level “primers”, and it should be sufficient for your purpose. Familiarize yourself with the following concepts: Availability, scalability, reliability, performance. Make sure you know of a few high level approaches to optimize for these. Find actual questions to practice, practice and practice on a piece of paper (like how you’d prepare for product design interviews).
Level #5. Coding / Algorithm: If you really have to, yes, leetcode like an engineer. Just know that you cannot develop coding skills over night, right before the interview if you have not been coding at all. So if you really want to be prepared, start doing a bit of coding and refreshing yourself basic data structure and algorithm concepts like sorting, selection, trees, array, linked list etc. and develop up your knowledge over time. I really don’t have a magic bullet for you on this one. Luckily like I said, it’s relatively less frequent, and you should build up level #1-#4 first anyway.
To Close
Knowing technical topics is important for product managers in tech. You don’t need to be as technical as the engineers, but you need to be technical enough to work well with them and with the technologies that create your product.
So in addition to spending the time and effort to prepare for your upcoming technical interviews, make sure you continuously learn and be curious about technical topics on and off the job. Don’t be afraid to get into the weeds with engineering, look up technical concept when facing something you don’t know much about, and selectively read tech news and technical resources to develop that tech acumen over time. That’s actually the best way to prepare! By doing so, you’ll not only find your next technical interviews much easier to crack. You’ll also find yourself being more effective at the job!
—
If you have your unique experience to share, or questions after reading the, contact me! I’d love to hear and help!