STAR stories
Five behavioral stories from your career, structured in STAR format (Situation, Task, Action, Result). Memorize the shape of each — they map to almost every behavioral question you'll get across all four stages.
01How to use this
Each story has a primary mapping (the question it answers most directly) and secondary mappings (other questions you can pivot it toward). When asked anything behavioral, pick the closest story and adapt the framing on the fly.
02Story 1 — Translation infrastructure overhaul
Best for: "Project you're proud of," "biggest impact," "system you architected," "performance work"
Situation
Artlist had grown internationally — multiple locales, with translation files that had accumulated over years. The system was shipping a lot of bytes to the client just to render localized strings, and a meaningful chunk of those keys were dead or rarely used in any given route.
Task
I led an effort to rethink how we organized, bundled, and shipped translations — without disrupting the dozens of teams writing user-facing copy.
Action
- Audited the existing translation files, mapped key usage to actual routes
- Designed a more granular bundling strategy tied to route boundaries instead of one global locale file
- Built tooling to detect dead keys and prevent regression
- Worked with the platform team on edge caching of locale chunks
- Coordinated with content and product teams so the change was invisible to them — same ergonomics, better delivery
Result
Measurable reduction in JavaScript bytes shipped to the client. Faster initial load and locale switching. Cleaner mental model for the team — easier to add a new locale, easier to clean up old keys. The system continues to scale as we add markets, where before it was getting heavier with each addition.
03Story 2 — Solo product: tutorialsearch.io
Best for: "End-to-end ownership," "side project," "what do you do outside work," "scrappy / pragmatic engineer"
Situation
I wanted a project where I owned every layer — not just the part of the codebase I touch at work. Tutorial content on the web is fragmented; nothing aggregates well across sources. I built tutorialsearch.io to scratch that itch and to keep my product instincts sharp.
Task
Build, ship, and run a real product — solo. Frontend, backend, infra, SEO, content ingestion, monetization, all of it.
Action
- Built on a Cloudflare stack — Pages for hosting, D1 as the database, KV for caching, R2 for blob storage. Picked deliberately for cost and edge performance.
- Designed a content ingestion pipeline that aggregates tutorials with proper SEO metadata
- Implemented Amazon Associates affiliate integration with ISBN-13 → ISBN-10 conversion and search-URL fallbacks
- Set up cross-posting to dev.to via RSS for syndication
- Investigated bot-blocking on outbound redirects via Cloudflare WAF rules
- Got affiliate tax forms and payment infrastructure right for an international payee
Result
It's live, indexed, has real users, and generates revenue. More importantly, it's taught me lessons I couldn't get at a job — the cost of every line of infra, where caching actually matters versus where it's premature, what a real SEO funnel looks like end-to-end. That perspective makes me a better engineer at my day job too.
04Story 3 — Memory leak debugging
Best for: "Hardest bug," "debugging story," "production issue," "what do you do when stuck"
Situation
A long-running React page in our app was getting noticeably slower over the course of a user session. Reports came in from internal users — by hour two it felt sluggish, by hour four it was painful. Hard to reproduce on demand because it required real session time.
Task
Find the leak, fix it, and make sure we'd catch the next one.
Action
- Reproduced reliably in a sandbox by simulating long sessions with a script that drove the relevant interactions
- Took heap snapshots in Chrome DevTools at intervals — 10 minutes, 30 minutes, 60 minutes — and compared retained-size deltas
- Narrowed the leak to a specific component subtree by isolating sections
- Found two issues compounding each other: a third-party library was attaching event listeners that weren't being removed, and a useEffect we'd written had a closure-over-stale-state problem keeping references alive
- Fixed both — proper cleanup of the third-party listeners, and refactored the effect to use a ref + functional updates
- Added a long-session memory regression check to our perf testing
Result
Memory growth flattened. Page stayed responsive across long sessions. The bigger win was the muscle memory and the regression check — leaks like this are insidious because they don't show up in normal QA. Now we'd catch the next one before users do.
05Story 4 — Technical disagreement (state management)
Best for: "Disagreement with a colleague," "how do you handle conflict," "convincing someone of an idea"
Situation
A senior colleague and I disagreed about how to handle a piece of feature state. They wanted to put it in our global store; I felt it should live local to a component subtree because the state didn't actually need to be shared anywhere else.
Task
Land on a decision we both could commit to, ideally without dragging the team into a long debate.
Action
- Walked through the actual usage of the state — which components read it, which write it, under what conditions
- Laid out the trade-offs explicitly: coupling cost of going global, testability, future maintenance if other features wanted similar state
- Made room for the possibility I was wrong — what would change my mind? What signals would suggest going global later?
- Proposed: start local, with an explicit migration plan to global if a second consumer appeared. Reversible decision.
Result
We went local. Eighteen months later, no second consumer ever appeared, so the decision held. The bigger lesson for me was about how to disagree productively: focus on trade-offs, not preferences. "I prefer X" doesn't move anyone. "Here's what we give up if we go global, and here's what triggers us to revisit" does.
06Story 5 — Mentoring / raising the bar
Best for: "Mentoring junior engineers," "raising standards," "leadership without authority," anything that asks for senior-level impact beyond your own code
Situation
Our frontend team was growing and bringing in newer engineers. Code review was happening, but the feedback was inconsistent — some PRs got rubber-stamped, others got nitpicked into next month. Newer team members were getting different signals from different reviewers.
Task
Help establish a more consistent review culture without coming across as the code-review police.
Action
- Started by being more deliberate in my own reviews — distinguishing "must fix" from "nit" from "consider for later"
- Wrote up our team's implicit conventions — naming, file organization, when to extract — into a short living doc
- In reviews, when I caught myself making the same comment for the third time, that became a candidate for the doc or an automated check
- Paired with newer engineers a few times when they asked, walking through how I think about a given change
- Avoided being prescriptive — my goal was to give them tools to make their own judgments, not to clone my preferences
Result
Reviews got more consistent and more useful. Newer engineers ramped faster because they could read the conventions doc instead of guessing from scattered PR comments. I also got better as a reviewer — having to articulate why something matters forced me to actually understand my own preferences. Net result: a higher floor on code quality without a heavier process.
07Quick-pivot mapping
If they ask this → reach for this story:
| Question | Primary story | Secondary |
|---|---|---|
| "Project you're proud of" | Translation infra | tutorialsearch.io |
| "End-to-end ownership" | tutorialsearch.io | Translation infra |
| "Hardest bug" | Memory leak | — |
| "Disagreement with someone" | State mgmt debate | Mentoring |
| "Mentoring / leadership" | Mentoring | State mgmt debate |
| "Performance work" | Translation infra | Memory leak |
| "Worked with ambiguity" | Translation infra | tutorialsearch.io |
| "Made a hard call" | State mgmt debate | Translation infra |
| "Worked across teams" | Translation infra | — |
| "Tooling / DX" | Mentoring (review doc) | tutorialsearch.io |
08Practice protocol
- Read each story aloud, twice. Once for the shape, once for delivery.
- Time yourself on each. Aim for 60–90 seconds. Cut Action bullets if you're over.
- Practice the opening sentence of each — that's where you hook the listener. The Result is what they'll remember; the opener is what gets them to listen for it.
- Have Sathi or Dan throw 5 random behavioral questions at you. Practice the pivot — picking which story fits.
- Don't over-rehearse to the point that it sounds memorized. The stories should feel like you remembered them, not recited them.