Google's Management Interview and mapping to me
• Mark Eschbach
I was invited to interview at Google at a managerial level. They send a number of videos and documents. To process them I thought I would write my notes here and how I map into their structure. At least for their publicly accessible content.
Prepare for Project, Product, & Program Mgmt Interviews
A video covering project management, their software process, and what they expect. Or at least that is the pitch. My key takeaways:
1. Communication and Influence
They would like to hear past examples of influence over teams, both yours and others, with data driven decisions. These decisions should include examples of including input from individual contributors and making them feel valued.
2. Navigating Ambiguity
Oddly enough, I would expect managers to be very familiar with this. You take high level initiatives from above and needs from collaborative teams and sort out the order. They outline the following approach to how they integrate these:
- Develop a Product Requirements Document
- Perform requirements decomposition into tasks
- Prioritize those tasks
- Build a roadmap and communicate
- Build project plans and roadmaps with your team
Strangely this doesn’t really go much into the project management philosophy. More of a generalized framework of you should have a formalized plan to move through project management.
3. Stakeholder Management
Primarily pushes the point a manager is responsible for balancing between the various stakeholders within a project, and keeping stakeholders informed of where the project is. They heavily push documentation as a valid method to keep stakeholders informed. The video recommends publishing a newsletter and project trackers for interesting parties, which they consider a proactive approach. Really they push a project manager and technical manager are one and the same at Google.
4. Technical Partnership
Managers are technical at Google and have the capability to jump in and code too. Although managers are not expected to be the primary expert they should grow as they work with the team to understand the details and be effective.
5. Strategic Insights and Creativity
Managers are expected to understand and articulate how the team’s long term goals fit into the organizations strategic objectives. Recommends asking the team for their particular views and understanding. Specifically calls out for disregarding of statements of possibility and movement towards achieving the end user goals.
6. Execution
Quantify impact of the teams’ delivery towards strategic goals of the organization. Having a logical argument towards how the metrics you are gathering affect the strategic goal. Claim managers will remove blockers before they appear. Warn teams are often stretched thin, with managers needing to help prioritize between features, budget, and schedule. They are particularly interested in learning about how a potential manager has executed to proactively abate issues and deliver.
7. Best Practices
Want explanation on thought processes. Verify assumptions, and try to select the best example.
Applicable Experience
When I started with WhiteSpace I was assigned to a legitimate tin foil hat project. I was given 14 engineers plus a project manager and told “go make things happen.” Setup 1 week iterations with 6 week retros to be responsive to plan changes as we move through. We began taking inventory of other teams plans and trying to find where we would fit. Our DevXP sub-teams realized the 6 collaborating teams would need Kinesis Streams. So after the first objective of setting up IaC for the shared infrastructure team we would build those out. Last major shared component set was ElasticSearch.
Originally we thought this would be easy, just spin up AWS ElasticSearch, since that was the cloud platform we were building on. Unfortunately we were informed the security group had explicitly denied AWS ElasticSearch due to load balancer logging issues. We had the team quickly prototype running ElasticSearch on an OpenShift Container Platform which proved challenging due all Persistent Volumes being configured in one AZ for both pre-production and production. So we circled up on how to do it on bare EC2 instances, something definitely approved. In the end we had designed an ES cluster front by an NLB using EBS volumes to determine node identity. Cluster was performant, tolerant to many failures, and was relatively cheap to operate.