The most comprehensive bank Interview Answer Review tooling available online.

Understand the role/goals/priorities of the other org. Prepare a pitch/proposal covering:

• My project – summary + goal/objectives + expected impact + timeline
• What is needed from the org and how fits in the project plan. Why them and not the current proj team
• Discuss how the org will benefit from partnership and results to be realized
• Make very clear it is a partnership and specific asks/resources required and by what timeline/deadline

I follow RISK and Decision Log which basically captures risks regarding program since inception. This Log contains risk identified and discovered along with way as well as key decisions taken that influence that risk mitigation strategy. This risk log is review at every program review meeting with all the stakeholders and encourage discussions to identify next steps for resolution.

At Auctane, I had a senior dev working on tech debt, this was critical for some small segment of customers and my PM was looking forward to it being devliered. A churn happend on other team and they had a higher priority project. That EM approaced me to help him deliver the project. I had to reshffle the resource and had to push back on the timing for this tech debt project . The compramise I made was to put hold the project we had been working and convince my PM that this was most optimal approach for the company.

I was working on a high stake project with very high visibility from my senior management.

Me and my manager were thinking of can we leverage the quality of the development using help from QA team. He wanted to keep the QA team separate. His point of view was that a separate team would keep clear focus for the team and they would focus on finding more customer facing bugs. I thought that we should have QA embedded in the scrum team as that would help in easier collaboration and quicker bug fixes plus this is a more efficient way. Though I understood his point of view I always believed that in QA embedded inside the scrum team. I went back had a thought to measure the merits and demerits of the proposals. I put down in a slide the merits and demerits of each. Merit from having a separate team, clear focus and better filtering of quality, demerits less collaboration with development team. I then proposed that the QA engineers attend the calls of dev teams but keep a separate QA board for their tasks. This will give clarity of what bugs they find, what test scenarios they create and finally the metrics to measure the bugs reported per development. My boss and I both agreed as it solved the problems of each proposals

During final stages of testing upgraded version of core banking applications, we encountered a defect which required resolution from development team. After dev deployed the defect, I had very limited time to thoroughly retest and perform regression.

My task was to perform retesting and make sure there are no major defects after the release.

After resolution, based on my prior knowledge of the apps I grouped those testcases that had a potential impact to run automation regression to speed up the testing. While I manually tested the defects with some edge case scenarios. 

I kept the cross functional team updated about the testing progress and the risk involved if testing wasn't completed on time. 

But, I was able to mitigate the risk of not completing the testing on time and major risk of unexpected issues with the help to prior knowledge and proactive communication.

Thus, I learnt from this incident to carefully strategizing the situation and collaborative approach can help to mitigate risks.

In my role leading the launch of that new customer onboarding system, the pressure was really on. We had that tight three-month window and a lean team to build something that would be the first impression for all our new users. One specific hurdle we faced was integrating our legacy customer database with this brand-new system. The data structures were quite different, and initially, the data migration process was proving to be much slower and more error-prone than anticipated. This threatened to push our launch date.

To tackle this head-on, I didn't just delegate. I dove into the technical details with the lead engineer. We mapped out the data fields meticulously, identified the key transformation rules needed, and actually prototyped a more efficient data migration script using Python. This allowed us to automate a significant portion of the process that was previously manual.

Furthermore, to ensure we were building the right thing quickly, we implemented very short feedback loops. We'd build a small piece of the onboarding flow, get immediate feedback from a small group of internal users, and iterate based on their input. For example, early on, users found a particular step in the registration process confusing. Based on their feedback, we completely redesigned that screen within a couple of days, leading to a much smoother experience.

By getting into the technical weeds to optimize the data migration and by relentlessly focusing on user feedback through rapid iterations, we not only overcame the risk of a delayed launch but also delivered an onboarding experience that was significantly more user-friendly than initially envisioned. It was incredibly rewarding to see new customers move through the system so smoothly right from day one. That success really underscored the power of combining technical problem-solving with a user-centric approach

So I'd say the time I took the risk was, I actually went against the recommendation of my manager. Not directly, but essentially I was put on a project at Niagara and I was looking at a lot of the contract amendments and I analyzed our contract negotiation with Uber. And so as I was looking at the whole data, trying to see the discrepancies and really seeing, okay, what lanes should we negotiate, seeing what are the terms of negotiation that we should use, and then finally, I wanted to also forecast on terms of a long-term growth. So not just necessarily for just this term, but see how that would last for the future quarters as well. So kind of taking those into consideration while I put them all out into a matrix and showed the team, the director, and a lot of my team was thinking that we should go with the option that saves us the most amount of money. I'll put the $700,000 to $800,000 for the quarter, implementing this new amendment that I actually disagreed. And I suggested we just take somewhere closer to about the $600,000 range because for two reasons, one, I noticed that the lanes that we included in the $600,000 would lead to better client relations with Uber as a long-term and one of our biggest carriers. And two, I also noticed that in the long run, we actually would save a little more just because in the future quarters with seasonality to keep into account, those lanes were not always going to save us the most amount of money. So maybe while the $700,000 to $800,000 option would save us that much in the first quarter, when it comes down to the winter, it would save us only about $300,000 versus the $600,000 option is a little more consistent throughout the seasons. And so we actually noticed that in terms of a long-term growth for the year, we would save a lot more. So that was a time where I kind of took a risk to go against and maybe recommend something slightly different than my manager. But I think the director, when he heard me say these things, he took those into consideration and saw my analysis and saw that I was able to back up kind of my decisions and this type of risk to making sure I'm minimizing it as much as possible. So I think that was something that he really appreciated and that the VP of supply chain ended up deciding to work towards.

In my current role, there was a time when operation and engineering team was not aligned which was causing lots of delays during deployment. as per operation team build should be deployed in same branch which was available on pre-prod but as we were running multiple projects/features parallelly. it was difficult to develop and test everything in one branch and made it ready for deployment in a short time.

I had to work with my team (engineering team) and operational team to come up with a solution where we both are aligned and can reduce delivery time as well.

Initially i had proposed a solution when we were developing and testing work on feature branch and once its fully tested by QA on feature branch we push all changes to staging branch where we can do final testing. for some time this approach worked but we start facing new issue which is related to code merge as after merge features were impacting each other and require additional time to fix those issues and make it ready within planned time.

We added one more process if features/fixes are small and won't impact much then we merge else we try to plan deployment sequentially to avoid any further delay. 

This approach helped team to deliver project/feature on time and operational team was happy as they don't need to keep track of multiple branches during deployment.