Execution Flashcards
What was your team’s strategy and vision? How did you arrive at it?
“Enable the world’s best transportation by protecting Lyft and its users from product abuse”
Strategy:
- Build a platform solution to allow product teams to solve their own unique problems
- Dogfood our own solution by using it for fin fraud
- De-risk against future attacks
How did you come up with this strategy?
Knowing the customers.
Anticipate their problems
Be data driven
What were the metrics you used to measure success for this vision? How did you know you were making progress against this vision?
For people that were integrated w/ us - Joint KRs
For the platform team:
- Speed of iteration.
For the Core Fraud team:
- Balance between fraud and good user impact
How did you set your goals? How did you come up with your roadmap?
Give me an example of a time you had to make a data driven decision
VOIP and prepaid cards.
How do you evaluate the quality of your team’s work? How do you measure quality?
Bake that into our KRs.
Introduce Reliability metrics
Measure Bugs, pages, incidents
Keep an eye out on how many, we see, how often
What processes did you introduce to improve quality?
From a culture perspective, make sure quality and rigorous testing are fundamental
- Engineers should feel ownership over QA-ing their features
- Build user empathy
Process: Weekly or biweekly design reviews
- TLs (open to all engineers) review designs across the team, raise questions, make suggestions
Process: Weekly on-call handoffs
- Update tech debt backlog
Process:
- Created their own QA docs for rolling out new product flow
Tell me about Tech debt vs Features. How do you prioritize these while making room for both?
There’s two things to make sure you make room for tech debt:
- Making sure that cross functional partners are aligned on why we need to make progress on tech debt
- Build an engineering culture where engineers feel empowered to tackle tech debt as they see it
Tactics:
- Build time in during long term planning: 70/20/10. Rough rule of thumb, should be flexible depending on needs
- Build a tech debt backlog.
- Weekly handoffs between on-calls
- Whittle down backlog when folks are done with things
- Fix-it weeks
How do you measure tech debt?
There are several categories of tech debt.
Category 1: From the most basic level, we have bugs or issues in a service that affect:
Developer productivity (CI speed, test flakes)
Operational cost: (oncall load)
System Reliability: (Latency, uptime, correctness)
Sprint Retros
How do you know how the team is executing in the short term?
For projects:
- Depending on what type of project
Sprint planning:
- Planning Poker
- Measure velocity based on story points
(*required) Tell me how you communicated your roadmap externally?
During Planning:
Gather it from the team. Get buy-in from the team
Before planning is over: Circulate rough draft to adjacent team, dependent teams Communicate it up to leadership Director, sometimes execs Gather feedback
After:
Publish it to team wiki
(*required) Tell me about a time you helped drive process or cultural changes across teams/orgs that you’re particularly proud of.
Improve cross-functional team culture and morale:
Normalized vulnerability
Continuous Feedback
Openness and transparency
(*) Tell me about a time you had to push back or say no to a stakeholder. Why was this necessary and how did you do it?
Example: (Wenbo Rule Engine)
(*required) Tell me about a difficult organizational resource tradeoff decision you were involved in. Why was it difficult, what were the options, how did you gather required information, what was the outcome?
Example: Data team vs Fraud
Tell me when you had to convince a different team to change priorities
ML Platform - ModelEx
