Netflix Values Flashcards
Made wise decisions despite ambiguity
BQ Cost issue
Superset project
LSP -> Sharding vs Batching (time pressure, fixed scale calculations, got buy-ins)
Used data to inform intuition
BQ Benchmarking => Queried redshift, BQ, Snowflake to identify the right choice
BQ Cost => Used previous queries to make an estimate
LSP Redis => How would a high fsync with multi az replica redis function compared to Google native NoSQL
Looked beyond symptoms to identify issue
Redshift issue -> Query load, batching etc wasn’t the issue. Storage and compute on the same node was the issue.
Kickstarter -> Game teams were reluctant to learn backend systems and my team was spending time on it. Updates were painful to roll out. Solution was to centralize the system.
Made decisions based on long-term impact instead of short term
LSP -> Decided to go batching even though it adds more dev time since sharding would be buggy and hard to maintain, causing issues to our players.
Migration to SuperSet (marketing issue -> Take on extra responsibility to figure out tableau and support them to get their buy-ins for long time goal)
Give an example where you put the company before your or the team’s priority
Superset Migration
WD losing engineers to Chef -> We had to re-prioritize our project several times, figure out ways to automate things, and drop performance improvement projects to support the company’s vision.
Give an example where you took someone else’s idea when yours wasn’t the optimal
Cron Design -> I was building it using AWS event bridge and cloud formation. The design was a standard cron system by configuring the event bridge directly. During a tech discussion with colleagues, one pointed out we could use the task queue. I hesitated initially, and we started discussing the pros and cons of the same.
We then got the original author of the task queue also involved to get his thoughts. He shed more light on how we can leverage the task queue but also added that several items in my design can be an opportunity to enhance the task queue. We then ended up deciding to add more capability to the task queue and internally use it to build cron jobs. This example demonstrated how I accepted feedback graciously and went further to support that initiative, eventually building a solution that superseded both proposals.
suboptimal: WD code onboarding -> I wanted to fork off and delete files and history for vendor. Abhi mentioned this would cause issue for debugging for our partner. He then investigated and found out alternatives to git filter branch that can work for us. I was excited to know of this and we decided to go that route.
You helped someone outside of your team to succeed.
Docker system -> After I moved to operations team in dragons, I realized the challenges they were facing with local dev. I used my past experience to build out docker image + VS Code and roll it out to my team. I then shared this to another game team. Their manager got interested, and I joined one of their eng sync meeting to give a demo and talk about it. After that, I worked with their engineers to set it up for them, roll it out, and suggest other areas they can use to enhance their productivity. They built out similar systems for their other services and strongly impacted their productivity and story points.
Kickstarter -> Kinda team oriented but outward looking.
BQ Training
Give an example where you disagreed and committed
LR -> I disagreed that JS is a good choice, but my manager suggested JS can be useful for hot deployments. Based on my experience in the previous game team, I wasn’t still convinced. However, we decided to try out his approach and give that flexibility to the team.
CI project staffing -> Post Chef, the company decided not to invest in tech that didn’t yet have a customer. I disagreed on the fact that building those tech takes time and severely hurts our time to market when needed. However, our leadership insisted that we focus all our efforts on finding the product market fit since w/o that time to market won’t matter. I disagreed but committed strongly. Discussed with my team and motivated them by explaining how our focus now should be to help the company ASAP and simultaneously keeping up our expertise to jumpstart those projects at the first sign of product market fit. We kept a weekly sync where people would discuss the tech stack, solve potential tech debts they anticipate can reduce their velocity when working full time again on those projects.
An example where you made tough decisions without a long delay
LSP shard vs. batching -> Identified the problem; time was short, discussed with PM and EM explaining the pros and cons to get quick buy-in and start on the project. I led those discussions thoughtfully, making sure everyone who needed to be there was there. I presented all the challenges in that meeting to avoid repeated discussions.
BQ cost -> Understood the challenge, did data crunching, and made sure to loop in DS lead and Finance and move forward.
When you made an informed decision but were open to failures
BQ Cost project -> Did data crunching but was aware it could go off. Built incremental system to mitigate a failure situation.
LSP -> Redid the calculation to estimate 20+ QPS. I knew this might not be enough in some instances, but I decided to roll with it and figure it out once we do it. For 99% of cases, this will do fine, and for the rest, 1%, we will solve once we identify why this is happening.
When did you show vulnerability to find the truth or a solution
SS migration issue -> I apologized for not being aware that my stakeholder was changed; I took on extra responsibility to help them build trust and reduce some headaches for them. This way I was able to show them my side to be an ally and gain their trust. They then committed to working with the team closely and gradually transition to our system over the next 6 months.
Cron job -> Engineer pointed out -> I asked questions to know more and mentioned that it’s a good idea and I would like to explore more -> Invited the author to discussion and eventually built a better design overall.
Have you ever given feedback to others
Feedback to DU -> Sol’s issue
Stakeholders management to Soul
Juan -> Communication: Why not to say “When I was in the team, things were so better xyz” but instead try to understand the current situation, use their experience to figure out how to improve the situation and share it to the team.
Yu Guan -> Strong opinions weakly held. He strongly believed his approach was the best. It had its merits but his opinions held him back from understanding that best tech isn’t always the best product for a customer.
Tech:
Long running task: API server is good but it doesn’t fulfill the use cases such as how do we stop faulty task.
BQ pipeline: Engineer’s proposal was to work on the same zone and incrementally deploy it. I suggested this will cause a lot of overhead and risks. Instead why don’t we do in a different zone and keep deploying changes to a parallel system and monitor. When we are ready, we simply flip our users to use the new system while we reverse monitor before full deployment
Share a few situations where you received feedback and how you reacted.
Approaching in meeting -> My method of asking questions was too direct and jr engineers were intimidated due to it. I worked with my manager to identify a recent situation for me to understand better. Read a few books like How to make friends; identified a role model (our COO) who is very direct but sounds approachable and modeled his behavior. I am glad I got the feedback before it caused a bigger issue.
Tasking system for Cron feedback.
Leading India initiative - Stakeholders were CFO, VP HR and others. I was worried to not step over them and was relying excessively on them. HR vp one day said this in front of others that as a lead of the initiative, it’s my job to guide them and assign the right tasks and not rely on them to figure it out. Since then, I started learning more about what their expertise were and in subsequent meetings, I did a better job gathering updates from them and concluding what we all need to do next.
Example where you took ownership
Kickstarter -> Client engineer not interested in maintaining backend; rollouts were difficult for our team; an opportunity to improve and take ownership
Docker system
Event tools
Did you ever question the status quo and how?
Kickstarter
Superset -> Everyone using different system; knowledge was lost when people switched team/company; no way to see coherent data; personally also annoying since I couldn’t see how company is doing. I brought this up by meeting with our CEO on office hour and proposed him a unified system. I then reached out to my manager and DS lead with the idea to start pushing for it. 7-8 months later we are using Apache superset across the company and function.
Event Tools
