Hardest data project deep dive, influencing without authority, and two-way feedback

These prompts come from the recruiter and hiring-manager conversations of a data engineering loop. Both conversations open with your background: your current team, how many people are on it, which part you own, what kinds of data you work with and how large it is. The three prompts below follow, and the interviewers probe each answer for detail. ### Clarifying Questions - How much technical depth do you want in the project walkthrough: architecture, data volumes, specific tools? - Should the project be recent, and is a team project fine as long as I make my own part clear? - For the feedback question, would you like a real example, my general approach, or both? ### Part 1 — Your hardest project Pick the project that was hardest to deliver and walk through it. Expect follow-up questions on where exactly you got stuck, which technology you used to get past it, what you personally did as opposed to the team, why you designed it the way you did, and who actually uses the result day to day. ```hint Lead with the obstacle Choose a project whose hardest moment you can name as one concrete technical problem, and have ready the alternative you considered and rejected. ``` #### What This Part Should Cover - The specific blocker and the technique or tool that resolved it - Your own decisions and work, separated from the team's - The design rationale, including the trade-off you accepted - Who uses the output and what changed for them, with a number where possible ### Part 2 — Earning buy-in without authority Tell me about a time you needed people you had no authority over, such as another team, a more senior engineer or a stakeholder, to accept your proposal or change how they worked. How did you get their agreement? ```hint Start from their side Think about what the other party stood to gain or lose from your proposal, and what evidence would have moved them. ``` #### What This Part Should Cover - Understanding the other party's goals and objections before pushing - Evidence, prototypes or small pilots rather than insistence - How agreement was reached, or what you did when it was not - The outcome and what you learned about influencing ### Part 3 — Giving and receiving feedback If you felt a colleague or your direct manager had handled something badly, how would you tell them? And the other way round: how do you handle feedback that someone gives you? ```hint Two directions, one habit Consider how timing, setting and specificity change between telling a peer, telling your manager and hearing it yourself. ``` #### What This Part Should Cover - A private, timely, specific way to raise an issue with a peer - How upward feedback to a manager differs in framing and setting - Receiving feedback: listening, clarifying, acting and following up - A concrete example in which feedback led to a visible change ### What a Strong Answer Covers - A short, structured introduction: team, size, scope, data types and volumes - Situation, task, action and result in each story, with concrete numbers - Clear ownership language ("I decided", not only "we did") - Technical choices tied to the people who use the result - Directness combined with respect, both in giving and in receiving feedback ### Follow-up Questions - If you rebuilt that project today, what would you do differently, and why? - Tell me about a time your proposal was turned down even after your best effort. What did you do next? - Your manager disagrees with the feedback you gave. How do you proceed? - What is the hardest feedback you have received, and what did you change because of it?