The STAR method for interviews, with worked examples

Situation: In my final year, our team of four was building a crop-disease detection app, and two weeks before the demo we found that a third of our training images were mislabelled.

Task: I was responsible for the model, so it fell to me to fix the data without missing the deadline.

Action: I wrote a small script to flag images where the model was most confident but wrong, which narrowed the problem to about 600 images instead of all 2,000. I split those between two of us to relabel by hand while the others kept building the app, and I retrained the model every night so we could see whether accuracy was moving.

Result: We demoed on time, and accuracy went from 71% to 84%. The bigger lesson for me was to check data quality first, which I now do before writing any model code.

Situation: At my last company, a client moved their go-live forward by a week, and our reporting module was still half built.

Task: I owned that module, so I had to deliver it in four days instead of eleven.

Action: I listed every report the client had asked for and agreed with them which five they needed on day one. I built those first, reused our existing export code instead of writing a new one, and asked our tester to test each report as soon as it was done rather than all at the end.

Result: All five reports went live with the launch, with no defects reported in the first month, and the remaining reports followed two weeks later. The client renewed the contract that quarter.

Situation: On a website project, a fellow developer and I disagreed about whether to build our own login system or use an existing service.

Task: We had to decide within a day, because the rest of the sprint depended on it.

Action: Instead of arguing in the stand-up, I suggested we each write down the cost, the risk and the time for our option, and then test the riskiest part of each for two hours. I also asked our lead to look at the result so it wasn't my opinion against his.

Result: The existing service was clearly faster and safer for our case, which was his option, so we went with it. We shipped on time, and I've used that write-it-down approach for every technical disagreement since.

Situation: In my first year as an analyst, I sent our sales director a weekly report that used the previous month's targets.

Task: I had to correct it before the regional review that afternoon, where the numbers would be discussed.

Action: As soon as I noticed, I called the director's assistant, sent a corrected version within the hour, and wrote a short note explaining what had changed. Then I added a check to the report that compares the target month with the report month and warns if they differ.

Result: The review used the right figures, and the check has caught the same problem twice since, once in a colleague's report. My manager asked me to add it to our team's template.

Situation: Our college's annual technical fest lost its sponsorship lead a month before the event, and we were short of the budget by about a third.

Task: I was a volunteer, not on the committee, but I offered to take over sponsorship.

Action: I made a list of local companies that hired from our college, wrote a one-page proposal showing how many students attended last year, and split the list among four volunteers with a short script for the calls. I met every interested company in person with a committee member.

Result: We signed six new sponsors and covered the full budget a week before the fest. The committee asked me to lead sponsorship the following year.