A recruiter approached me and explained their interview process. Apparently the first two interviews are very technical and product design oriented and they are “very hard” to get through. It left me wondering if anyone does this work in their day to day job. I certainly don’t!
3 Likes
Uh even the most detailed interviews don’t even begin to scratch the surface of what I do in my day-to-day job. Interviews are usually summarizing work that takes days, weeks, or months into an example of what my process is and how I would apply it to a novel problem.
Technical:
- “System design”: Last system I described was a high-level data flow. I knew a significant amount of the database architecture, and had to reason about it, because it materially impacted what features were and were not feasible, and some details were exposed to customers.
- “Explain recursion to a five year old”: While I want to say a feature is expensive because the code base is an insult to spaghetti, the issues are so unbelievable that nobody, not even execs, will let the costing issue go without an explanation of how fucked the API is.
- Version control / automation: Most of my customers use version control in some part of the human workflow or data pipeline associated with my products, so I need to understand their change management practices and automation tools.
- APIs: Good API design benefits from understand both what tasks someone might automate and how they might do so - individual resources? Batch? How do resources / objects relate and how many calls do people need to make to get the info they want?
- Data formats: A lot of my products have been technical and output some form of structured data. Basic knowledge of object-oriented programming can help you understand this quickly. Also, this is like the one thing where coding knowledge can really help
- Proofs / Logic: Certain products, especially automation / technical tools need to work, or at least fail in predictable manners. When customers are trying to make assertions about how their workflows function, applying rigor to your product requirements that resembles a mathematical proof ensure full coverage of complex use cases
Product design:
- “Why?” (for the business): I’m busy and have important work to get to, if my manager asks me to do something that seems dumb I’m going to ask why me and what the purpose is
- “Why?” (for the customer): Probably the most common thing PMs all do consistently. If you don’t know the underlying goal you usually build the wrong product. “Why this and not that?” for prioritization
- User needs / stories / etc.: Yes, writing these out end to end, in a pretty waterfall style is how I make sure complex systems actually set out the goals they intend to achieve, and ensure that dependencies stay in line
- Random obnoxiously detailed edge cases: Yes, someone needs to make the decisions and it’s usually me
- Metrics: Yes and no. This depends a lot on your company and product (especially maturity - legacy products tend to lack great instrumentation and newer ones might lack a customer base to generate meaningful data quantities). I usually provide end with some must-have success metrics at the start, and then we work on a wishlist of other useful insights leading up to launch
I don’t think anything about the product design stuff is super controversial. I don’t do all these things in great detail for every product / feature. Sometimes I do build things because the boss thinks it’s strategically critical. For some products I talk with lawyers several times a week and review lots of legal documents, while for other products I’m mostly working with stakeholders or on visual design. Curious, are there specific detailed product design things the recruiter mentioned that seem unusual to you?
The technical stuff is both a generic muscle you can flex if you have it to make working with engineering easier, and central to your job if you have technical users completing technical tasks. But system design is far, far more useful than actual coding ability in most jobs.
1 Like
No, not unusual. In fact, pretty much par for the course as far as the interviews go. As you know there’s a booming training business vertical feeding off of this particular types of interviews. I’m just curious if these system design stuff is mainly for the sake of weeding out the candidates or if someone actually uses these in real life. I certainly haven’t and I have worked for FAANG.
2 Likes
Ah, I see. Yeah, IMO the “system design” stuff (or whatever we call our PM flavor of it) is actually the difference between PMs who build decent products and PMs who quite literally fuck everything up. If you have a team working on a big interdependent platform (any SaaS / PaaS / IaaS tends to fall into this) one PM’s bad decisions can make developing product for everyone else down the line who has to interact with their stuff.
That being said, I don’t know if the system design-lite interviews are the right way to test for those skills. The best questions I was ever asked was basically if I knew why the engineering team had made certain technical design decisions. They were based on future features we wanted to be able to support in the future, and I explained how we made certain tradeoffs and planned ahead. But that experience is not common - I happened to be around very early on in the life of a product - so I don’t think that that works across the board.
I should mentioned that I do have a CS background, so of course I have bias in terms of how I approach problems. Most of the PMs in my product areas are really technical right now because our jobs demand it. We could probably switch into each other’s jobs given a few months, but our specialization includes a bunch of subject-matter specific knowledge on top of that technical foundation.
1 Like
For every product I’ve managed so far, not much. The benefits have been credibility and context.
- Credibility: Engineers and architects trust and respect me more inherently because I’m “technical.” I don’t sidetrack technical discussions by asking for technical 101’s. I can read code/architecture diagrams.
- Context: I can sniff out bad decisions and steer them back on track by asking the right product-minded questions. I don’t overstep but I don’t require handholding.
I would wager there are contexts - the problem, the user base, the team you have, etc. - where PM’s having these skills are likely more valuable, even essential.