Prep · Module 03

STAR Story Bank

Eight real stories structured for two-minute delivery, mapped to the questions that summon them.

Delivery format: STAR with a point

Every behavioral answer is the same two-minute machine. The most common failure mode is not a missing story — it is a story with the wrong time allocation: ninety seconds of background, twenty seconds of what you actually did. Invert that. The Action is the answer; everything else is framing.

Phase	Time	What it must contain
Situation	~20s	Company, your role, the stakes. One sentence of context the interviewer needs — nothing they don't.
Task	~10s	What you were on the hook for, stated as an outcome, not a job description.
Action	~60s	Three to five decisions you made, in order, with the reasoning for each. This is where Spark, Delta, Unity Catalog, and stakeholder moves live.
Result	~20s	A number, a shipped thing, or a changed behavior. Ideally all three.
The point	~10s	One sentence: what you learned or what you now do differently. This is what separates a report from an answer.

Three rules that apply to every story below:

Say "I", not "we". Interviewers cannot hire a team. "We built the pipeline" tells them nothing about you; "I designed the metadata-driven framework and reviewed the team's PySpark against it" does. Use "we" only for outcomes you genuinely shared, then immediately name your slice.
Quantify the Result. Source-system counts, dollar savings, downtime avoided, audiences served. If you have no number, name the artifact ("three production agents", "a runbook the team still uses").
Land the point. A lesson stated out loud signals self-awareness — the thing failure and conflict questions are actually probing for.

Rehearse each story out loud, timed, three times. Two minutes spoken is roughly 280 words. If your draft runs over, cut Situation first, then Result detail — never the Action. For Databricks field and professional-services loops, expect the project-delivery round to be a behavioral interview wearing a technical costume: the same stories work, but the follow-ups go deep into architecture, so know your own systems cold.

Tailor to the values Databricks screens for

As of mid-2026, Databricks describes its culture with principles along the lines of customer obsession, ownership, truth-seeking, and raising the bar — check the current careers page for exact wording before your loop, then echo their language back in your "point" sentences. Mapping your bank against them:

Customer obsession: Story 1 (CFO-level consumers), Story 4 (a public agency client on a clock), Story 2 (HR users who must trust an AI answer).
Ownership: Story 1 (end-to-end R2R delivery), Story 5 (owning an upgrade nobody would notice unless it failed).
Truth-seeking: Story 6 (data over preference in tool selection), Story 3 (and the discipline of verifying your own headline number).
Raising the bar: Story 7 (review standards), Story 2 (shipping GenAI to production, not a demo).

Your career is unusually well-shaped for this value screen: you have a nine-year arc from lottery DW/ETL at Scientific Games to leading Finance R2R analytics at ADM, with a promotion from Senior Data Engineer to Data & Analytics Technical Lead in March 2026. When asked "why should we believe you raise the bar," the promotion inside sixteen months at ADM is itself a Result — someone with budget authority already concluded it.

The eight stories

Story 1 — ADM: leading Finance R2R delivery end to end

Answers: leadership, ambiguity, "your most significant project", "a time you coordinated multiple stakeholders".

S: ADM's Finance Record-to-Report analytics ran across disconnected systems — JDE, SAP, HFM (Hyperion), IBM DB2, IBM APGO Web Wire — with Executive Committee and CFO-level consumers depending on the numbers being consistent and traceable.
T: I owned R2R analytics delivery end to end: architecture, build, governance, and the executive-facing output.
A: I architected Bronze/Silver/Gold medallion pipelines on Azure Databricks and Azure Data Factory integrating all five sources into Delta Lake; put lineage and Unity Catalog governance in from day one so Audit could trace any figure to source; and ran orchestration across ADF, Databricks Workflows, and Redwood RunMyJobs so Power BI refresh was part of the pipeline contract, not an afterthought — and consolidated the KPI definitions behind the frameworks into shared, governed versions rather than one-off departmental reports.
R: KPI frameworks for P&L, Budget vs Actual, Expense Forecasting, EHS, and Capital Allocation now serve Executive Committee and CFO-level consumers; I was promoted to Data & Analytics Technical Lead in March 2026.
Point: Ambiguity across departments is resolved by governance and lineage, not by meetings — make the data defend itself.

Delivery tips: Resist listing all five source systems twice; once is credibility, twice is inventory. Spend the Action on how you got stakeholders onto shared, governed KPI definitions — recover those specifics from memory before the loop; that is the leadership signal.

Likely follow-ups: How did you resolve a specific KPI definition conflict? Why medallion rather than a single curated layer? How does Unity Catalog lineage actually help an auditor?

Story 2 — ADM: three production GenAI agents on sensitive HR data

Answers: innovation, security and data sensitivity, impact, "a time you shipped something new to production".

S: HR questions about headcount, salaries, and policy were answered by analysts pulling from PeopleSoft and SAP labor data — slow, and risky for data this sensitive.
T: Ship GenAI assistants HR could actually use in production — meaning governed, auditable, and trustworthy, not a demo.
A: I built three agents on Databricks: a Corporate Headcount & Salaries Data Agent on a Genie Space that shows the generated SQL alongside the answer so users can verify it; an Employee Policy RAG Assistant on Databricks Vector Search and LLM endpoints that cites its sources; and a Combined Multi-Agent Assistant with intent routing between them. I hosted everything as a Databricks App with a custom Streamlit UI and embedded dashboards, and enforced Unity Catalog row- and column-level permissions so each HR user sees only what their role allows — the LLM never becomes a permissions bypass.
R: All three shipped to production for HR users, with the trust mechanisms — visible SQL, cited answers, UC enforcement — designed in from the start rather than bolted on.
Point: For GenAI on sensitive data, governance is the feature; the model is the commodity.

Delivery tips: Lead with "production" and "salaries" — both words make interviewers sit up. For a Sr. RSA ML & GenAI loop this is your flagship story; rehearse a whiteboard version of the intent-routing architecture.

Likely follow-ups: How do you evaluate answer quality? What happens when the router misclassifies intent? Why Genie Space instead of pure text-to-SQL against the warehouse? How do row filters interact with vector search results?

"Tell me about a time you had to balance innovation against risk." Outline: Story 2. Situation — HR data is the most radioactive data in the company. Task — ship GenAI anyway. Action — three trust decisions: show the SQL, cite the sources, enforce UC row/column security underneath the model. Result — production, not pilot. Point — you de-risk innovation by making verification cheap for the user, not by slowing the project down.

Story 3 — Maersk: semantic-layer lakehouse and the $10M figure

Answers: impact, cost optimization, "your proudest technical achievement".

S: Maersk's Fact-Based Reporting program pulled SAP S/4HANA, the AC-DOCA Universal Journal, and Hyperion HFM into an Azure lakehouse; the legacy estate included SSAS multidimensional cubes and heavy dedicated infrastructure.
T: Modernize the reporting stack while cutting its run cost.
A: I built metadata-driven ADF and PySpark ingestion to Delta on ADLS Gen2, published to a Synapse Dedicated SQL Pool, migrated SSAS multidimensional cubes to Azure Analysis Services Tabular, moved managed tables to external tables for governance and cost control, and delivered a Dremio plus Power BI semantic-layer lakehouse as the governed serving layer.
R: A multi-million-dollar annual infrastructure cost reduction attributed to the semantic-layer lakehouse (a program-level figure — lead qualitatively and only cite the number once you can defend its composition; see the caveat below).
Point: The cheapest infrastructure is the layer you decommission — a semantic layer over Delta means retiring serving systems instead of tuning them. (Only claim retirements you can name; see the warning below.)

The $10M figure is on your resume flagged internally as "verify before external use." Before any interview, reconstruct the calculation: which systems were retired, which licenses and compute made up the number, over what period, and what share is fairly attributable to your work versus the program. A senior interviewer will ask "how was that measured?" — and a confident breakdown turns the question into your best moment, while a shrug turns your biggest number into your biggest liability. If you cannot reconstruct it, downgrade the claim out loud ("a program-level reduction my workstream contributed to") rather than defending a number you can't decompose.

Delivery tips: Say "program-level figure, and here's the composition" before you are asked. Pair it with the smaller-but-fully-yours Ecolab number (~$20K/month Azure savings) to show a pattern, not a one-off.

Likely follow-ups: Walk me through the calculation. Why Dremio over building the semantic layer in Power BI alone? Why move managed to external tables, and what did it cost you in convenience?

Story 4 — Port Authority of NY & NJ: two deliveries, one six-month contract

Answers: prioritization, delivery under constraint, "competing deadlines", "a time you managed scope".

S: A June–November 2024 contract at the Port Authority with two distinct mandates: the ICMS agency-wide financial lakehouse, and a separate PATH Ridership Analytics migration off legacy VBA and MS Access.
T: Deliver both inside the contract window — no extension assumed.
A: For ICMS I built metadata-driven ADF and PySpark ingestion to ADLS Gen2 Bronze from SAP ECC FI, IBM Planning Analytics, and Budget PRO, covering Plan, Budget, Forecast, and Actuals across Capital and Operating portfolios for Aviation, PATH, and TB&T. The metadata-driven design was the prioritization decision: onboarding a new source became configuration, not code, so I could timebox ICMS work and parallelize the ridership track — replacing VBA/Access workloads with parameterized Azure Synapse pipelines and Power BI.
R: Both workstreams delivered within the six-month engagement.
Point: Under a fixed clock, the highest-leverage move is an architecture that converts repeated work into configuration — prioritization is a design problem before it is a calendar problem.

Delivery tips: This is your best consulting story for an RSA loop — short engagement, public-sector client, hard stop. Frame it as exactly what a Resident Solutions Architect does: land, build, hand over, leave.

Likely follow-ups: What did you deliberately not do? How did you hand over to staff who would maintain it? What would you have cut first if you'd fallen behind?

Story 5 — Ecolab: EBX 5.9 → 6.0.11 with zero downstream disruption

Answers: risk management, attention to detail, "a high-stakes change", "a time careful planning paid off".

S: At Ecolab's India GCC, the TIBCO EBX MDM platform — customized, and feeding downstream Customer Data Management consumers — needed a major version upgrade from 5.9 to 6.0.11.
T: Execute the upgrade without breaking anything downstream; success meant nobody outside the team noticing it happened.
A: I inventoried the customizations and downstream dependencies, validated them against the new version, and sequenced the upgrade so every consuming integration was verified before cutover.
R: Zero downstream disruption. In the same period I drove roughly $20K/month in Azure cost savings on the broader CDM estate.
Point: On a platform other systems depend on, the risk lives in the dependency map, not the upgrade itself — so I now start every risky change by enumerating consumers.

Delivery tips: "Zero downstream disruption" is the headline — say it in the Task as the success criterion and in the Result as the outcome. Keep this story short; its power is its cleanliness.

Likely follow-ups: What was your rollback plan? How did you test customizations against the new version? What would "disruption" have looked like and how would you have detected it?

Story 6 — ADM: fit-gap tool selection against stakeholder preferences

Answers: technical disagreement, influence without authority, conflict, "a time you changed someone's mind with data".

S: ADM needed a semantic-layer direction, with Power BI, Dremio, and Denodo in play — and stakeholders holding different starting positions.
T: Produce the architecture recommendation, knowing a fit-gap result can contradict people senior to you.
A: I ran a fit-gap evaluation: agreed the criteria with stakeholders first — workload shapes, batch versus near-real-time needs, CDC/SCD requirements, governance fit with Unity Catalog, licensing and run cost — then scored each option against criteria everyone had already signed. I presented the gaps per tool rather than a verdict, and let the scoring carry the argument.
R: Recover the specific outcome from memory before the loop — which option the fit-gap favored, who started elsewhere, and how the co-authored criteria carried the conclusion. Do not improvise it; the mechanism is what makes the story land either way.
Point: You win technical disagreements before the scoring starts: get agreement on how the decision will be made, and the decision makes itself.

Delivery tips: Never name a stakeholder as "wrong" — describe positions, not people. This story doubles as your conflict story and your truth-seeking story; vary the point sentence depending on which question summoned it.

Likely follow-ups: What were the actual decisive criteria? What if a stakeholder had vetoed the result anyway? When has a fit-gap told you something you didn't want to hear?

"Tell me about a time you disagreed with a senior stakeholder. What did you do?" Outline: Story 6. Do not open with the disagreement — open with the decision that had to be made. Action beats: (1) moved the argument from tools to criteria, (2) got the criteria signed before scoring, (3) presented gaps neutrally. Result: the real outcome you recovered from memory, told without naming a loser. Point: influence without authority is process design. Expected pushback: "what if they still said no?" — answer that you would disagree and commit, and say those words explicitly; interviewers listen for them.

Story 7 — Mentoring junior engineers through reviews and standards

Answers: developing others, leadership without a title, "how do you raise team quality".

S: At ADM, junior engineers on the team produced PySpark of uneven quality — working code with hidden costs: unmanaged shuffles, no idempotency, inconsistent patterns.
T: Raise the team's floor without becoming the bottleneck who rewrites everything.
A: I run design reviews before code exists, so direction gets corrected when it is cheap; I do code reviews against written PySpark standards rather than personal taste, so feedback reads as "the standard says" not "I prefer"; and I review for the why — making engineers explain a join strategy or partitioning choice rather than just fixing it for them.
R: Engineers I mentor ship to the same production pipelines I architect, against a shared standard, with less of my time per review over time.
Point: Mentoring scales when the standard is written down — review against a document and you teach the document, not dependence on you.

Delivery tips: Have one concrete review anecdote ready (a specific anti-pattern you caught and how you coached it) — pull it from memory before the interview; the generic version of this story is the weakest in your bank without it. Also be honest about the standards artifact: if your PySpark best practices live in review habits and templates rather than a single written document, say so — or write the document before the loop, because the follow-up below assumes one exists.

Likely follow-ups: Tell me about someone you grew — where are they now? How do you handle an engineer who rejects feedback? What's in your PySpark standards doc?

Story 8 — Production incident / hypercare (TEMPLATE — fill before interviews)

Your resume documents hypercare, monitoring, and runbooks via Azure DevOps across ADM orchestration (ADF + Databricks Workflows + RunMyJobs) — but no specific incident. You almost certainly have one. Recover it from memory before the loop and fill this skeleton. Do not improvise specifics in the room.

S: During hypercare for [pipeline / release] at [ADM / client], [the incident:
   what broke, e.g. failed load, late data, wrong numbers in an executive report].
   Detected via [detection: monitoring alert / data quality check / user report]
   — note honestly whether monitoring caught it or a human did.
T: I was on the hook to [restore correct data / unblock the refresh] within
   [the real constraint: reporting deadline, SLA, close calendar].
A: 1) Triaged: [how you scoped blast radius — which tables, which consumers].
   2) Diagnosed: [root cause — config, data, code, upstream system].
   3) Fixed: [the fix, and how you validated it before declaring victory].
   4) Communicated: [who you told, when, and what you committed to].
R: [time to resolution; consumers affected or protected; what the runbook
   gained]. Prevention: [the monitoring check, validation step, or runbook
   entry added so this class of failure is caught earlier next time].
Point: [your honest lesson — usually about detection or communication].

Answers (once filled): failure, pressure, ownership, "a time something broke in production", "a mistake you made" (if the root cause was yours — owning it cleanly is a stronger answer than a deflected one).

Delivery tips: Interviewers grade incident stories on detection honesty, communication during the outage, and prevention afterward — more than on the cleverness of the fix.

Never fabricate an incident, a metric, or a root cause. Experienced interviewers probe incident stories three follow-ups deep ("what exactly did the alert say?"), and invented details collapse under exactly that pressure. An honest "the data quality check missed it; a user caught it, and that's why I added the check" outscores a fictional heroic save every time.

When a question doesn't match any prepared story, fall back on the shape of your career rather than freezing: six employers, industries from lottery gaming and payments to chemicals, shipping, the public sector, and agribusiness, one repeated playbook — metadata-driven ingestion, medallion on Delta, governed serving, measured cost. You used that exact pattern at Maersk, PANYNJ, and ADM; "let me give you the pattern and one instance of it" is a legitimate, strong answer structure.

Question → story lookup

Drill this mapping until retrieval is instant. In the room you get about three seconds to pick a story; choosing well matters more than telling perfectly.

Question	Story	Angle to emphasize
Tell me about your most significant project.	1	End-to-end ownership; five source systems, CFO-level output.
Tell me about a time you led a team or initiative.	1	Cross-functional definition-setting; promotion as external validation.
Describe a time you dealt with ambiguity.	1	Disconnected sources, shared KPIs; lineage and governance as the resolution mechanism.
Tell me about something innovative you built.	2	Production GenAI, not a demo; trust mechanisms as the innovation.
How have you handled sensitive data?	2	UC row/column security under the LLM; salaries data in production.
What's your biggest measurable impact?	3	$10M program figure — with the composition ready, caveat stated first.
Tell me about a time you reduced cost.	3 (alt: 5)	Decommissioning over tuning; Ecolab ~$20K/month as the fully-yours backup.
Describe competing priorities or a tight deadline.	4	Two mandates, six months, fixed end date; design as prioritization.
Tell me about delivering for a difficult or constrained client.	4	Public-sector contract; hand over and leave — the RSA motion.
Describe a high-risk change you managed.	5	Dependency mapping first; success defined as nobody noticing.
Tell me about a disagreement with a stakeholder or engineer.	6	Criteria before scoring; positions, not people.
How do you influence without authority?	6	Co-authored criteria make stakeholders own the conclusion.
Tell me about developing or mentoring someone.	7	Written standards; review the why; one concrete anecdote.
Tell me about a failure or production issue.	8	Fill the template first. Detection honesty, communication, prevention.
Tell me about a mistake you made.	8	Only if the root cause was genuinely yours; own it without hedging.
Why Databricks? / Tell me about yourself.	—	Not STAR questions — use your positioning arc from the Interview Prep Track hub, then bridge into Story 1 or 2.

Final pass before any loop: re-verify the $10M composition, fill the Story 8 template from memory, and pick a concrete mentoring anecdote for Story 7. Those are the three open items in this bank — everything else is rehearsal.