In this Medium Post, we’ll talk about how to prepare and do well in a “project presentation” or “technical retrospective” type interview. Typically in this scenario you’ll be asked to prepare a set of artifacts that help you present something technical that you worked on in the past. These types of interviews are called many different things (but they’re effectively very similar):
- Technical Deep Dives or (“Reverse Pirate”): Often you’ll be interviewed on some technical initiative of project that you led in the past. Part of this interview can be categorized as a behavioral question because they offer the interviewer the ability to probe on your prior experience and require many of the similar principles in this doc, even if they can be technical in nature.
- Technical/Project Presentations: Often you’ll be asked to prepare some artifact (e.g. Slides).
Selecting the technical project
It’s important that you select a technical project that is extremely deep and can showcase your strong understanding and decision-making. The project needs to be difficult and challenging in multiple technical ways. It should be the type of project that more junior engineers can’t handle, so you can showcase your technical prowess.
Here are some technical dimensions of “difficulty”. Try to pick your technical project that is difficult along multiple of these dimensions.
(1) Scale. Your technical project needed to scale (which would make it more difficult).
- Ex: It requires special type of sharding/partitioning, replication, etc.
(2) Availability/Reliability. Your project required some challenging type of availability or reliability that is not trivial.
(3) Latency/Throughput. Your project required some type of special latency/throughput that made it challenging.
(4) Customers/Business. Your project had some especially difficult or challenging customers/stakeholders/business requirements.
(5) Security/Privacy. Your project had some security or privacy constraints that added a great deal of complexity to it.
(6) Multi-modal/factorial. Your project involved many very disparate systems working together (e.g. mobile + ML + infrastructure, etc.)
Merging/Consolidating Projects
Note: if the technical projects you’ve worked on are only complex in one of the above ways, you can combine them together to form a more complex project to present.
- Ex: You worked on multiple experimentation products, one that allows you to set up an experiment (aka Gatekeeper or Quick Experiment) and the other that lets you analyze an experiment (aka Deltoid).
- Let’s say the first product has crazy scale (1) and availability (2) requirements, and the second had challenging stakeholder (4) and security (5), you can combine these two projects together.
- You can frame the technical deep dive as building an entire experimentation product suite end-to-end that has four separate complexities (1, 2, 4 and 5).
Projects to Select vs. Avoid
In my experience, there are a few “categories of projects” that I think generally make good projects to select, and a few that i think you should avoid.
Great Projects to Select:
- 0 → 1 and then 1 → 10 Projects: These are great projects to discuss because they typically involve interesting tradeoffs.
- Well Known Projects: Projects whose complexity is publicly well-known are great projects to discuss. For ex: Building News Feed at Facebook, or Ethereum wallets at Coinbase, etc. These will help save you from having to explain context on the project to the interviewer, as they will likely already intuit the importance and complexity.
- Platform Projects: Projects on top of which other engineers need to build, provide really interesting discussion points.
Types of Projects to Avoid:
- Migrations: Migrating from one system to another generally appears less impressive to an interviewer than it does to you. The reason is because the complexity of a migration usually comes from operational overhead, ensuring feature parity, and backfilling. To an interviewer without much context on the complexity of your existing system, this will not appear as impressive/complex as it really was.
- Simple Features: Implementing simple features within a product (e.g. add a UI component, etc.) often don’t appear as interesting for an interviewer, because for them to intuit the impact of the simple feature, they’d have to have a deeper understanding of your prior company’s product suite.
Preparing Artifacts
You’ll likely want to prepare one or more artifacts, while also not making it appear too rehearsed. You can either create a set of slides or use a white boarding tool like Excalidraw.
Excalidraw or Lucid
If you’re using a product like Excalidraw or Lucid, I recommend to have a full version of your diagramming already pre-drawn out and open in a separate window during the interview. This will allow you to quickly have a “north star” that you’re diagramming towards and you can reference it during the interview.
Slides
If you do prepare a set of slides, keep it simple and make sure you talk about the business context first as well as the constraints/challenges of what you’re building.
Technical Choices
Be prepared to talk in depth about all of the key technical choices you made. If you’re not sure about a given technical decision (and aren’t able to explain it) utilize ChatGPT to find out more details as needed.
- Ex: If your technical project used a technology (e.g. Simple Queue Service), but you’re unsure what the alternatives (e.g. Service Bus, RabbitMQ, Kafka, etc.) were and why that was selected, you can prompt ChatGPT to learn about the details.
- ChatGPT Prompt: “I’m trying to find a technology to handle queueing for my consumer web app. The existing app is on the AWS stack, what technologies can I use besides Amazon SQS?” → ChatGPT will give you some answers/thoughts.
During the Interview
During your interview, keep a few things in mind:
- Zoom in or out as needed. Read cues from your interviewer and be able to zoom in and out regarding the level of technical detail your interviewer wants from you. Offer to talk about things in more detail as needed.
- Use structure, number your lists. The similar rules apply to behavioral interviews — try to use numbered lists and structure to navigate the conversation efficiently.
- Offer specific discussions as needed. Offer to go into more detail on specific areas of the project to your interviewer as needed.
- Terminology and Technical Decisions. Be prepared to explain any terminology that arises as well as technical decisions. If you say your project used X, be prepared to explain X and why did you utilize X.
- Time Management. Keep an eye on the clock to make sure you have enough remaining time to cover more interesting aspects of the interview.
