// Transforms completed work into STAR interview stories (Situation, Task, Action, Result). Use when completing tasks, preparing for behavioral interviews, or documenting achievements.
| name | star-story-extraction |
| description | Transforms completed work into STAR interview stories (Situation, Task, Action, Result). Use when completing tasks, preparing for behavioral interviews, or documenting achievements. |
"Every feature you build is an interview answer waiting to be told."
Transform completed work into compelling interview stories using the STAR method. These stories demonstrate real problem-solving ability.
| Component | Question | Focus |
|---|---|---|
| Situation | "What was the context?" | Set the scene, explain the problem |
| Task | "What were YOU responsible for?" | YOUR specific role and responsibility |
| Action | "What did YOU do?" | Specific technical actions YOU took |
| Result | "What was the outcome?" | Impact, metrics, improvements |
What kind of problem did you solve?
| Story Type | Good For Questions Like |
|---|---|
| Technical challenge | "Tell me about a difficult bug you solved" |
| Feature implementation | "Describe a feature you're proud of" |
| Performance optimization | "How did you improve system performance?" |
| Security fix | "Tell me about a security issue you addressed" |
| Refactoring | "Describe a time you improved code quality" |
| Learning curve | "Tell me about a time you learned something quickly" |
"What was the context? What problem or challenge existed before you started?"
Good elements:
Avoid:
"What were YOU specifically responsible for? What was your role?"
Good elements:
Avoid:
"Walk me through the specific steps YOU took. Be technical."
Good elements:
Avoid:
"What was the outcome? Can you quantify the impact?"
Good elements:
Avoid:
# STAR Story: [Feature/Problem Name]
**Date:** [When completed]
**Type:** [Technical Challenge / Feature / Performance / Security / Refactor]
## Situation
[The context. What problem existed? Why did it matter?]
## Task
[YOUR specific responsibility. What were YOU asked to do?]
## Action
[The specific steps YOU took. Be technical. Show your thought process.]
## Result
[The outcome. Metrics if possible. What impact did it have?]
---
## Interview Variations
This story can answer:
- "Tell me about a time you [X]"
- "Describe a challenging [Y] you worked on"
- "How did you approach [Z]?"
## Key Technical Points to Mention
- [Technology/pattern 1]
- [Technology/pattern 2]
- [Decision/trade-off made]
"I built a login form. It had validation. It worked."
Problems: No context, no challenge, no depth, no impact.
Situation: Our SaaS application was experiencing a 40% drop-off during signup because the existing form had poor UX and no real-time validation, frustrating users.
Task: I was responsible for rebuilding the entire authentication flow, focusing on reducing friction while maintaining security.
Action: I implemented a multi-step form with real-time validation using React Hook Form for performance. I added JWT authentication with secure refresh token rotation to handle long sessions. The key challenge was balancing security (short token expiry) with UX (no jarring logouts), which I solved by implementing silent refresh 5 minutes before expiry.
Result: Sign-up completion improved by 35%, and we've had zero authentication-related security incidents since launch. The pattern I built is now used across our other products.
Guide the junior with these:
| Mistake | Fix |
|---|---|
| "We built..." | Use "I implemented..." |
| Too long (10+ minutes) | Cut to 2-3 minutes |
| No technical depth | Add specific technologies and decisions |
| No result | Always end with impact |
| Only happy path | Include challenges overcome |
Stories are saved to:
ownyourcode/career/stories/[date]-[feature-name].md
Example: ownyourcode/career/stories/2026-01-15-jwt-auth.md
Transforms completed work into powerful resume bullet points with action verbs, technical context, and quantified impact. Use when completing tasks, updating portfolio, or preparing job applications.
Reviews accessibility including WCAG, ARIA, keyboard navigation. Use when junior builds forms, buttons, modals, interactive elements, or asks "is this accessible", "a11y", "screen reader".
Reviews API design, REST conventions, and backend architecture. Use when junior builds API endpoints, Express routes, middleware, controllers, or asks "is this RESTful", "check my endpoint".
Reviews schema design, SQL queries, ORM patterns. Use when junior creates schema, writes queries, adds migrations, works with Prisma/MongoDB/PostgreSQL, or asks "is this SQL safe", "N+1", "index".
Guides systematic debugging through Protocol D (READ, ISOLATE, DOCS, HYPOTHESIZE, VERIFY). Use when junior says "stuck", "not working", "broken", "bug", "error", "crashed", "failing", "can't figure out", or expresses frustration. Do NOT use for general questions.
Guides documentation standards including READMEs, JSDoc, and code comments. Use when writing documentation, adding comments, or explaining code. Enforces "WHY not WHAT" principle.