The most comprehensive bank Interview Answer Review tooling available online.

Thank you for the question. I have been working as a data engineer for a combined total of three years, working closely with business leaders and engineers at different enterprises. where my main focus and speciality was in building reliable data pipelines that supports business decision making. I also have experience running a solo consultancy firm, where I have had the opportunity to consult and build end to end data products for businesses, which has allowed to be explore and hone my leadership, and communication skills on top of my technical expertise. Above all. in addition to the skills  I have learnt over the last three years, my experience in academia, especially as a consequence of my PhD research, I have a strong preference and a proven track record  in delivering complex analytical tasks.  All of the above essentially package me up as  an ideal candidate for this role.

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.

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.

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.