Staffing a Three-Engineer Team Across Account Takeovers and Spam as New Facts Emerge

You are a product manager at Meta with three engineers and two integrity problems competing for them: people reporting that their accounts were hacked, and people complaining about spam messages, including spam email. Decide how to divide the three engineers. The interviewer reveals new facts in stages, so expect your answer to move, and be ready to say exactly which fact moved it. ### Clarifying Questions - Which product and channel are involved: is the spam arriving by email, as in-app messages, or both, and do the hacked accounts belong to the same product? - Do the 1,000,000 spam complaints come from 1,000,000 different people, or are many of them repeat reports about the same senders or campaigns? - Over what time window did these reports arrive, and how do the counts compare with a normal period? - Apart from the three engineers, what already exists: automated spam filtering, a security team, support staff who handle account recovery? ### Part 1 — Split the team using the reported volumes There are 4,000 reports of hacked accounts, not yet verified, and 1,000,000 complaints about spam. Explain what should decide the split, then assign each of the three engineers and say what each one works on first. ```hint Counts are not harm A report is not a harmed person. Think about what one report is worth if it is true, how likely it is to be true, and how much an engineer can actually reduce each problem in the next few weeks. ``` #### What This Part Should Cover - A comparison of the two problems that goes beyond raw counts: harm per real case, the chance a report is real, and how reversible the damage is. - The leverage of one engineer on each side, such as fixes that remove many complaints at once versus work that protects accounts one flow at a time. - A concrete assignment with a first task per engineer and a stated trigger for revisiting it. ### Part 2 — Half the hacked-account reports are real Verification shows that 2,000 of the 4,000 hacked-account reports are genuine. Does your allocation change? Explain why or why not. ```hint Two things this number reveals The figure settles one unknown from Part 1, and it also says something about the reporting channel itself. Use both. ``` #### What This Part Should Cover - How 2,000 confirmed takeovers changes the Part 1 comparison, ideally stated as an explicit break-even between the two problems. - What a 50 percent false-report rate means for real victims waiting in the queue and for how far the spam complaint count can be trusted. - The revised assignment and the first thing the account-security engineers do. ### Part 3 — The confirmed accounts belong to celebrities You now learn that the 2,000 confirmed hacked accounts all belong to celebrities. How does that change your assessment and your allocation? ```hint Audience and pattern Consider what a hijacked account with a very large following can do within an hour, and what it suggests that so many high-profile accounts show up in one batch of reports. ``` #### What This Part Should Cover - How audience size changes the harm of a single takeover, including trust and press consequences for the platform. - Whether the pattern points to a coordinated attack with a shared entry point, and why that changes urgency. - The new allocation, how long it lasts, what happens to spam work meanwhile, and which other teams get involved. ### What a Strong Answer Covers - One explicit comparison model (volume, validity, severity per case, reach) applied consistently across all three parts. - A committed split at every step, with the specific fact that moved it. - Whether the two problems interact, for example whether hijacked accounts are a source of the spam. - Success metrics and guardrails for both workstreams, including the cost of false positives. - Levers beyond the three engineers: existing filters, support operations, security and communications partners. ### Follow-up Questions - Two weeks later the celebrity incident is contained but spam complaints have doubled. How do you decide when to move engineers back, and what evidence do you need? - Would you give high-profile accounts stronger protection than ordinary users get? Defend the choice. - Which metrics would convince you the takeover incident is over rather than just quiet?