4.1 KiB
| id | title |
|---|---|
| star-format | STAR Format |
What is STAR?
The STAR 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.
- Action - What did you do? The interviewer will be looking for information on what you did, why you did it and what the alternatives were.
- 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?
Example
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".
Situation
"I was the team lead of a school project about building a social network mobile web app. Our designer's mid-terms 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."
Task
"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."
Action
"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 mid-term dates were out of the designer's control and we had to be more understanding about each others' 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 mid-terms 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 mid-term, by <DATE>."
Result
"When our designer ended mid-terms, 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."
Qualities
Through the above, experienced interviewers can extract the following qualities from the mentioned behaviors.
- Empathy - Empathize with both roles and made sure to understand each individuals’ reasons
- Willingness - to wear multiple hats: Picked up the role of the designer and came up with wireframes
- Project management - Able to unblock the project by changing approaches midway to great effectiveness
- Conflict management - Explain to parties involved in conflict and make sure no hard feelings remain
- Hold people accountable - Get a confirmation date as to when the designer can produce the mockups and hold him accountable