The most comprehensive bank Interview Answer Review tooling available online.

During my early days at Teradata in 2015, I received critical feedback from my manager and colleagues that, although I had strong technical skills, I wasn't very vocal in expressing my opinions during discussions. I initially found this feedback difficult to accept because I believed that my work alone should be enough to communicate my value.  The task was to enhance my communication skills, particularly during team discussions and design reviews, to ensure that my thoughts and ideas were being heard and valued, rather than relying solely on the quality of my technical work.  Taking the feedback to heart, I made a concerted effort to prepare thoroughly for design discussions and technical meetings. I started to actively participate by sharing my opinions on the designs, asking questions to gain clarity, and offering my technical insights. Additionally, I sought feedback from my colleagues to better understand how I could communicate more effectively in these settings.  By consistently engaging in discussions, I found that my opinions were appreciated and valued, which led to more productive conversations and collaborations. This not only helped me build stronger relationships with my teammates but also improved my overall presence in the team. Over time, I became more confident in expressing my ideas and saw growth in my ability to communicate complex technical concepts more clearly and effectively.

I’m my current role, during a core-team meeting I noticed conflicts between 2 team members, the MM and the EE. They were debating about why to include one component in the official BOM and discarding another one.

To understand their perspectives, I spoke with them separately in a friendly environment. The MM was frustrated because the EE didn’t provide any data or argument to discard the component that the MM suggested. This component had the same performance, was pin to pin compatible, and cheaper. On the other hand the EE explained he had bad experiences in the past with the component suggested by the MM and he refused to validate and qualify it to do not waste his time.

So… After being clear about the situation, I brought them together for a discussion and I emphasize to focus on the issue, not in personal discrepancies. Do, during the meeting, I encouraged both to consider the Project requirements, customers need and I worked with them brainstorming session.

Then, they agreed to meet with other stakeholders to get their inputs about these 2 components, they commit on a validation plan including both components. The one suggested by the EE as POR and the one suggested by the MM as alternate. They also agree to allocate 60% of the mass production volume to the EE component and 40% to the component suggested by the MM.

From my side, to ensure progress, I scheduled follow-up meetings with them to monitor their collaboration and for sure, I offered my support. Finally, both components are currently part of the product official BOM and these 2 guys improved their working relationship and communication.

Scope of the project needs to be agreed upon and documented at the beginning of a project in initiation and planning phases. There should be prioritized list of requirements that are in scope, requirements that didn't meet the cut and other things that are out of scope. With time requirements may change due to external and internal factors. Customers may ask for new things, the team may have new learnings, priorities may shift due to changes in competitive landscape, etc. It is important to have change control process such as a change control board and a template for requesting and approving change requests. Reviewer, Approver, Consulted and Informed should be define for change requests. Impacts on other parts of the projects, dependencies, risks and assumptions should be considered. If the scope impacts the critical path then the timeline and budget should be adjusted. Agile is a good framework to handle scope creep as there is an opportunity to adjust the sprint backlog at the beginning of every sprint. As an example, while developing a VR game customers requested that it support certain new types of drills for practice. I drove the effort to understand the impact of adding those drills to budget, timeline and quality and propose a plan to customers on when those drills could be added that they were happy with. This allowed us to deliver the initially committed game in phase 1 and do a fast follow with the requested drills in phase 2 after initial launch.

Knowing the history of a project is good but not a requirement to successfully deliver a project. The way to estimate the expected work, would be to understand what is the business problem and then understand who are the various stakeholders responsible for delivering the project. Here are a few bullet points:

1) Having a clear understanding of the business need:

· I once organized a session where we clarified ambiguous requirements, which reduced delays caused by misaligned expectations.

2) Are the business requirements completed?

· I’ve worked on projects where siloed communication created bottlenecks, so I established cross-functional syncs to break down barriers and complete the business requirements.

3) What tools are being used to track the project delivery? Jira, Azure DevOps etc?

· I kept on-going discussions with the lead scrum master to identify what types of meaningful dashboards would help us be transparent on the progress of the project.

4) Are the technical requirements signed off on?

5) How many stakeholders are assigned to the project? Both on the business and technical side?

6) Any on-going risks being tracked?

· There was a time when I flagged an issue with the data that would have become a significant blocker later on, but identifying it early led to active remediation steps.

7) When is the expected delivery?

8) List out all the tasks that are necessary to complete the project and expected timelines for each task.

· This step helped me in a project where there were tight deadlines and the project was complex with multiple unknowns. Having a tracker helped the team stay on track.

9) incorporate any existing blockers into the timeline as a risk table to assess how much work is required and when it is likely to be delivered.

I was once tasked with a project as a business analyst which had several business analysts who had worked on the project in the past leading to unsuccessful attempts in product delivery. When i was tasked to the project i started by meeting with people and understanding what was required for the project to complete. After a long series of meetings and understanding of what work is entailed and getting all my questions answered by the stakeholders and getting required sign off, I was able to ship the project.

When buildling the next generation instance, during the planning phase I budget the amount of servers we will launch the product with. Given each server cost was over 2 million dollar I biased to towards frugality and provided a bare minimum number of server we could launch with. But what I completely missed was during the developement some servers will end up in bad state and the engineering team will short of servers to test the software and firmware getting built which made meeting the project timeline riskly and heavily dependent on delivery schedules of servers and them staying healthy. This quickly became a bottleneck that I realized. I quickly put togther a plan to request adittional server and provide a detailed breakdown on where and how these would be used during and after developement. Synced with the hardware and ODM team and executives to get a approval and ordered the parts to get the servers and racks build at ODM. 

Generally, the program life cycle is Initiation, Planning, Execution, Monitoring and Controlling, Closure. So, you start with the initiation phase where you discuss program goals and their alignment with company mission and vision with the program sponsors. Next, I would identify the stakeholders and discuss the goals and alignment with them.  Next, step is to work with stakeholders to come up with prioritized list of requirements based on reach, impact, confidence and effort and alignment with company mission as part of program planning. I would also document all the risks, assumptions, issues and dependencies and develop mitigation plan. Make sure mitigation plans and dependencies have owners and due dates assigned, I would create communication plan that  defines the format of the status report, distribution list and cadence of reports. Setup communication channels like Slack groups. Setup a series of meetings for the stakeholders to sync regularly. This is how I would start a program. The next would be execution, controlling and monitoring and closure. Would you like me talk about those? 

At hyperface we got requirement from product team to build a nudge engine, this will be a configuration driven engine and when a condition is met based on the configured communication pattern it is going to send the communication. Example : If user have done 5 transaction is flikart and an offer is going on to do 10 transactions to get a reward we will nudge user based on the communication channel and rules that nudge him on whatsapp this much time and send him the push notification.

When this product requirement came , product wanted to build each and everything as a single engine, but at that time I realized that having a separate notification service which will take care of all notification related stuff and we will be able to efficiently scale that system and prevent having a tight coupling  will be very helpful , but when I proposed this product did not agreed as they thought right now there is no usecase for making nudge engine and notification engine a separate component.

At that time I dicsucces this with my fellow EM and came to know that they are scenarios where they need to send notification for example otps , push notification and everyone is handling this in a custom way in there own code based . With all this data I went back to product team ann pitched them that having this notification engine all this custom handling will be gone we will have better mechanism to control notification  track metricies and and improve the experience by handling failure scenarios .

with this data I was able to convenience the product team to build to different systems.