Project Retrospective Example

Here's an example of a project retrospective, along with some example follow up questions.

Interviewer: "Tell me about a project you're proud of."

"When I was an engineering manager at my previous company, my team launched a notifications service for our web and mobile products. Based on earlier customer research, we believed this feature would increase user retention, which was one of our company's main KPIs. This was a particularly challenging project due to the technical complexity of the feature, the velocity of the timeline we were aiming for, and the tight collaboration required across engineering teams that hadn't previously worked together.

There were a few main components of the project. We had to design the backend service and API that would handle fetching and sending notifications with minimal latency. We had to implement the storage layer that would handle reading and writing the notifications for each user. Finally, our team also helped build the interface for the feed to display notifications, which would highlight unread notifications and handle deep linking to the correct place within the application. There were some interesting technical challenges to all of these components that I can go into in more depth.

In the end, the project was very successful. We shipped the project a week ahead of schedule, and the feature had an even greater impact on our key metrics than we had expected, with customer retention increasing by 20%."

Explanation

In this first part of the discussion, the interviewer is looking for a high-level explanation of the project. This answer does a good job of setting the stage for further questions by explaining why the project existed, what it was, and the overall outcome of the project.

Interviewer: "What made this project technically interesting or complex?"

"There were a number of complex parts of the project, but scalability and performance were the most challenging in my opinion. The notification feature would be used throughout the application on multiple platforms, so there could be millions of active users for this feature. Our engineers had to think about scalability from the beginning.

In particular, we had to handle a high volume of API requests and optimize the response latency to make sure users have a good experience in our application. To understand the load requirements more, we calculated estimates based on historical data and projected the number of active devices, which came out to around 300 queries per second. Since that's on the higher end, I asked our tech lead to talk with our infrastructure team and understand if there would be risks of overwhelming any downstream services or exceeding our server capacity. Based on their feedback, we determined that the volume of read queries would be too high for our databases to handle, so we decided to add a caching layer to mitigate those concerns.

Things weren't quite that simple, though. We knew our database would be overwhelmed if we used it to serve every read request, but our in-memory caching service also didn't have the space to store every notification either. In the end, our team made a tradeoff where new notifications would be served from the cache while older notifications would be handled by the database. To manage space, we used a least recently used cache policy so that older notifications would be replaced by newer ones as needed. Since notifications are typically read soon after being created, we also used write-through caching to ensure the initial read could be served from the cache rather than the database."

Explanation

This response clearly explains the technical tradeoffs involved in building the feature described. While the specifics will vary for your story, it's important to demonstrate that you understand the technical details and can explain the rationale behind them like this.

Interviewer: "How did you set up your team for success with this project?"

"It's important to me that my teams succeed both in terms of execution and the personal growth of the people on the team. At the start of this project, I chose a senior team member who previously expressed interest in opportunities for leadership. I thought this project would be a particularly good growth opportunity for her based on her skill set and interests, so I asked her to be the tech lead for this project. I also set aside extra time for us to talk about what success means and set expectations around the outcomes of the project.

From a process perspective, I'm especially proud of the way we brought multiple teams together to solve problems. Since the engineering work spanned across several platform teams, I felt it was important to tighten the feedback loop with a process for regular communication. I set up regular weekly syncs to review progress with the whole team, and our tech lead ran daily standups to keep everyone on the same page. These meetings ended up being critical to the success of the project because we were able to identify dependencies earlier on and parallelize our team's work instead of waiting for each engineer to complete their part of the project.

In order to make sure our team had the resources and focus needed to complete the project, I also created a process for prioritizing inbound requests from other teams. This prevented a lot of thrash and interruptions caused by non-urgent requests, which saved us several hours per week."

Explanation

This answer does a good job of explaining what success means — in this case, project execution and personal growth — and then describing the process for each of those. These also map to project management and delegation, two important skills for a manager to demonstrate.

Interviewer: "Were there any conflicts during the project? How did you resolve them?"

"There weren't many conflicts within the team, but there was one issue we faced with a partner team. This team owned one of the core database models that we needed to modify in order to implement our feature. Although someone on their team had greenlit our proposed modifications during the planning process, later during the code review process, a senior engineer on the other team brought up additional concerns that could add significant work and risk delaying our team's project.

In order to come to an agreement, we set up time to discuss the set of possible solutions, understand the other team's priorities, and facilitate a solution that worked for everyone. In the end, we found a compromise where we would ship our initial changes to unblock the rest of the project and then iterate to a solution that addressed their main concerns at a later date. One lesson learned here is that we should have spoken to all of the relevant stakeholders earlier in the review process."

Explanation

This answer demonstrates a proactive and empathetic approach to resolving conflicts. Importantly, the conflict is remedied and results in a useful lesson.

Interviewer: "What was the outcome of the project?"

"In terms of the business impact, the project beat our expectations. The overall effect was a nearly 20% increase in user retention following the launch of the project. We were able to attribute most of this impact directly to notifications with the help of our data analysis team.

The project also had a big impact on our team. I felt it brought everyone together and leveled up the whole organization. Our engineers gained a lot of visibility for their work, and several of them were promoted in the following performance cycle, owing in large part to their contributions on this project."

Explanation

This answer addresses two distinct outcomes of the project that managers should care about: the business outcome and the team outcome. The business outcome is backed up with clear metrics and KPIs, while the team outcome is explained in terms of the career growth of the team members.

In the next video lesson, we'll see these put in practice.