Meta is betting Muse on partners it does not control. The question that tests whether you can work through one.
On September 24, 2026, TechCrunch reported from Meta's annual Connect event in Menlo Park, where Mark Zuckerberg opened the keynote by calling Muse, the company's few-weeks-old personal AI agent, the "centerpiece of our vision." The list of what Muse will do ran long: operate any app on a Mac, take on its own email address, guide a workout from a pair of Meta glasses, and buy almost anything through Shop Pay and PayPal. What stood out was who else was on the slide. TechCrunch listed partnerships with Stripe and Shopify, retail connections to Best Buy, Gap, Sephora, Walmart, and Wayfair, and connectors for Expedia, GitHub, Granola, and Notion, with Instacart to follow. Meta's chief AI officer, Alexandr Wang, said the company had received more than 1,500 applications from developers wanting to build their own "connectors" in under a week of opening the platform, and Zuckerberg said Meta expects to profit "by taking a small fee from transactions." Several timelines were left open. The glasses integration is due in "the coming months," and the agent's own email address is coming "soon," with no firmer date offered for either.
Read the partner list the way an engineer would. Every capability Wang described, from an agent that will "get work done for you" to one that buys a product you noticed through your glasses, runs through a company Meta does not own, with its own roadmap, its own margins, and its own reasons to say no. An agent you can "walk away from your computer" and trust is only as capable as the parties who agreed to be connected, and the fee Meta plans to take is a cost someone on the other side of each of those deals had to accept. The interesting work at Connect was not the model. It was the negotiation, repeated partner by partner, with counterparties that could not be routed around. That is the exact shape of a question managers get asked in nearly every behavioural loop, and it is why a keynote about integrations is also a question about you.
Why they ask it
The question is "Tell me about a time you worked with a difficult engineer / executive / stakeholder / client." Nobody asking it is checking whether you have met a difficult person. Everyone has. The interviewer wants three things. Whether you can tell the difference between a person who is hard and a person whose incentives differ from yours. Whether you can find out what the other party is actually protecting. And whether you can get the outcome without needing them to become a different person first. A manager who can only ship when the counterparty is agreeable is a manager whose delivery depends on the luck of the org chart, and interviewers at the senior levels have learned to price that risk.
The trap
The reliable failure is the villain story. The candidate spends the first ninety seconds establishing that the stakeholder was unreasonable, then describes surviving them. The interviewer hears two things: a person who never tried to understand the other side, and a preview of how the candidate will describe the interviewer's own colleagues in a year. A quieter failure is the escalation story, in which difficult meant wrong, the candidate went over the stakeholder's head, and a vice president settled it. That demonstrates access to a vice president, not the skill in question. The third is the story with no mechanism, where the two of them sat down, cleared the air, and it was fine. Fine how? What changed? Strong answers name the incentive behind the objection, in the other person's terms, and then name the specific thing that made saying yes cheaper than saying no.
Applying STAR-T
Situation. A hypothetical: your team is six weeks from a launch that depends on a read endpoint owned by a platform team. Their principal engineer has declined to expose it twice, and the written reason is that it is not on the roadmap. The real reason, which you only learn by asking, is that the last consumer of a similar endpoint doubled their on-call pages and never fixed a single one.
Task. Get the endpoint by launch without escalating over a colleague whose team you will need again next quarter, and without pretending the pager concern is irrational, because it isn't.
Action. Stop arguing about priority and start pricing the objection. Propose that your team carries on-call for the endpoint for its first ninety days, write the runbook before anyone asks, and put a rate limit and a kill switch under the platform team's control in the design. Put the offer in a document the principal engineer can forward, so they are defending a plan to their own manager rather than a favour. Set a standing fifteen-minute check-in for the six weeks so that surprises reach them from you, not from a page.
Result. The endpoint shipped in four weeks and the launch held its date. The platform team later turned the same endpoint into a shared service using the runbook your team wrote, and the principal engineer became the first reviewer you requested on the next cross-team design.
Trade-off. Your team absorbed a quarter of on-call it did not want, and roughly a sprint of velocity went with it. You also set a precedent that consumers carry the pager, which a later, smaller team found hard to afford. Say that. An answer that names what it cost is more credible than one in which everyone won.
The follow-up that breaks weak answers
What was their reason, in their words? A candidate who told a villain story has nothing to say, because they never asked. A candidate who told the escalation story will answer with their own reason rather than the stakeholder's. The strong candidate can state the objection back with enough specificity that the interviewer could take the other person's side, and then explain what they built to make that objection go away. A close cousin is if I called them today, what would they say about how you handled it? The answer should be something the difficult stakeholder would actually sign.
Score your answer against the director’s bar
Q: Tell me about a time you worked with a difficult engineer / executive / stakeholder / client.
Bank this story with the stakeholder's reason written in their own words, then rehearse it until the follow-up is the easy part. Try it free →