STAR story bank¶

Fill in every Fill in before the interview. A real number beats a polished sentence.

1. The schema redesign (challenging project, impact, technical leadership)¶

S: In Index Research, our client-reporting app's database schema limited scale: onboarding a new client was hard and monthly reports to a large client base were at risk. Fill in: the concrete limitation.
T: Redesign it so clients onboard by configuration and reports deliver reliably, without disrupting the monthly cycle.
A: I analysed the queries and the data, designed a new schema (Fill in: key change), wrote a migration with backfill and reconciliation (compared old and new report outputs), added caching for reference data, optimised the slow backend steps, and released between monthly cycles with a rollback plan.
R: New clients onboard easily; reports reach the client base reliably every month. Fill in: before/after (onboarding time, run time, incidents).
Learned: migrate in reversible steps and prove equivalence with data, not confidence.

S: The Model Portfolios platform had to move to new EKS and EMR clusters. Fill in: why.
T: Migrate with zero downtime for advisors.
A: Built the green environment alongside blue, deployed the same version, smoke-tested, planned the tricky parts (Kafka consumers, scheduled EMR jobs, config/secrets), shifted traffic gradually while watching error rate and latency, kept blue ready for rollback, then decommissioned. Fill in: your specific role and one surprise.
R: Zero downtime. Fill in: services moved, duration.
Learned: the risky parts are the stateful edges (consumers, jobs), not the stateless services.

S: In Prayog I added a rule rejecting duplicate client order IDs.
T: Ship the rule without breaking recovery.
A: After restart the exchange traded for two minutes on a book that differed from what clients had been told: the new rule was applied to old history during replay, and recovery only checked that replay produced at least as many events. I found it by comparing the replayed log with the recorded one, then made rule changes journaled inputs (SetRules(version)) and made recovery compare every event byte for byte and refuse to start on any difference.
R: History now replays under the rules it was made with; any divergence stops the exchange instead of trading on a wrong book.
Learned: in a deterministic system, code is part of the input. My check was too lenient; I now verify exactly.

S: Prayog's Grafana showed new-order p99 at 445 ms with spikes to 3.5 s, while the host benchmark said 12 ms median.
T: Find the cause before changing anything.
A: Wrote a script to query Prometheus for latency quantiles and GC pause totals over the incident window. The JVM had picked the Serial collector in the 768 MiB container, and pauses were 6x slower than normal. Tried generational ZGC: pauses vanished but allocation stalls made p99 5x worse in that heap. Then used JFR to find where the matching thread allocated and replaced a boxed HashMap index with a primitive map.
R: Allocation per order down 12–21%; decision recorded (keep the default collector, give the container memory first) with the measurements.
Learned: check GC before blaming code, measure the window you care about, and a "better" tool can be worse in your constraints.

S: 2023 DeepRacer: our team of 6 couldn't tell why the car behaved as it did. 2025–26: I was city lead and SME for the AWS AI League at the Mumbai tech center.
T: Improve the team's results; later, run a site-wide program with volunteers.
A: Built a tool that drew what our reward function actually rewarded on the track, which made the fixes obvious. As city lead: onboarding, workshops on agent design and prompt engineering, office hours, unblocking teams, coordinating with AWS. Fill in: one hard moment (low turnout, a stuck team).
R: 2nd place in 2023; co-led DeepRacer for 700+ in 2024; Fill in: AI League participation/results.
Learned: making a system visible is often the fastest way to improve it, and people engage when they can see progress.

S: Fill in: a junior who joined Portfolio Insights / struggled with an area.
T: Get them productive and confident.
A: Paired on their first tickets, explained why in code review rather than just what, gave them a well-scoped feature to own, shared reusable AI skills and our conventions, and checked in weekly.
R: Fill in: they shipped X independently / now review others' code.
Learned: explaining the reason scales; giving answers doesn't.

S: Fill in: e.g. the product owner wanted a feature by a date that meant skipping tests, or a colleague wanted a design you thought wouldn't scale.
T: Reach a good decision without damaging the relationship.
A: Understood their goal first, made the trade-off concrete (risk, cost, options), proposed an alternative (thinner first version, a spike, a flag), and agreed to a decision and a check-in point. Disagree and commit if overruled.
R: Fill in.
Learned: most disagreements are about different information; put it on the table.

S: Java 8, iBatis and an outdated Sybase package were slowing releases and failing security scans.
T: I led upgrading to Java 17 and MyBatis without disrupting reporting.
A: Planned two steps (8 → 11 → 17), upgraded libraries and build plugins, fixed removed APIs and reflective access, migrated SQL maps to MyBatis, removed the Sybase package, ran full regression and compared report outputs.
R: Faster, more secure releases on a supported JDK. Fill in: duration, modules.
Learned: break risky upgrades into releasable steps.