Personal STAR Interview Cheat Sheet
When interviewing for a technical role, you will be asked to provide examples of previous projects either directly or within the context of a behavioral question. In this post I will go over how to build a “cheat sheet” for your personal projects to help you make the biggest impact in your interviews. This post will not tell you how to answer STAR questions and describe a specific technique to help in these interviews.
Behavioral or past-project interviews
Behavioral or STAR (Situation Task Action Result) interviews ask you to provide an example of a situation where you took some action as well as what you achieved. Here are examples of questions I received as part of an interview preparation package from my most recent job hunt:
- Tell me about a project you’ve executed recently that you are proud of
- Tell me about a time when you had to work with a difficult stakeholder
- Tell me about a time when you had to go over the project timeline
- What is an example of a project where you had to work with different types of stakeholders?
- What is an example of a project where you’ve had to make tough decisions?
Past-project or project showcase interviews are interviews where you're asked to present a previous project you worked on either in a short, verbal form or as a presentation via slides or a write-up.
In both of these cases, the context (S of STAR) and impact (R of STAR) are key to highlighting your experiences. A common mistake in these interviews is not providing sufficient, hard data to make your answer convincing and relevant. Part of a good interview preparation plan is to get these numbers and be able to provide them immediately during the interview.
The Cheat Sheet
You can create a cheat sheet of project context and impact to help you build and quickly recall supporting data for your interviews. My cheat sheet is copied on to 2 large post-its on my monitor during interviews. Example cheat sheet:
| Project | Role | Project team size | Project Timeline | Impact | Collaborators | Scale |
|---|---|---|---|---|---|---|
| CICD | Technical lead | 3 engingeers | 3 months | 0.5 million /year | Manager, Product, QA, Leadership | 20 deploys per year -> 20 deploys per week |
| Wishlist | Design and delivery | 5 engineers | 6 months | 10 million/year | Lead, Manager | 2 million customers, 200 RPS |
| Security Committee | Security Lead | 50 person org | Continuous/2 years | Legal Compliance | Legal, Managers, QA | 3 reviews per month |
| Save as Draft | Implementation | 4 engineers | 2 months | 100k/year | Lead, Manager | 10k customers,10 wishlists per day |
Definitions:
- Project: a name for the project you can remember
- Role: Roughly your responsibilities - did you design, lead, code, etc.
- Project team size: present your team size for who you worked with regularly to deliver the project. This is particularly important for lead roles to provide a signal of the size of your leadership, influence, and ability to delegate.
- Project timeline: describe how long the project took as well as what your starting point and end point was. For example, "I was on this project for 6 months and I worked on it from design to launch" or "I was on this project for 2 months and was brought on midway through implementation to get the project back on track through to launch".
- Financial or business impact: an estimate of the money saved, made, or general business impact of the final product.
- Collaborations: other roles you interacted with external to the core project team. This could be organization technical leaders like directors or principal engineers, QA team, UX team, legal team, stakeholders, product experts, customer support - anyone that isn't on your core team.
- Scale: how many customers you have, how much traffic you have, or any other measure to help describe how much usage, scope, or users the project impacted.
Here is an example:
I worked on a project to migrate my team's delivery process from a manual, bi-weekly release to a CI/CD (project name) pipeline for my team of 5 engineers over the course of 3 months (project length). I initiated the project as the technical lead (role) and continued through to implementation, delegating tasks to 2 other engineers on my team of 5 (project team size). I worked with my manager and technical leadership (collaborators) to get buy-in for the project and the operations (collaborators) team to ensure optimal use of internal tooling. Overall, this ended up saving 2 days of developer time per sprint, the equivalent of 10 dev weeks per year (impact) by supporting 20 deployments a week from 20 deployments a year (scale).
How do I get this data?
The best way to get this data is to note it down while you're working on the project or as a project retrospective. However, if you've already left your job and are trying to look back to get these numbers you can:
- Do your best to recall the entire project as a whole to jog your memory on the details
- Reach out to old coworkers to help you remember the project context (without putting them at risk of sharing confidential data)
- Find public information about the project you worked on
Some tips to coming up with financial numbers:
- Convert saved developer time into money saved per year by using hours saved + average salary
- Look up tech blogs or conference talks related to the same or similar topic and convert their impact numbers to map to your project
- Do domain specific research to find market numbers to describe potential impact
There are cases where financial numbers don't work like with regulatory compliance and human safety. You can actually find data on fines for non-compliance but often if you just say "regulatory compliance" or "human safety", that's enough.
If you're worried about what is or isn't public information, you can go to your company's blogs and press releases to identify what's safe to share. Here are some examples from my career:
- Wayfair supplier numbers: "Wayfair is one of the world‘s leading home goods brands, offering 14 million items from more than 11,000 global suppliers" for my work on Wayfair's supplier APIs.
- Amazon safety numbers: "Over the past five years, the rate of MSD [musculoskeletal disorder] recordable incident rates at Amazon has improved 32%, but they still make up about 57% of all recordable injuries at Amazon" for my work on Amazon's employee health and safety ergonomic risk assessments.
Good luck!
With some math, memory, and creativity, you can come up with a cheat sheet of context and impact numbers that can highlight your professional experiences and turn you into a stand-out candidate. Best of luck on your next interviews!