Salesforce — Cyber Security Detection — Product Case Questions
Role context: Data Scientist (SMTS), Cyber Security Operations Center · Est. study time: 60 min · 5 questions
How to approach product cases here
Every case is one move in the same chain: understand the goal, break it into a data problem, choose the metric or method, name the bias and the trade-off, land on a decision and an action. Walk it out loud and survive the follow-ups.
Five things make security detection cases distinctive. Internalize these and most questions become tractable.
1. Your data has an adversary. This is the property that separates security from every other data science domain. A threshold is not a parameter, it is a public commitment your attacker optimizes against. Salesforce's own writing names the response: low-and-slow exfiltration, "reports of modest size spread over multiple requests," designed to sit under whatever line you drew. Your model's success causes its own obsolescence.
2. The label is context, not content. In the words of the VP who runs this org: "The same signal represents either normal business or a real attack depending entirely on context." An employee running a script is IT automation or an intrusion, and the event cannot tell you which. That is why the work is correlation rather than classification.
3. Recall is not computable. The denominator is attacks you missed, which you cannot see. Any number presented as recall is really "recall against attacks we already know how to find." The honest substitutes are technique coverage, purple-team exercises, and retrospective hunting. Saying this plainly is a senior signal.
4. The binding constraint is analyst attention, not statistics. At several hundred alerts a day, the analyst-hour budget binds long before the loss function does. A low-precision detector gets muted, and a muted detector has an effective recall of zero regardless of what its offline evaluation said.
5. Anomalous is not malicious. In an enterprise of 80,000 people, most statistical anomalies are a new laptop, a VPN, a conference trip, or an intern discovering the export button. The gap between those two words is the central difficulty of the job.
The traps: computing accuracy on an imbalanced problem, treating an agreement metric as validation, lowering a threshold to "catch more," and claiming credit for a breach that did not happen.
This is a detection science role rather than a product role, so the five below weight source evaluation, measurement design, diagnosis under adversarial drift, an autonomy decision, and impact measurement where the counterfactual is unobservable. There is deliberately no growth or funnel case: this team is never asked whether to ship a feature, it is asked whether a detection is real, affordable, and still working. That skip is the signal. If you only have time for two, do bc1 and bc4.