- Skiplevel Newsletter
- Posts
- Handling technical interview questions without a technical background
Handling technical interview questions without a technical background
Welcome to my monthly newsletter. I'm an experienced software engineer, a tech mentor to product managers, and the founder of Skiplevel. Every month I share:
technical skills and knowledge you should know
tips for working with and collaborating with dev teams
tips for non-engineers struggling with confidence in technology
tips for managers looking to build a more technically literate team
Ask me anything (yep, anything) and I'll cover it in an upcoming newsletter issue!
Q: I'm interviewing for product roles and I'm wondering how to best handle technical questions during PM interviews if I don’t have a technical background?
| Asked by Product Manager @ Walmart Data Ventures
Got a burning technical question? Ask me anything & I'll answer it in an upcoming issue!
This month's question is answered via an interview with Kenton Kivestu, CEO of RocketBlocks.
Irene: Kenton, thanks so much for agreeing to do this interview with me and providing some of your interviewing expertise to Skiplevel’s readers. Before you started RocketBlocks, you had a full career in product management including being a Director of Product. What was your experience in product like?
Kenton: I started working in product at Google — in what feels like ages ago! I was focused on ads products and spent a little bit of time working on search ads but pretty quickly shifted to building a series of new ad format products — like a very early internet radio ad product we built in 2009 (it was an audio clip + clickable companion banner).
I learned a ton at Google, both about how to build products and what type of projects I like to focus on as a PM. On the former, a key lesson was speed: it was better to build a product or feature and get it out quickly, get feedback and iterate then getting stuck in analysis paralysis. On the latter, the key personal lesson for me was I enjoyed zero-to-one projects — it was more fun to build a product from scratch and see if we get adoption, usage, revenue, etc. than it was to optimize an already successful product (which is also a great and fun challenge, just not my personal preference!)
After Google, I went to Zynga where I joined a tiny team making a mobile poker game for iOS and Android — this was fun for me b/c it was the super early stages of mobile gaming and there was so much to build. Ultimately, I helped build Zynga mobile poker into the #1 top grossing game on both iOS and Android simultaneously — we went from making about $10K / day when I joined to over $200K+ / day and we grew the team from about ~6 to ~35 people.
After Zynga, I joined Flurry, a mobile analytics and ads company, as a Director of Product and led their demand side ads team. Again, I was drawn by the opportunity to build a new product from scratch — which was a mobile demand side platform. It’s less sexy than mobile gaming — but was a fun challenge nonetheless. Flurry ultimately got acquired by Yahoo during the Marissa Mayer era and after integrating our products, I started by own company: RocketBlocks.
Irene: Your PM experience is incredible and sounds like a ton of fun. So what ultimately was your inspiration for starting RocketBlocks?
Kenton: When I first tried to break into PM, I ran into all sorts of obstacles around official qualifications (e.g., “you don’t have a CS degree”, etc.). This didn’t make sense to me because I viewed the real requirements as skills and believed that how you obtained the skills (self-taught like myself or formal degree) was irrelevant.
Given the barriers, I found that I needed to be very sharp at demonstrating those skills in interviews. For each interview I had, I went through an exercise mapping out the key basket of skills the company cared about and then devised all sorts of little tools to help me build those skills day in, day out. Over time, I started sharing these tools with friends and they all found them really useful as well. That was the inspiration for RocketBlocks — whether it’s PM or consulting, pretty much anyone can do these jobs if they’re given the right tools to understand what matters and how to get good at it.
So that’s ultimately what RocketBlocks: a place to build skills for your interviews and land the dream job.
Irene: That’s an incredible story. Speaking of skills that can be self-taught but hard to demonstrate, having technical skills is often a requirement for PM interviews, yet coding is not part of a product manager’s job responsibility. So why do technical questions exist during PM interviews? What are interviewers looking for?
Kenton: Haha, it can be confusing! If you don’t need to code on the job, why test people on it!
The simple answer: it’s a proxy.
When companies ask technical questions in PM interviews, they’re typically trying to assess whether you’ll be able to communicate and collaborate successfully with engineers — which is a core part of being a PM.
The point is not to figure out if you can actually code an algorithm in python or whatever BUT rather figure out if you can identify 1) where technical topics impact product (or vice versa) implications and 2) how to successfully communicate that to engineering so high-quality decisions can be made.
For example, imagine someone asks a PM in an interview — “Suppose you want to add a button to this interface to do X, what would you need to build?” They don’t care if you know how to code all that BUT rather they want to see if you understand implications like, “Oh, we’d need to store some new info to do that and we’d need some process to run daily, etc.”
NOTE: Of course, there are always some caveats but they’re rare! If you’re applying for a super technical PM role like owning an API team, the company **may** actually have some preference for more technical experience.
Irene: Are what interviewers looking for different for candidates with and without a technical background? If so, in what way?
Kenton: Theoretically, no. If a company has a clear idea of what type of PM they need, then the skills they’re testing for shouldn’t be influenced by the background of the candidate.
In practice, sometimes. If you’ve got a CS degree or some other technical experience on your resume, people will generally assume a level of knowledge associated with that. So if someone asks a CS major what an API is and the answer is sloppy, that can be a really bad sign.
Irene: Can you give us an example of a common technical question asked and how you would go about solving it?
Kenton: Company X is planning to launch feature Y — what needs to be built to support it? This format is super common and I really like this type of technical question because it gets DIRECTLY at the heart of the type of technical discussion a PM should be ready to have.
One particular one I like is thinking about Gmail’s delayed send functionality. It illustrates the concept well PLUS reinforces that this isn’t just thinking about new features! The exercise is simply about thinking through the components to build anything and whether that already exists or not is irrelevant.
Example from RocketBlocks: ...
Got a question? Ask me anything & I'll cover it in an upcoming issue!
💡 Tech Term You Should Know (TTYSK)
"Proxy Servers"
A "Proxy" is a technique that's an integral part of software design whereby something acts as an agent or intermediary for something else. The technique is popularly used throughout the various parts of software development (infrastructure, architecture, programming, etc..) A "proxy server" is an server intermediary between a client and a server. They are typically used to improve security, reliability, or the performance of services. In system design, proxy servers are used to decouple two software components so they are not dependent on each other in case of failures and so they can each evolve and scale independently.
Example: Firewalls work with proxy servers to protect a network and/or server from malicious activity. The Firewall sets the parameters on what is and isn't malicious activity and the proxy server will re-route the user to the appropriate server.
Hot Twitter Takes 👀
This thread perfectly explained why we use story points when estimating tasks:1) People attach less emotions to points2) People-Hours -> 'How long' but Story Points -> 'How big' (this is better)
Want to feel more confident in your technical skills?
Become more technical in just 5 weeks, without learning to code. We also train teams. Find out more at skiplevel.co/teams and book a call with me to get started.