Engineer Past Projects Deep Dive

Why Are We Doing This?

Most of our interviews are simulations of work. The problem with a simulation is that it requires you to work through a problem with extremely artificial time constraints and little context.

Going through one of your past projects allows us to see what you would actually do on the job—like how you gather information, make decisions, plan work, and deal with time constraints or setbacks.

The Interview

We’ll walk through past projects two times during the interview process:

1. The first time will be in your introductory call with one of our engineering leaders. We’ll spend about 10 to 20 minutes on it.
2. The second time will be in the final round. It will be with our VP of Engineering and another engineering leader and will last 30 or 45 minutes, depending on your level of experience and seniority.

We’ll ask you to lead, and we’ll stop you for questions along the way. We might go very deep into pieces we find interesting or ask you to repeat or rephrase things we couldn’t understand. It might derail your explanation, but we’ll do our best to bring you back to where you left off.

You are welcome to use the same project throughout the interview process. The final round gives us more time to dig into the details—just make sure there’s enough to cover the length of time we have scheduled.

You are welcome to use diagrams or slides if they help you. We don't expect you to, and you don’t get bonus points for doing so (or not doing so). Use them solely if they help you communicate and help us understand. If you use slides, they can be as simple as black text on a white background.

If you’re unsure about which project to choose or simply want to put your best foot forward, ask your hiring manager. They’re happy to help, and we won’t ding you for asking. Send over a couple of ideas with 1-2 sentence descriptions or ask for 15 minutes with your hiring manager. This has sometimes helped candidates pick a better project!

Expectations

The project you present should be one that you led and made critical decisions for. Additionally:

• There were ambiguous challenges that required creative solutions (this is subjective, but we like projects with interesting abstractions, for instance).
• You led the technical decision-making and implementation, and you can describe them in great detail (e.g., details about data models).
• You can speak to both the business context and technical architecture. You can explain how customer or business needs influenced your technical decisions (we get excited when you also make product decisions!).
• You’re able to explain why important decisions were made, including technology choices, tradeoffs, testing, and reliability considerations.
• You can remember details like properties on a data model, timelines for milestones, customer reactions.

We’re particularly interested in understanding:

• How you scoped the problem and defined success
• The architecture and technology stack
• Key decisions and their tradeoffs
• How the project fit into the broader technical and business landscape
• Any interesting challenges or lessons learned during development or after release
• How long it took to reach important milestones and why that time was necessary

Here are a few helpful prompts to think about as you select your project(s):

• What’s a project you’re most proud of?
• What’s the most technically challenging thing you’ve worked on recently (enough that you can remember key decisions and technical details)?
• If a project that comes to mind is more internal-facing, have you worked on something that impacted developer productivity, monitoring and reliability, or involved a build-vs-buy decision?

Effective communication is an important skill we’re assessing in this interview. You may have an impressive project, but it doesn’t matter if we can’t understand it. While we’ll ask questions, you should still decide where context is necessary and where it isn’t. Your interviewers will be technical, so you can assume they’ll understand basic technical concepts.

No slides or formal prep are required. We’re just looking for a thoughtful, easy-to-follow conversation about your experience. Some folks do find it helpful to put diagrams or slides together. Sometimes it’s easier to describe a complex system or data model and its relationships through a diagram. Some folks are a bit nervous unless they have a talk track they can reference, and slides can help. Do what’s best for you to communicate your project effectively!

Examples

Here are some quick descriptions of projects that have received perfect or close-to-perfect scores from us:

• An engineer identified that their product’s script language was challenging for customers to use and for them to maintain. They worked with Product to prioritize it and led the migration to a new scripting language. They investigated alternative languages, and proposed a solution that was well-justified. They implemented a language parser, an automated migration path from old to new, and, for exceptions, worked with Customer Success and Support to communicate with customers and perform a manual migration. They could speak about the benefits of the language, alternatives, and why they discarded the alternatives.
• The engineer automated a lot of the detective work that happens during an incident/page. The engineer saw a problem and took initiative (versus waiting for approval). The engineer showed a great understanding of the problem and empathy with end-users, especially those less skilled than they are. They broke the problem down into small deliverable chunks and delivered incrementally.
• The engineer was tasked with adding a set of features to a product to help it scale to larger customers. They spotted the opportunity to create an abstraction, advocated to rebuild the product on this abstraction via a prototype, and developed the first version of a workflow engine for their company. They understood customer needs deeply, predicted requirements that would come up later, and provided examples of other features in the product using their workflow engine.

Projects we’re much less interested in:

• A project that is primarily CRUD without interesting abstractions, data model decisions, or technology decisions.
• A project that was partially released or where you left before it was released. It’s hard to know the outcomes of your decisions if you didn’t see them firsthand.
• A project that didn’t have much ambiguity or require much creativity, but instead required coordinating across multiple teams. These projects are usually valued by Engineering teams that are heavy on process or coordination; we are not that team.
• Migration projects from one technology to another. While technically interesting, these kinds of projects rarely involve product or business-driven technical decisions.
• A project that primarily navigates company politics, a subpar team, and/or convincing centralized authorities that something should be done.
• A project that didn’t make an impact or was driven by poor decisions out of your control. While you may have executed flawlessly, it’s hard to see the impact of your work if it wasn’t the right project to work on for the business.