1. Customer Obsession
What they're actually evaluating: Do you start from the customer and work backward, or do you build what's technically interesting?
Best scenario type: A time you overruled a technically elegant solution because customer data showed they needed something simpler.
SDE2 STAR example: Situation: Our API response times met SLA but customer support tickets about “slow search” increased 40%. Task: Investigate whether the perceived slowness was a real issue. Action: I instrumented frontend render times separately from API latency and found the search results page was re-rendering 3 times per query due to a state management bug. The API was fast; the UI wasn't. I proposed and shipped a memoization fix over a two-sprint refactor the team had planned. Result: Support tickets dropped 65% in two weeks. The “slow search” problem was solved without touching the backend at all.
2. Ownership
What they're actually evaluating: Do you act beyond your job description when something needs to be done?
Best scenario type: A time you took responsibility for something outside your team's scope because it was the right thing to do.
SDE2 STAR example: Situation: Our service had a dependency on an internal library maintained by another team that was being deprecated with no migration path. Task: Our team wasn't responsible for finding the replacement. Action: I wrote a compatibility shim, documented the migration, and presented it to both teams. Then I drove the migration for our service and two other teams that used the same library. Result: Three services migrated cleanly before the deprecation deadline. The other team adopted my shim as the official migration guide.
3. Invent and Simplify
What they're actually evaluating: Can you find a simpler solution when everyone else is over-engineering?
Best scenario type: A time you replaced a complex system with something dramatically simpler.
SDE2 STAR example: Situation: Our data pipeline used a distributed message queue with five microservices to process CSV uploads. Average processing time was 45 minutes. Task: Reduce processing time to under 5 minutes. Action: I profiled the pipeline and found 80% of the time was inter-service serialization overhead. The actual data transformation was trivial. I proposed replacing the pipeline with a single Lambda function that processed the CSV in-memory. Result: Processing dropped to 90 seconds. We decommissioned three services and reduced infra costs by 70%.
4. Are Right, A Lot
What they're actually evaluating: Do you make good decisions with incomplete data, and do you update your position when evidence changes?
Best scenario type: A decision where you were initially wrong, changed your mind based on data, and the outcome improved.
SDE2 STAR example: Situation: I advocated for migrating our monolithic API to microservices. After two sprints of planning, usage data showed that only 2 of 12 endpoints had independent scaling needs. Task: Decide whether to continue the migration. Action: I reversed my recommendation and proposed extracting only those 2 endpoints as services while keeping the rest as a modular monolith. I presented the data to the team and took ownership of the pivot. Result: We shipped the partial extraction in half the time with 80% of the scaling benefit and none of the distributed systems complexity.
5. Learn and Be Curious
What they're actually evaluating: Do you actively seek to understand areas outside your immediate expertise?
Best scenario type: A time you went deep into an unfamiliar domain to solve a problem or make a better decision.
SDE2 STAR example: Situation: Our ML team wanted to deploy a recommendation model, but the serving infrastructure was my team's responsibility. I didn't know how model serving worked. Task: Build a serving layer that met latency requirements. Action: I spent a week learning TensorFlow Serving, ONNX Runtime, and model quantization. I built a prototype comparing both approaches and presented benchmarks to the ML team. Result: We deployed with ONNX Runtime, achieving p99 latency of 12ms. The ML team said it was the smoothest model deployment they'd experienced.
6. Hire and Develop the Best
What they're actually evaluating: Do you raise the bar in hiring and invest in making others better?
Best scenario type: A time you mentored a junior engineer to a level they didn't think was possible, or made a hiring decision that raised the team's capability.
SDE2 STAR example: Situation: A junior engineer on my team was struggling with system design tasks. Their designs consistently missed edge cases. Task: Help them improve without micromanaging. Action: I created a weekly 1:1 design review where they'd present a design and I'd only ask questions (not give answers). I also shared my own design doc templates with built-in sections for failure modes and rollback plans. Result: Within 3 months, they independently designed and shipped a caching layer that reduced our database load by 40%. They were promoted 6 months later.
7. Insist on the Highest Standards
What they're actually evaluating: Do you hold the line on quality when there's pressure to cut corners?
Best scenario type: A time you pushed back on a launch or release because the quality wasn't where it needed to be.
SDE2 STAR example: Situation: We were about to launch a new payments feature. The manager wanted to ship on the committed date. I found that our error handling didn't cover partial payment failures — a customer could be charged without the order being confirmed. Task: Decide whether to block the launch. Action: I documented the failure scenario, estimated the customer impact (0.3% of transactions), and presented it to the team with a 3-day fix. I blocked the launch and took responsibility for the schedule slip. Result: The fix shipped 3 days late. Post-launch monitoring showed the exact failure scenario occurring in 0.4% of transactions — close to my estimate. Without the fix, hundreds of customers would have been incorrectly charged.
8. Think Big
What they're actually evaluating: Do you see the larger opportunity beyond the immediate task?
Best scenario type: A time you proposed a solution that scaled beyond the immediate problem and was adopted more broadly.
9. Bias for Action
What they're actually evaluating: Do you act decisively with imperfect information rather than waiting for certainty?
Best scenario type: A time you made a reversible decision quickly rather than waiting for perfect data, and it paid off.
10. Frugality
What they're actually evaluating: Can you accomplish more with less? Do you avoid waste?
Best scenario type: A time you delivered a result without additional headcount, budget, or infrastructure.
11. Earn Trust
What they're actually evaluating: Are you honest about mistakes? Do you listen to others, especially when they disagree with you?
Best scenario type: A time you admitted a mistake publicly, or a time you changed your approach based on feedback from a junior team member.
12. Dive Deep
What they're actually evaluating: Do you get into the details, or do you rely on summaries?
Best scenario type: A time you dug into the data/code yourself and found something everyone else missed.
13. Have Backbone; Disagree and Commit
What they're actually evaluating: Do you voice disagreement respectfully, and do you commit fully once a decision is made — even if it wasn't yours?
Best scenario type: A time you disagreed with a senior engineer or manager, presented your case with data, and either won them over or committed to their decision.
14. Deliver Results
What they're actually evaluating: Do you focus on outcomes, not activity? Do you deliver on commitments despite setbacks?
Best scenario type: A time you faced unexpected obstacles and still delivered the committed outcome.
15. Strive to be Earth's Best Employer
What they're actually evaluating: Do you create an environment where others can do their best work?
Best scenario type: A time you improved your team's processes, culture, or tooling to make everyone more effective.
16. Success and Scale Bring Broad Responsibility
What they're actually evaluating: Do you consider the broader impact of your work beyond your immediate team?
Best scenario type: A time you considered the impact on other teams, customers, or the broader ecosystem when making a technical decision.
The Bar Raiser: How to Handle Progressive Drilling
Every Amazon interview loop includes a Bar Raiser — a trained interviewer from a different team whose job is to ensure every hire raises the bar for the role. Bar Raisers are specifically trained to probe the depth and authenticity of your stories.
Their technique is progressive drilling:
- ■“Tell me more about your specific role in that decision.”
- ■“What alternatives did you consider?”
- ■“What would you do differently if you faced this again?”
- ■“Who disagreed with you and how did you handle it?”
- ■“What data did you use to make that decision?”
The goal is to get past the rehearsed STAR answer and test whether you actually lived the experience. Generic answers collapse under drilling. Authentic stories with specific data points, names (redacted if needed), and measurable outcomes survive it.
How faFAANG's Experience Mode Loads Your Story Bank Into the Interview
Every LP prep guide tells you to build a story bank. The problem is using it under live pressure. When the interviewer asks about a time you demonstrated Ownership, you need to instantly map the right story to the right LP — and when the Bar Raiser drills deeper, you need specifics from that story on demand.
faFAANG's Experience Mode is built precisely for this:
- ■Separate context thread — Experience Mode maintains its own seeded Codex thread, completely separate from Coding Mode. Context doesn't bleed between modes.
- ■Story upload — You upload your
experience_context_prompt.mdand career story files. faFAANG builds a mode-specific manifest of your actual stories with chunked ACK seeding — ensuring the AI has read and acknowledged every story before the session begins. - ■JD-aware briefing — If you upload a job description, faFAANG generates an Experience Mode JD brief: evaluation criteria for the role, relevant story angles, likely follow-up pressure points, and Bar Raiser signals. This is injected into the seeded manifest before the session.
- ■Live LP support — During a live LP round, your verbal response is transcribed locally via Moonshine, submitted through the seeded Experience context to your own ChatGPT account, and a STAR-structured suggestion streams into the pane — grounded in your actual uploaded stories, not generic templates.
- ■Pane interactivity on — Experience Mode defaults to pane interactivity enabled, so you can scroll and read the suggestion naturally.
- ■Instant mode switch —
Ctrl+Mswitches to Coding Mode instantly if the round shifts to a technical question.
Every LP prep guide tells you to build a story bank. faFAANG is the first tool that loads your story bank into the interview with you.