The most comprehensive bank Interview Answer Review tooling available online.

In the first company I worked as tech lead, even though my performance rating was good, I received a 360 degree feedback on my interpersonal skills as well. One of them said that I sounded a bit rude in couple of discussions. When I asked for the instances, I got examples where I got the feedback from and not whom. So I had to explain my manager that it was not intentional and the aggressive demanding nature of mine could have been perceived as rude. But I considered the feedback and identified, corrected myself, toned down the way I speak in certain instances which made a set of teams in my org ex: production support teams reach out to me more often now for guidance. So this helped me gain valuable experience and unlock a totally different perspective in terms of collaboration with other squads in the company.

Situation:
While working on the CloudGate (CASB) program at Oracle, I had to collaborate closely with a lead engineer who was highly technical but often resistant to input from non-engineering stakeholders, including program managers like myself.

Task:
Our shared goal was to integrate CloudGate’s policy engine with a third-party SaaS provider under tight deadlines for a compliance milestone. Coordination was critical, but communication friction risked delaying delivery.

Action:
I focused on building mutual respect by first acknowledging his technical expertise and then shifting our interactions to be data- and goal-driven. Instead of pushing process, I came to discussions with clear risk/impact scenarios and timelines tied directly to customer and audit deadlines. I also adapted my style—fewer meetings, more async updates with technical clarity—which matched his preference. Gradually, we established a working rhythm built on outcomes, not personalities.

Result:
We delivered the integration on time, passed the compliance audit, and by the end of the project, had built enough trust that he started proactively surfacing risks to me before I had to ask. The experience reinforced for me that adapting communication style and focusing on shared goals is often more effective than trying to change personalities.

I would analyze the following for each of the tasks at hand

• I would first evaluate if there are alternative solutions to temporarily address one task. A quick fix might free up the resources to completely focus on the next task and reduce urgency on this task

• I would evaluate to see if one task can be broken down further and still be able to deliver value to the customer. For Example - deliver functionality over trendy user interface

• I would assess potential risks on business metrics if the tasks are not delivered - revenue, retention rate, operational efficiency

• I would evaluate the team expertise and identify if there is anyone with a higher expertise level who can help expedite on one task

Once I have gathered this information, I will prioritize the tasks based on my assessment on impact on business goals and customer outcomes. Throughout this process I ensure transparent communication with the stakeholders, aligning their expectations and ensure that the team understands the rationale behind the decision.

I have handled several such situations. For example - I had to choose between an important feature update and a performance issue affecting all users. By assessing the risks and leveraging team’s expertise, we delivered a partial feature update while simultaneously fixing the performance issue. This approach ensured we addressed immediate concerns without losing sight of broader goals.

while reviewing one of the older projects that was currently implemented in the company I noticed that there was no alerting in place if the data pipeline breaks, the data pipeline has never been broken and it never failed for the last 2 years. it was a pipeline where the data would be dropped into an sftp bucket by the customer every hour and then it was moved to an s3 bucket where s3 triggers were implemented to moved the data in to queue. So in case there is an issue with the data not being processed we would only know when the we see a drop in volume. I identified it as a potential issue with the system and worked on a proposal to have monitoring in place so we are notified when there is an error. I worked with the program manager and devised a plan on how to implement the alerting and the time lines as well as the effort that will be needed to implement it. I mapped the impact of not having it to the current goals of the company and then put forward a proposal of implementing the alerts to the business and took their buyins. after getting the buyins I proposed the task to my team and some of the sr devlopers were not too keen on implenting the alerts, I gave the task to some of the Jr devlopers and the alerts were implemented. after the implementation we discovered that for some hrs in a day we werent getting any files so instead of getting 24 files in a day we were getting 20 files a day in an average. This was rectified by talking to the customer and the missing data was solved. but this made the whole team realize the importance of monitoring and alerting. It also bosted the moral of the Jr developers seeing the direct impact they made to the business goals

We had to decide whether or not to keep investing in, or sunset a feature that came out of a hackathon project. The feature itself was well-coded, and the design was created by a designer, and functionally it worked. However, it was built on an untested assumption that customers would actually get value from automating and thus losing some control over a fairly sensitive and infrequent workflow. That meant that the feature was launched as quickly as possible due to the hackathon nature, and (i) confused customers, as it wasn't in our public roadmap or well packaged in the app, and (ii) led to low adoption and thus no meaningful testing feedback to further develop the feature. While there were hypotheses that an adapted version of the feature could be more valuable (and verified during sales demos) for a new, larger customer segment - we decided to instead deprecate the feature as it was a distraction, and not a high impact investment at the time given other priorities. 

Learning: 

- Have a product person leading any new feature, so that there is a clear value hypothesis and alignment with GTM functions to launch and communicate the feature successfully to customers 

- Do not assume that customers will want to adopt something just because they mention it 

- Well coded, designed feature without a clear value prop is still without value 

1) Clarify the objective - so just for clarification, the objective of this case is to design an alarm clock that will be specifically be used by users without their sight?

Okay great

2) Identify the user - In this case we will be dealing with people who are unable to see, but can use their other senses

3) Identify pain points that blind users may have with the current features of the alarm clock. 

Blind users may have an issue locating the alarm clock

Blind users are unable to see the time on the clock 

Blink users are unable to set the alarm 

Blind users may have trouble locating the power cords or knowing if the batteries are running low

4) Prioritize the pain points and pick two to move forward with. Discuss value to user - 

Most important pain points is that Blind users are unable to see the time on the clock

Blind users may have trouble locating the power cords or knowing if the batteries are running low

5) User value and effort to implement improvements for each pains point 

Implementing a voice activated alarm clock that tells you the time when the user asks what time it is, this voice activation feature would also allow the user to set the alarm with voice activation

6) Recommendation - 

I recommend that in order to update the design of an alarm clock to best fit the needs of blind users, we should invest in voice activation technology in order to tackle the pain point of users not being able to see the clock and users being unable to set the alarm. Although there would be some knowledge transfer/additional resources to be learned in the process of implementing voice activation feature for blind users, I believe that the value being delivered to the customer heavily outweighs the cost of effort that will be required for our team to implement this. 

I would establish a priority list dependent on the impact each ask has on the company.  The higher the impact, the higher the priority.  I would assess how long each ask takes and then speak with the stakeholders letting them know that I support their ask.