The [STAR](https://en.wikipedia.org/wiki/Situation,_task,_action,_result) format is a framework to help you organize your experience into sections that flows nicely. From Wikipedia:
- **Situation** - The interviewer wants you to present a recent challenge and situation which you found yourself in
- **Task** - What were you required to achieve? The interviewer will be looking to see what you were trying to achieve from the situation. Some performance development methods use "Target" rather than "Task". Job interview candidates who describe a "Target" they set themselves instead of an externally imposed "Task" emphasize their own intrinsic motivation to perform and to develop their performance
- **Results** - What was the outcome of your actions? What did you achieve through your actions and did you meet your objectives? What did you learn from this experience and have you used this learning since?
Here's an example of how the STAR format can be used to answer the question: **"Tell me about a time in which you had a conflict and needed to influence somebody else"**.
> "I was the team lead of a school project about building a social network mobile web app. Our designer's midterms were approaching and didn't have time to produce the mockups. Our front-end person was rushing him for the mockups so that he could proceed with his work, and that was stressing the designer out. The atmosphere in the team was tense."
> "As the team lead, I had to resolve the tension between the front-end developer and the designer so that the team could work together peacefully and complete the project on time."
> "I spoke to the front-end developer to ask him why he was rushing the designer for the designs. He said that he wanted the designs early because it would be a waste of time rebuilding if the designer designed something different eventually. I explained to him that the midterm dates were out of the designer's control and we had to be more understanding about each other's schedules.
> I spoke to the designer to get a rough idea of what he had in mind and asked him when he could commit to producing the high-fidelity designs. He replied that he could start on them as soon as his midterms were over. I explained to him why the front-end developer was pushing him for the mockups, and that the front-end developer had no ill intentions and simply wanted the project to succeed.
> As someone with some experience in UI/UX design, I came up with wireframe mocks, ran them by the designer for approval, then passed them to the front-end developer to start building. I encouraged the front-end developer to use placeholders and not be too concerned about the details for now. We could build the non-UI parts first (authentication, hook up with APIs) and tweak pixels and add polish later on. The front-end developer agreed and went ahead with the approach. I explained to the front-end developer that the designer will pass us the mockups after his midterm, by <DATE>."
> "When our designer ended midterms, he came back with beautiful mockups that fit well into the wireframes. Our front-end developer implemented them with great care to detail. We ended up scoring top marks for the project and became a great team."
