I had two hours of phone screens before I was called in for an onsite interview.

They gave me a "director interview scenario" to prepare for in advance, which was supposed to be a panel interview with the team.

However, they suddenly ended the onsite after half the interviews were done, saying I was not a fit.

The experience was negative, not because they decided to cancel in the middle, but because there was nothing I said in those interviews that they could not have asked during the phone screens.

They make a huge deal about their culture and how they get rid of people that are not perfect, and yet they have such incompetent hiring managers who don't even know how to do phone screens properly.

If there were specific, key requirements for the position, you would think they should probe for that experience during the hours of phone screens they subjected me to, and not pretend like they discovered it during the onsite.

They also wasted my time (not to mention theirs) preparing for some stupid scenario, which they never got into at all.

Director Interview Scenario

Your task is to guide a collaborative session with the team where we form a plan around the below scenario. We need not cover every aspect, but there should be a good balance of high-level vs. detail, short-term vs. long-term, innovation vs. risk, and strategic vs. tactical. Examples of things you could consider include staffing, architecture, operations, and quality.

We're looking for someone who has enough grasp of technology that they can use it to solve problems and then organize and align teams around those solutions, while also questioning and helping to shape the organizational vision. At Netflix, we want our interviews to bring out your best. To that end, you have a lot of freedom in how you choose to engage with us. Note that we do not expect an entire presentation prepared ahead-of-time; the intent is to work together to develop a solution and debate it.

The Good

You've been hired as the new CTO of a budding online food-delivery service in the Bay Area. We've enjoyed early success getting three partner restaurants on board and, thanks to timely, accurate food deliveries, customer demand is increasing. We've just raised a round of cash and want to take this to the next level.

The Bad

BizDev has tentatively signed on 5 new partner restaurants. The CEO is looking for metrics on partner performance to better understand where to invest. The Board is discussing expanding into more regions over the next 5 years. All are looking to you for a plan.

The Ugly

The systems supporting the three partners had to be customized for each one's different workflows and business practices. These misalignments lead to mistakes and painful customer support, risking our company's main competitive advantage in a crowded market. The dev team is already stretched thin just supporting the three partner restaurants we already have.

We'd like to spend the first 10 minutes with introductions where you can ask questions and get to know us, the next 45 minutes debating the above scenario, and the last 5 minutes for feedback. That is a lot to ask in a short time, so use your judgment in what you choose to cover and how to make the most of it.

Good luck, we're thrilled to meet you!

Additional Context

Some initial assumptions you can make to save some time:

1. We already have a basic microservice architecture in place on AWS.
2. We have a fleshed-out web app which customers (individual users) can use to order food and pay via Stripe. The order fulfillment process is: a. Our three current partners are small and unsophisticated. We've provided each with an iPad configured with an email client. b. Our system sends emails with order details to partner restaurants and delivery info to a contracted local delivery service. c. Partner restaurants do not communicate directly with customers. If there are any changes, problems, or updates to delivery times, the partner emails us, and we handle communication and charge adjustments manually. d. After delivery, drivers click a special link they received in their email to confirm. This triggers a Stripe transfer to the partner restaurant. i. We don't store card numbers or process payments ourselves.
3. Menu creation is very high-touch: a. Our employees go on-site to partner restaurants and take photos. b. Details are entered into a Google Sheet. c. An engineer manually runs a script to import the sheet into our database. d. Changes require manually tweaking the DB or a re-import of the entire sheet.
4. We have minimal analytics: a. Creating stats requires an engineer to run queries by hand. b. We have a feedback widget on our site; customers generally seem happy. c. Most customers make additional orders. d. Since we only have three partner restaurants and currently maintain a close relationship with each, we can confidently say they are happy. e. Though simple, the system itself is quite stable; unexpected downtime is rare.