Amazon Leadership Principles & MAANG Behavioral Stories

Prep doc for SDE-II / L4 / E4 loops. Covers Amazon’s 16 LPs, Meta’s “Jedi” rubric, and Google’s “Googleyness”. Sanjay should treat the STAR stories as drafts — rehearse aloud, swap in voice, do not memorize verbatim.

1. Why Behavioral Matters in 2026

Behavioral is no longer a tiebreaker — it is a gate. Every MAANG company now runs at least one dedicated behavioral round, and most run two. The trend over the last three hiring cycles is unmistakable: companies have learned that they can find people who solve LeetCode-medium in 25 minutes, but they cannot easily find people who own outcomes, handle ambiguity, and tell the truth when something goes sideways.

A few specifics worth knowing before walking into the loop:

Amazon embeds the Leadership Principles in every round — yes, including the coding rounds. After you finish the algorithm question, the interviewer will pivot with “tell me about a time when…” and they are scoring you on LPs, not on your code. Amazon also assigns a Bar Raiser to your loop: a senior interviewer from a different org who has veto power on the hire decision. The Bar Raiser is almost always evaluating on LPs.
Meta runs an explicit behavioral round they internally call “Jedi”. It scores on four axes: drives results, communication, direction, and people. Meta has been particularly heavy on behavioral signal since 2024 for IC4+ (E4+) hires.
Google runs a round called “Googleyness + Leadership”. It is less rubric-driven than Amazon’s LPs but evaluates collaboration, comfort with ambiguity, and humility.
Apple, Microsoft, Netflix all run dedicated values rounds with their own flavors (Netflix is famously brutal on the “Keeper Test” mindset).

Bottom line: the bar has moved. A strong coder with weak stories will get downleveled or rejected. A median coder with crisp, quantified, LP-aligned stories will get the offer.

2. The STAR Framework — Done Right

STAR (Situation, Task, Action, Result) is the standard structure. Most candidates butcher it the same way: they spend three minutes on Situation, thirty seconds on Action, and forget the Result. Here is the correct weighting for a 2–3 minute spoken answer:

Section	Time budget	What goes here
Situation	~10% (15–20 sec)	One sentence of context. Team, product, scale.
Task	~10% (15–20 sec)	What were you specifically responsible for?
Action	~60% (90–110 sec)	The bulk. Use “I”, not “we”. What did you decide, build, push for?
Result	~20% (30–40 sec)	Quantified outcome. Numbers, percentages, dollars, latency.

A few hard-earned rules:

“I” not “we”. Interviewers cannot grade a team. They are grading you. If you say “we decided”, they will ask “what did you decide?”. Skip the round-trip — start with “I”.
Pre-write, do not memorize. Write each story as a paragraph. Read it three times. Then put it away and tell it aloud. If you memorize word-for-word, you will sound robotic, and when the interviewer interrupts (they will) you will lose your place.
Quantify everything. “Reduced latency a lot” is dead on arrival. “Reduced p95 from 2.5s to under 500ms — 80% improvement” gets you hired.
One story = one LP, primary. You can map a story to 2–3 LPs, but pick a primary so you can pivot if asked.
Have a failure story for every success story. Amazon especially loves “tell me about a time you failed”. If you only have wins, you sound either junior or dishonest.

3. Amazon’s 16 Leadership Principles

The five marked [every loop] show up in essentially every Amazon interview. Prepare two stories minimum for each.

Customer Obsession [every loop] — Start from the customer and work backwards. Don’t focus on competitors.
Ownership [every loop] — Act on behalf of the entire company. Never say “that’s not my job”.
Invent and Simplify — Find ways to simplify; expect to be misunderstood for long periods.
Are Right, A Lot — Strong judgment. Seek diverse perspectives and disconfirm your own beliefs.
Learn and Be Curious — Always be improving yourself. Explore new possibilities.
Hire and Develop the Best — Raise the performance bar with every hire and promotion.
Insist on the Highest Standards — Have relentlessly high standards. Many will think they’re unreasonably high.
Think Big — Bold direction. Communicate a different and better future.
Bias for Action — Speed matters. Many decisions are reversible — don’t need extensive study.
Frugality — Accomplish more with less. Constraints breed resourcefulness.
Earn Trust [every loop] — Listen attentively, speak candidly, treat others respectfully. Vocally self-critical.
Dive Deep [every loop] — Operate at all levels, stay connected to details, audit frequently.
Have Backbone; Disagree and Commit — Challenge respectfully when you disagree. Once decided, commit fully.
Deliver Results [every loop] — Focus on key inputs and deliver with the right quality, on time.
Strive to be Earth’s Best Employer — Create a safer, more productive, more diverse workplace.
Success and Scale Bring Broad Responsibility — We must be humble, thoughtful about the secondary effects of our actions.

LP 15 and 16 are newer (added 2021) and asked less often for IC roles, but be aware of them. The Bar Raiser may probe them if your other answers feel narrow.

4. 12 STAR Stories Drafted for Sanjay

Each story is ~250 words, written in first person, ready to rehearse. Time them: should land between 2:00 and 2:45 spoken at a normal pace. Practice with a stopwatch.

Story 1 — Customer Obsession (AI Rate Limiter)

Primary LP: Customer Obsession | Secondary: Frugality, Bias for Action

In early 2025 I was building the Clinical AI Summarization Engine, which calls large language model APIs to synthesize patient EHR data for oncologists. Within two months of launch the cloud LLM bill was running 40% above forecast, and worse, doctors were complaining that summaries took 8–10 seconds to load during morning rounds when traffic spiked. The vendor was rate-limiting us silently, returning 429s that we were retrying blindly.

I was the only backend engineer on that surface. My task was to bring cost under control without losing availability — because a doctor who cannot see the AI summary in their workflow will simply stop using the tool, and we lose them forever.

I dug into the call patterns first. I found three things: 30% of calls were duplicates within a 5-minute window, our retry logic was thundering on 429s, and we had no per-tenant fairness — one hospital could starve another. I designed a token-bucket rate limiter with a Redis-backed cache layer, per-hospital quotas, and a circuit breaker that fell back to a smaller cheaper model when the primary was saturated. I rolled it out behind a feature flag, validated on two pilot hospitals over a week, then enabled globally.

The result: 40% reduction in monthly LLM spend, p95 latency for summaries dropped from 8 seconds to 2.1 seconds, and zero doctor-reported timeouts in the following quarter. The cost savings funded an expansion to two additional hospital partners.

Story 2 — Ownership (ePRO Microservice End-to-End)

Primary LP: Ownership | Secondary: Deliver Results, Dive Deep

In mid-2024 our oncology platform needed an ePRO — electronic patient-reported outcomes — service so patients could log symptoms from home and have that data flow into the clinician’s dashboard in real time. The product manager scoped it, the architect drew a box on a slide, and nobody owned the implementation. I raised my hand.

My task was to design and ship ePRO from scratch, including HLD, LLD, schema, and real-time sync across five existing microservices: patient data, treatment plan, communication, clinical risk scoring, and the doctor-facing dashboard.

I started by interviewing two oncology nurses to understand what symptom data they actually acted on — the spec had 40 fields, but only 12 drove clinical decisions. I rescoped to those 12. Then I drew the HLD: a write-optimized Postgres store for the raw submissions, Kafka events for fan-out to the five consumers, and a Mongo projection for the dashboard’s read path. I wrote the LLD myself, including the API contracts, sequence diagrams, and the LiquiBase migration. I built it, paired with QA on the test harness, and shepherded the rollout through three environments.

The result: ePRO shipped on the original target date, real-time sync settled at sub-2-second end-to-end latency across all five services, and within a quarter it was the most-used patient-facing feature in the product. I also wrote the operator runbook myself because I knew I would be on call for it for the first 60 days.

Story 3 — Invent and Simplify (AI-Driven Development Framework)

Primary LP: Invent and Simplify | Secondary: Think Big, Deliver Results

By late 2024 our team was spending real time on the same kinds of work over and over: scaffolding a new microservice, writing the boilerplate controller and DTO layers, checking that the architectural conventions were followed in pull requests, and updating documentation when interfaces changed. I watched a junior engineer spend two days getting a new service to even compile against our parent POM, and I knew there was a better way.

My task — self-assigned, then endorsed by my manager — was to build an AI-driven development framework that codified our architectural rules and automated the repetitive scaffolding.

I designed a custom orchestration layer on top of Cursor and Claude with project-specific rule files that encoded our Maven parent-child layout, our naming conventions, our LiquiBase patterns, and our security gates. I added an automated compliance check that ran on every PR and flagged architectural drift before review. I built a dependency-management agent that kept our 20 microservices in sync on shared library versions. I wrote it incrementally over six weeks, dogfooding on my own tickets first, then onboarding two volunteers, then the whole team.

The result: average development time for a feature dropped by roughly 60%, measured across 40 tickets pre and post adoption. New-engineer ramp time for “first merged PR” went from three weeks to under one. The framework is now standard across the org, and I gave two internal talks on the approach.

Story 4 — Are Right, A Lot (Hibernate Optimization)

Primary LP: Are Right, A Lot | Secondary: Dive Deep, Customer Obsession

In Q3 2023 the patient data microservice was returning a treatment-history endpoint in around 2.5 seconds at p95. Doctors were complaining that the dashboard felt sluggish during clinic hours. Two engineers before me had looked at it and concluded “Postgres is the bottleneck — we need a read replica.” I was not convinced.

My task was to either confirm the read-replica plan and execute it, or find the actual root cause.

I started with disconfirming evidence. I pulled the actual Postgres slow-query log and ran EXPLAIN ANALYZE on the suspect queries. The database was responding in 60–80 milliseconds. The 2.5 seconds were happening somewhere else. I turned on Hibernate statistics logging and immediately saw the N+1 problem: one parent fetch was triggering 30+ lazy child fetches per request, and the entity graph had two layers of @OneToMany with FetchType.LAZY that no JOIN FETCH was unwinding.

I rewrote the query to use a single JPQL with explicit JOIN FETCH on the two collections, added an @EntityGraph annotation for the controller path, and tuned the second-level cache for the lookup tables that were being re-read on every request. I benchmarked locally, then ran the same load test the previous engineers had used as their justification for the read replica.

The result: p95 dropped from 2.5 seconds to under 500 milliseconds — an 80% reduction. The read-replica project was cancelled, saving roughly six engineer-weeks of work and the ongoing infra cost.

Story 5 — Learn and Be Curious (Kong + Konga POC)

Primary LP: Learn and Be Curious | Secondary: Bias for Action, Invent and Simplify

In early 2025 our platform was hitting growing pains with API management: rate limits were hardcoded per service, auth was repeated in every microservice, and we had no central observability for our 20-plus internal APIs. Leadership was discussing whether to build something custom or evaluate a gateway. I had never touched an API gateway in production. I volunteered to run a POC anyway.

My task was to evaluate Kong as our API gateway and produce a recommendation within three weeks, including a working POC against our actual services.

I spent the first weekend reading Kong’s documentation end-to-end and watching two conference talks on production deployments. I learned that Kong’s default admin UI was bare-bones, so I added Konga on top for a real dashboard. I hit a wall on Konga’s bundled SQLite for production use, so I learned its schema and decoupled it onto our existing Postgres cluster — that itself was a small architectural win. I wrote plugins for our JWT format, configured rate limits per route, and integrated it in front of three real services as the POC scope.

The result: I delivered the POC two days early, with a written comparison against the build-in-house alternative covering cost, ops burden, and feature gaps. Leadership greenlit Kong as the gateway direction. More importantly, I went from zero Kong knowledge to authoring an internal training doc that two other engineers used to onboard.

Story 6 — Hire and Develop the Best (KT + Velocity Gain)

Primary LP: Hire and Develop the Best | Secondary: Earn Trust, Insist on Highest Standards

After my promotion to Senior in October 2024, I had two engineers more junior than me on the team — one a recent hire, one a year-one engineer rotating in from another product. Sprint velocity was uneven: some sprints we closed 80% of committed story points, some we closed 50%. The variance was killing our planning credibility.

My task was unofficial but obvious: lift the team’s throughput by raising the floor, not by working more hours myself.

I started by sitting in on their PR reviews silently for two weeks to see where they were getting stuck. The pattern was clear: both engineers were strong coders but unsure on our architectural conventions, Hibernate quirks, and the deployment pipeline. So I designed a weekly 45-minute knowledge-transfer session — one topic per week, hands-on, with a small exercise. Topics covered our parent-POM structure, LiquiBase migration patterns, Kafka consumer idempotency, and writing testable Spring services. I also started doing detailed PR reviews with explanatory comments rather than just “looks good” — treating the review itself as teaching.

I committed to this for six months. By the end of Q1 2025, sprint velocity had stabilized and gone up roughly 40% measured by story points closed per sprint. One of the two engineers was promoted to mid-level in the next cycle. The KT format was adopted by two adjacent teams. I learned that scaling myself through other people was a much bigger lever than scaling my own output.

Story 7 — Insist on Highest Standards (SonarQube + HIPAA)

Primary LP: Insist on Highest Standards | Secondary: Ownership, Dive Deep

In mid-2023 we ran our first organization-wide SonarQube scan across the oncology platform. The results were ugly: over 200 security vulnerabilities flagged across 20 microservices, ranging from SQL-injection-prone string concatenation to logged PII to outdated dependencies with known CVEs. We were also preparing for a HIPAA compliance audit. Most engineers looked at the report and quietly hoped someone else would own it.

My task was to drive remediation across the whole codebase before the audit, even though most of the offending code wasn’t mine.

I categorized the 200 findings into three buckets: critical (auth, SQL injection, PII exposure), important (deprecated crypto, logging hygiene), and cosmetic. I owned the critical bucket personally — that was about 50 issues — and broke the others into tickets across the team with clear acceptance criteria and reproductions. I refused to let anyone close a ticket as “won’t fix” without a written justification I had reviewed. I also added a SonarQube gate in CI so new vulnerabilities would block merges going forward.

It took eight weeks. The result: all 200 vulnerabilities resolved, the SonarQube code-quality score went up 40%, and we passed the HIPAA audit with zero findings on the application layer. The CI gate has since prevented dozens of new issues from landing. I learned that “highest standards” is not about being a perfectionist — it’s about being the one person who refuses to let the bar slip when nobody’s watching.

Story 8 — Think Big (Clinical AI Summarization Engine)

Primary LP: Think Big | Secondary: Customer Obsession, Invent and Simplify

In late 2024 the product ask was modest: “give doctors a one-paragraph summary of the patient’s last visit”. I looked at the request and thought it was too small. A one-paragraph summary of the last visit would save a doctor 30 seconds. But oncology patients often have 5–10 years of treatment history across multiple hospitals, and the real problem was that no doctor could read a 200-page longitudinal record before a 15-minute consult.

My task started as the small ask. I expanded the scope through a written proposal.

I drafted a one-page vision document arguing that we should build a clinical summarization engine that synthesizes the patient’s entire longitudinal journey — every encounter, every lab, every imaging report, every treatment line — into a structured timeline plus a narrative summary tuned for oncology. I sketched the architecture: a retrieval layer over the EHR, a summarization layer using LLMs with clinical-grade prompts, and a citation system so doctors could click any sentence and see the source document. I shared the doc with my manager and the product lead. They pushed back on scope. I argued that the small version had no real moat and the big version was actually defensible.

The result: leadership greenlit the bigger scope. I built the first version over four months. It is now used across multiple hospital partners, and the citation-backed summaries are the feature doctors mention first in feedback. I learned that the right move is often to argue for a bigger problem, not a smaller one.

Story 9 — Bias for Action (CDC Microservice)

Primary LP: Bias for Action | Secondary: Deliver Results, Ownership

In Q2 2024 our patient data was split between a Postgres write store and a MongoDB read store for the dashboard. The two were synced by a nightly batch job. This caused a real clinical problem: a doctor updating a patient’s treatment plan at 10am could not see the change reflected on a colleague’s dashboard until the next day. We had been talking about fixing it for two quarters. The architecture discussions were going in circles — three options on the table, no decision.

My task was technically just “improve sync latency”, but I read the room and saw that the real blocker was that nobody had run a concrete experiment.

I gave myself two weeks to ship a working prototype rather than join another whiteboard session. I picked option two from the discussion — Debezium-based CDC with Kafka as the transport — because it was the option with the least invasive code change. I stood up Debezium against a dev Postgres in two days, wrote a Kafka consumer that wrote into MongoDB, handled idempotency with the Postgres LSN as the dedupe key, and demoed end-to-end sync in week one. Week two was hardening: ordering guarantees, replay on failure, schema-evolution handling.

The result: sub-3-second sync latency from Postgres write to Mongo read, replacing the nightly batch. We shipped to prod within five weeks of my prototype. The other two architecture options were dropped. I learned that for most reversible technical decisions, a working prototype ends an argument faster than a slide deck.

Story 10 — Frugality (LLM Cost Reduction)

Primary LP: Frugality | Secondary: Invent and Simplify, Ownership

Cross-references the rate-limiter story but framed differently for Frugality.

In Q1 2025 our cloud LLM bill for the summarization engine was on track to hit a number leadership was not happy about — roughly 40% over the original forecast and rising as we onboarded more hospitals. The easy ask would have been “buy more capacity” or “negotiate a bigger committed-spend contract”. I disagreed.

My task was to bring the bill back to forecast without throwing more money at it and without degrading the doctor experience.

I started by instrumenting every LLM call with its input token count, output tokens, latency, and the calling feature. Two weeks of data made the answer obvious: 30% of our calls were near-duplicate requests within a 5-minute window — the same doctor refreshing the same patient summary — and we were paying full freight every time. Another 15% were calls that could use a cheaper model with negligible quality loss for the use case. I built three things on a small budget: a semantic cache keyed on patient-id plus a content hash, a model-router that sent simpler tasks to the cheaper tier, and the rate limiter to enforce fairness.

The result: 40% reduction in monthly LLM spend, achieved with zero new infrastructure spend — the cache ran on existing Redis, the router was a 200-line config layer. The saved budget funded the onboarding of two more hospital partners that quarter. I learned that frugality is really about being annoyed enough by waste to instrument it before you assume it’s fine.

Story 11 — Earn Trust (Admitting a Wrong Call)

Primary LP: Earn Trust | Secondary: Are Right A Lot, Have Backbone Disagree and Commit

In early 2024 I argued strongly in a design review that we should use synchronous REST calls between two microservices for a particular workflow rather than Kafka events. My argument was that the workflow was inherently sequential, the latency budget was tight, and adding Kafka would complicate the failure modes. Two more senior engineers pushed back and argued for events. I held my position. We shipped it sync.

My task, in retrospect, was supposed to be making the right architectural call. I made the wrong one.

Within six weeks of shipping, we hit two production incidents where the downstream service was slow and the upstream calls timed out, taking the whole user-facing flow down. The exact failure mode the senior engineers had warned me about. I had two choices: quietly patch with longer timeouts and circuit breakers, or own it openly. I wrote a short post-mortem and shared it in our team channel: “I argued for sync, I was wrong, here’s what failed, here’s what I’m changing.” I rebuilt the integration with a Kafka event in the following sprint, and I pinged the two senior engineers privately to say they had been right.

The result wasn’t a metric — it was that one of those senior engineers has been my go-to design reviewer ever since and recommended me when I went up for promotion. I learned that being publicly self-critical when you’re wrong builds more trust than being quietly right.

Story 12 — Dive Deep (Hibernate Fetch-Cycle Root Cause)

Primary LP: Dive Deep | Secondary: Are Right A Lot, Insist on Highest Standards

This is a deeper version of the Hibernate optimization story, framed for the Dive Deep probe specifically.

The setup: 2.5-second p95 on a treatment-history endpoint, two prior engineers had concluded the database was the bottleneck, the proposed fix was a read replica costing six engineer-weeks plus ongoing infrastructure.

My task was to verify the diagnosis before we spent the money.

I did not stop at “is the database slow”. I went layer by layer. First layer: APM trace. The actual SQL time was 60–80ms total. So the 2.5 seconds was happening in application code. Second layer: Hibernate statistics. I enabled hibernate.generate_statistics=true and hibernate.session.events.log.LOG_QUERIES_SLOWER_THAN_MS=50 in a dev environment with prod-shaped data, replayed the request, and saw the smoking gun: a single user request was emitting 47 SQL queries. Classic N+1. Third layer: the entity graph. I read the actual entity classes — there were two layers of @OneToMany with default lazy loading, and the service code was iterating both collections inside a stream. Fourth layer: the cache. The lookup tables (encounter types, treatment categories) were being re-fetched on every request because the second-level cache region was misconfigured.

I fixed all four layers in one PR: JPQL with JOIN FETCH, @EntityGraph on the repository, fixed cache region, and a Hibernate stats assertion in the integration test so the N+1 could not silently come back.

The result: p95 from 2.5 seconds to under 500 milliseconds, read-replica project cancelled, and the test now fails CI if anyone reintroduces an N+1 on that path. I learned that “the database is slow” is almost never the actual answer — you have to dig until the data tells you what it really is.

Story 13 — Have Backbone; Disagree and Commit (TEMPLATE)

Primary LP: Have Backbone; Disagree and Commit | Secondary: Earn Trust, Are Right A Lot

Template — Sanjay should swap in his real disagreement. Two plausible candidates from his portfolio: (a) advocating for Kong over an in-house gateway, (b) advocating for Debezium CDC over the alternative architecture options. Use whichever actually happened — interviewers can smell invention. Below is the Kong version as a placeholder.

In early 2025 the team was debating how to solve our API-gateway problem. Two senior engineers were advocating for building a thin in-house gateway on top of our existing Spring Cloud Gateway setup, arguing that we knew the codebase and could iterate faster. I disagreed and advocated for Kong.

My task was to make my case in the design review and then either win the argument or commit to the outcome either way.

I came in with a written one-pager. I laid out three dimensions: feature gap (auth, rate limiting, observability, plugin ecosystem — Kong shipped these; in-house would take quarters to reach parity), ops burden (Kong has a community and known scaling patterns; in-house would be our team’s problem forever), and total cost of ownership over two years. I acknowledged the real risk — Kong was new to us — and proposed mitigating it with a time-boxed POC. I deliberately did not attack the in-house proposal; I made the alternative concrete instead. The two senior engineers pushed back on the learning curve and the unknown ops cost.

We agreed I would run a two-week POC. I did, including the Konga dashboard and the Postgres decoupling. The POC closed the ops-burden concern. Leadership greenlit Kong.

The result: we shipped the gateway in eight weeks rather than the projected six months. I learned that backbone is not about being loud — it’s about being the person who shows up with a written argument and a falsifiable plan.

Story 14 — Deliver Results (Medical Reporting Engine)

Primary LP: Deliver Results | Secondary: Ownership, Customer Obsession

In mid-2023, a few months into my full-time role, I was handed the medical reporting engine. The scope was significant: generate clinical reports for 21+ distinct oncology encounter types — chemotherapy cycles, surgery summaries, radiation plans, follow-ups — and ship them as PDFs to 80+ partner hospitals with their own branding, headers, and signature requirements. The previous version was a brittle template engine that broke on every new hospital onboarding.

My task was to rebuild the reporting engine so that adding a new encounter type or a new hospital was a configuration change, not a code change.

I designed it around a Factory pattern for the encounter types and a template-strategy pattern for the hospital-specific formatting. I picked iText for the PDF generation because of its mature support for digital signatures, which we needed for clinical sign-off. I used Java multithreading to parallelize the generation of multi-page reports — many of them ran 30–50 pages with embedded charts and lab tables. I built a test harness that ran a representative report from every encounter type and every active hospital on every PR.

I shipped it in three months. The result: all 21 encounter types live, all 80+ hospital partners migrated within a quarter, average report generation time dropped from 14 seconds to under 3 seconds per report, and onboarding a new hospital went from a two-week engineering effort to a half-day configuration task. Two years later, the same engine is still in production and the architecture has held up as the encounter list has grown.

5. Common Follow-Up Probes

Interviewers do not just take your STAR and move on. They drill. Below are the ten probes that come up most often, and how to prep for each. Have a rehearsed half-sentence for every one — not memorized, but ready.

“What would you do differently if you did it again?” Always have an answer. Never say “nothing”. Say something specific and small — “I would have instrumented before I built the cache, not after, because the data would have informed the cache key design.”
“What was the hardest part?” Pick a technical hard part, not a people hard part, unless the story is explicitly about a people conflict. Be honest — “the hardest part was convincing myself the N+1 was the issue when two senior engineers had already concluded otherwise.”
“Who pushed back? How did you handle it?” Have a name (or at least a role — “the principal engineer on the platform team”). Describe the pushback fairly. Describe how you addressed it without making the other person look stupid.
“How did you measure success?” Always have a metric. Latency, cost, story points, error rate, adoption — pick the one that matched the goal. If you can’t measure it, that’s a flag.
“What did your manager think?” They are checking that you actually told your manager. Have a sentence: “My manager was initially skeptical because… after I showed him the prototype, he…” — pattern works.
“What if the result hadn’t worked?” Tests your judgment under counterfactuals. Have a Plan B you considered. “If the cache hit rate had stayed below 20%, I would have fallen back to negotiating the committed-spend contract.”
“How did you decide it was the right time to ship?” Tests your ship discipline. Talk about the bar — what tests passed, what monitoring was in place, what rollback plan existed.
“What was the trade-off?” Every real engineering decision has one. If you say there was no trade-off, you’re either lying or you didn’t understand the problem. Always name the trade-off explicitly.
“How did this scale?” For senior roles especially — interviewers want to see you think beyond the immediate story. “It scaled because the rate limiter was keyed per tenant, so adding hospitals was linear in cost, not super-linear.”
“Tell me about a time you failed.” Have one ready. The Earn Trust story above (the sync-vs-Kafka call) works. Pick a real failure, take real ownership, show real learning. Do not pick a humble-brag failure like “I worked too hard”.

6. Meta-Specific Behavioral Signals (Jedi)

Meta’s behavioral round, internally called “Jedi”, scores on four explicit axes. For E4 (entry-mid IC) and higher, you need at least one strong story per axis. Stories below are tuned from Sanjay’s portfolio to hit each signal directly.

Axis	What Meta is scoring	Lead-with story
Drives Results	Shipping outcomes against a deadline, prioritizing ruthlessly, handling ambiguity.	Medical Reporting Engine (21 encounter types, 80+ hospitals, 3 months).
Communication	Clear writing, clear verbal, alignment across stakeholders.	Clinical AI Summarization vision doc — converted scope upward.
Direction	Picking the right problem, setting technical direction, knowing what to not build.	CDC microservice — ended an architecture debate with a prototype.
People	Mentorship, feedback, conflict resolution, team-building.	KT sessions + sprint velocity gain (40%).

A fifth story tuned for Meta’s L4/L5 boundary:

Operating in ambiguity (Direction + Drives Results) — The AI-Driven Development Framework was a problem nobody had defined. There was no ticket, no design doc, no metric. I wrote my own problem statement, picked my own success metric (dev time per ticket), got informal endorsement from my manager, and shipped it incrementally. Meta L5 specifically rewards engineers who define the work, not just execute it.

A few Meta-specific tactical notes:

Meta’s interviewers tend to ask about conflict more aggressively than Amazon’s. Have at least two distinct conflict stories ready (one with a peer, one with a manager or PM).
“Why Meta?” comes up almost always. Have a 30-second answer that connects to scale, infrastructure problems, or a specific product. Generic answers get marked down.
Meta cares about velocity culture. If your story has the phrase “we waited two quarters for sign-off”, that’s a negative signal. Reframe around what you shipped in the meantime.

7. Google “Googleyness + Leadership”

Google’s behavioral round is less rubric-driven than Amazon’s or Meta’s. The scoring areas Google publishes are: collaboration, comfort with ambiguity, and humility. The bar is “would I want to work with this person on a hard problem for two years?”. Three stories tuned for it:

Collaboration — KT sessions and code reviews story. Frame it as: I made the team better, not just myself. “The 40% velocity gain wasn’t mine — it was the team’s. My contribution was creating the structure that let the team improve itself.”

Ambiguity — AI-Driven Development Framework. There was no spec, no ticket, no defined success metric. I created the problem statement, picked the metric, and iterated. Google specifically tests whether you can operate when nobody is telling you what to do.

Humility — The Earn Trust story (sync vs Kafka, admitting I was wrong). Google’s interviewers explicitly flag candidates who can’t name a mistake. Lead with the mistake, do not soften it, and land cleanly on what you learned. Do not pivot into “but actually it worked out fine” — that destroys the signal.

A general Google note: avoid sounding overly polished. Google’s interviewers are trained to detect rehearsed answers and will sometimes deliberately interrupt to see how you handle it. Practice telling each story starting from a different sentence so you are not anchored to one opening.

8. “Tell Me About Yourself” — 90-Second Elevator Pitch

Draft for Sanjay. Rewrite in your own voice — this is a template, not a script. Time it at 80–95 seconds spoken.

“I’m Sanjay Naik, a backend engineer with about three and a half years building production systems in healthcare. I started as an intern at Karkinos Healthcare in late 2022 doing Spring Boot microservices and GCP deployments, joined full-time as an SWE in mid-2023 when Karkinos was acquired into Jio Platforms, and I’ve been a Senior SWE there since October 2024.

My work has centered on two things. First, the oncology platform — I’ve shipped the medical reporting engine that serves 80-plus partner hospitals, an ePRO microservice for real-time patient-reported outcomes across five downstream services, a CDC pipeline that took our Postgres-to-Mongo sync from nightly to under three seconds, and a clinical AI summarization engine that synthesizes longitudinal patient records for oncologists.

Second, I’ve built infrastructure that scales the team — an AI-driven development framework with custom orchestration rules that has cut our dev time per ticket by about 60%, an API rate limiter that reduced our LLM costs by 40%, and a knowledge-transfer cadence that helped lift sprint velocity 40% across my team.

What I’m known for is taking work end-to-end — HLD, LLD, schema, code, deployment, runbook — and being the person who actually digs into Hibernate fetch cycles or LLM call patterns rather than guessing at the bottleneck. I’m interviewing now because I want to work on problems at a scale where the systems I build matter to millions, not thousands, and that’s why I’m here today.”

9. Day-Before Rehearsal Checklist

The day before each behavioral loop, run this checklist. Do not skip it. The candidates who skip it are the ones who run long, blank on a question, or freeze on a follow-up.

Loom recording. Record yourself telling three random stories. Watch them back at 1.25x. You will notice every “uh”, every drift, every overlong setup. Fix the worst one.
Three-minute timer. Tell each of your top six stories with a visible stopwatch. Land between 2:00 and 2:45. If you’re under 2:00, you’re skipping the Action. If you’re over 3:00, you’re rambling on Situation.
“What’s your weakness?” template. Pick a real weakness, name a concrete step you have taken to address it, and show a result. Template: “I’ve historically been quick to commit to a design before fully exploring alternatives — I learned this the hard way on a sync-vs-events call that backfired. Since then I force myself to write a one-page comparison of at least two options before any non-trivial design decision, and my last three design reviews have gone through without rework.”
“Why this company?” Have a 30-second answer. Specific. Connects to your work. Not “great culture” or “smart people”.
“Why are you leaving?” Have a 20-second answer. Forward-looking. Not bitter. Not blaming. “I’ve done what I can do at the current scale and I want bigger problems” is fine.
Three questions to ask the interviewer. Pick ones that show seniority:
1. “What’s the most painful technical debt the team carries today, and what’s stopped it from being addressed?”
2. “What does someone who joins this team and is thriving 12 months in actually look like — what did they do?”
3. “If I joined and had one quarter to make an impact, what would you want me to focus on?”
Logistics. Charge laptop. Test mic. Test camera. Close Slack. Close the LLM tabs that the interviewer might see. Glass of water within reach.
Sleep. Stop preparing at 9pm. Cramming the night before makes you sound rehearsed and tired. Read a novel for an hour and go to bed.

Amazon Leadership Principles & MAANG Behavioral Stories — Sanjay Naik