What is the STAR Principle

The STAR principle is an acronym for Situation, Task, Action, and Result.

The STAR principle is commonly used in writing resumes and quarterly summary reports to describe past work. Before I prepared to submit my internship resume in March 2015, the resume I wrote felt very “amateurish and student-like”, failing to highlight key points and lacking any quantified achievements. So Qin (a senior) from the ACM lab and several other seniors guided me step-by-step to refine my resume. The single most important resume-writing method they suggested was using the STAR principle to describe each development project experience. Although the resume written using the STAR principle ended up being as long as 4 pages, it barely managed to help interviewers grasp some key focus points. (Of course, later during the autumn campus recruitment, I hit a setback because I placed too much emphasis on project experience and didn’t practice algorithm problems. So refining your resume is only the first step—you need to be strong yourself. Make sure to prepare the necessary technical fundamentals (“ba gu wen”) and algorithm problems first.)

Using the STAR Principle for Summary Reports

It’s recently that time of year again to write the semi-annual performance review document. Because I usually document as I go—especially making a habit of recording result data—writing the review document is just a matter of copying, pasting, and polishing. Even though GPT can assist with copywriting nowadays, taking quick notes on the job saves a tremendous amount of time and energy. Plus, great documentation can be shared with others to boost your influence in the team—why not do it?

Situation

In the Situation section, you can write about the problems faced or competitor research findings, analyze the external context, and describe internal current conditions and issues.

The situation should include fundamental information such as time, location, and background, or can be described directly using the 5Ws. For example: During the preparation phase for Singles’ Day (Double 11), our competitor was preparing a grayscale rollout of Feature XXX in the Beijing area, but our system lacked Feature XXX.

Task

Then, outline clear goals, tasks, and measures tailored to the situation described above.

For example: To prevent a drop in GMV during Singles’ Day due to the missing Feature XXX, we conducted an emergency feature benchmarking and launched Feature YYY on a specific date, aiming to increase GMV by Y% and average order value (AOV) by Z%.

Action

Based on the aforementioned situation and task, describe what actions were taken to solve the problem. In this section, you can also highlight the difficulties and challenges encountered, as well as your breakdown of and thinking behind these challenges. Just like when an adversary or challenge appears in a script, readers or audiences immediately perk up and look forward to the protagonist’s brilliant resolution.

For example: After receiving the task to develop Feature YYY, explain how the task was broken down, how much time, resources, and which methods were used to complete it, along with the difficulties encountered and their solutions.

Result

What was the outcome of the actions? If successful, what valuable and transferable experiences can be extracted and generalized, and can they help reach a higher level in future similar tasks? If it failed, what was the reason, and how can failure be avoided in subsequent actions?

The result is about showcasing your work in a language of [quantified numbers], bombarding the reader’s retina with big, red, bold text. However, it also requires analyzing the results, providing concrete explanations, and distilling accumulated experience.

Going a Step Further

Of course, using only the STAR principle to write summaries is not enough; it often lacks [deep thinking]. How do you stand out among a sea of workaholics (“juan wang”)? The answer is not to join the rat race or mindlessly fulfill every incoming requirement, but to create differentiation. This so-called differentiation comes from the insights distilled through in-depth [analysis] and [reflection] on technology and business.

So, can you analyze the project you are currently working on using the STAR principle? How effective is it? Is there room for further improvement? Can the experience from this project be transferred and applied to other projects? Has the project contributed to your technical growth and overall capability? If so, have you documented and preserved these insights? Would you consider sharing them within your team? What additional support do you need from the team? Are there similar problems waiting to be solved in other related projects across the team?