The most comprehensive bank Interview Answer Review tooling available online.

Context: One of the most challenging situations I had to deal with recently was deciding whether or not to expand features on a product we had just launched. The product scans our customers' websites periodically and reports on trackers and pixels that could jeopardize user privacy data. We assumed that customers would also want the ability to select trackers in the reports and implement blockers we provide. This feature would require significant engineering resources and effort, and I wanted to ensure we were building the right thing.

Decision process: To approach this decision, I consulted with stakeholders, conducted customer interviews, and collected data for analysis. This involved engaging with our product team, engineering leads, and a sample of our customers to gather diverse perspectives and validate our assumptions.

Outcome: Ultimately, we decided to proceed with the feature, but we scoped it just enough to gather more signals. This decision was difficult because, while early research showed potential, the evidence was not yet strong. We had to balance immediate resource allocation with other priorities. We managed to secure buy-in from the product team and other stakeholders based on our research findings. 

Learning: This experience taught me the critical importance of researching customer interests for product development. Being flexible with project scope and ensuring stakeholder buy-in were crucial for the project's success. In future, I would allocate more time for this research phase ahead of major decisions to ensure we are aligning our efforts with customer needs and organizational priorities.

Risk assessment at the beginning of any project/initiative is critical for the successful delivery. I have set up the right mechanisms in the teams that I was leading to identify risks early enough to avoid surprises. First, I ensure that the scope is identified and carved out clearly. Second, I identify the dependencies and owners for dependencies. I assess any security, compliance risks that we can potentially encounter. I also ensure that the proper acceptance criteria and success metrics are established for the project goals. Mechanisms that I use are 1/ defining SMART goals for the project with clear success metrics, milestones and dependencies 2/ mechanism to fill in threat model once the high level design is complete 3/ engage external stakeholders for appsec, pentest and regionalization early in the project phase 4/ set up recurring session with external dependency teams to track status and progress 5/ have risk assessment captured as part of the design doc and a mechanism to escalate if we identify any new risks during the execution of the project. 

In the Meraki integration project, the supply chain process required significant optimization of the entire flow. To achieve this, most of the shipping-related process needed to be modified. However, the team lacked sufficient time to complete the work because the planned use of an adapter did not work, requiring me to redesign the flow.

With limited time remaining before system integration testing (SIT), the cross-functional teams and other tracks were ready to test their code, and management was unwilling to postpone SIT and Cycle 1 testing. Since there was an additional round of SIT and Cycle 2 testing planned, I decided to proceed with the changes that the team had already completed. We migrated the completed code to the test instance and communicated that only Phase 1 of the changes would be released initially, while the remaining changes would be delivered during Cycle 2 testing.

I ensured the Phase 1 delivery was designed to avoid impacting the end-to-end flow, allowing the other teams to proceed with testing their portions of the code. This approach ensured that other teams' deadlines were not affected. I also informed the cross-functional teams that the OTM and GTM changes were completed, and the remaining shipping-related code optimization would be delivered before Cycle 2 testing, along with the next round of SIT.

By taking this approach, I ensured that complete testing was not impacted and that the project stayed on track.

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.

At Auctane I would do the following:

a) How did i execute on projects and measure on Impact to customes and business

b) How did i empower my team mates to grow in thier carrer - either by help them get promoted or switch roles

c) How did I grow personally?

By measuring these and continuly coarse correcting to be a better manager is how i reflect as a EM

I would like to talk about situation. When I was an engineering  manager at digital commerce platform org at Amazon, I was handling close to 11 services, and 

as part of the Rolling Stone initiative where Amazon was trying to move all its services away from Oracle, I had four services that I was trying to migrate from Oracle to the databases hosted on Azure. All my fellow colleagues who were owning services of DCP were doing similar exercise. One of the colleague who was owning digital redemption service had to go on maternity leave, and then couple of engineers earmarked to do this migration for digital redemption service wwere transition out of the organization. That is when I offered to help with the migration of the service. 

So I now had 5 services with competing  priorities where I 

had to manage very tight schedule of service migrations. Planning a very ruthless prioritization, figuring out an optimal execution path of a completely unknown service, interacting with the service upstream clients whom i had not worked with prior, working with an amalgam of My team members and the service owner team members were few of the ambiguous paths I navigated to help do on time migration completion of the   service owned by my collegues.