TL;DR: Run a two-tier system: a low-latency model on cheap request-time signals to gate the obvious abuse synchronously, and a slower behavioral/graph model that scores accounts over sessions for the subtle coordinated cases. Engineer weak and delayed labels, set the operating threshold by the asymmetric cost of a false ban versus a missed bot, route the uncertain middle to human review, and monitor for adversarial drift because the attacker retrains against you.
How to approach it
Clarify three things first: what enforcement actions the score drives (a silent flag, a CAPTCHA challenge, a rate limit, a hard ban) because the cost of a mistake sets the threshold; what the latency budget is (a login or post check needs sub-100ms, a periodic account audit can take seconds); and where labels come from, since this domain has almost no clean ground truth at decision time. Then design backward from enforcement cost and label reality, not forward from a model. The defining facts are extreme imbalance (positives well under 1%), adversaries who adapt, and labels that are scarce, weak, and delayed.
A strong answer
Split detection by latency and signal richness. A real-time tier scores every sensitive action (account creation, login, post, friend request, purchase) in single-digit to low-tens of milliseconds using cheap features: request rate, IP/ASN reputation, device fingerprint, header anomalies, time-since-signup, simple velocity counters from a feature store. Its job is to catch the loud, high-volume abuse synchronously and trigger a friction action. A near-real-time tier scores accounts over a session or rolling window with expensive behavioral and graph features: action-timing entropy (humans are irregular, scripts are not), graph signals (shared devices/IPs, near-identical follow graphs, creation-time clustering, embeddings from a GNN over the account-device-IP graph), and content similarity across accounts. Coordinated inauthentic behavior is invisible per-account and obvious as a cluster, so the graph tier is where you catch the campaigns the cheap tier misses.
Labels are the real problem. You rarely know at decision time who is a bot. Build labels from several weak, delayed sources and combine them: confirmed labels from human review and from accounts that later got actioned for spam/fraud; weak labels from rules (impossible velocity, known bot IP ranges) and from honeypots/tripwires that only an automated client trips; delayed labels from downstream outcomes (chargebacks, mass reports, takedowns days later). Treat these as noisy and use techniques like positive-unlabeled learning, because "not yet caught" is not "legitimate." The delay matters operationally: if it takes a week to confirm a bot, your training set always lags the current attack, which is exactly why monitoring and fast retraining are load-bearing.
Imbalance and metrics. With positives under 1%, accuracy is useless and even ROC-AUC flatters you. Optimize PR-AUC and report precision and recall at the threshold you will actually enforce at, plus recall on known attack families. Class weighting or focal loss beats blind oversampling; SMOTE on adversarial tabular/graph data tends to manufacture unrealistic positives and is a weak answer here. The threshold is a business decision driven by asymmetric cost: banning a real paying user is far more expensive (trust, support load, churn, press) than letting one bot through, so you bias toward precision for hard enforcement and accept lower recall, while using softer actions (CAPTCHA, rate limit, shadow restriction) at lower-confidence scores where a mistake is cheap and reversible. The cleanest framing is a tiered response by score band rather than a single ban/allow cut.
| Score band | Action | Why |
|---|---|---|
| Very high confidence | Auto-enforce (ban / block) | False-positive risk low enough; volume too high for humans |
| Uncertain middle | Challenge (CAPTCHA, 2FA, rate limit) or human review | Reversible friction; humans adjudicate and generate labels |
| Low | Allow, keep logging | Cheap miss; behavioral tier may still catch it later |
Adversarial drift and the feedback loop. Unlike watch-time prediction, your data distribution is an opponent. The instant you block a signal, attackers change it (rotate IPs, randomize timing, mimic human curves), so static models decay in days, not quarters. Counter it with: monitoring of score distributions and per-feature drift, recall tracked on a continuously refreshed set of known-bad accounts and on honeypots, scheduled and trigger-based retraining, and ensembling cheap-but-stable signals with learned ones so a single evaded feature does not collapse the model. Keep some signals secret and rotate tripwires; a fully transparent rule set is a spec for evasion. Watch the feedback loop carefully: if the model only ever sees the accounts that survived its own filtering, its training data drifts toward "bots that look human," which is the right next target but also a sampling trap. Inject exploration (occasionally let a flagged account through under shadow monitoring) to keep observing what evasion looks like.
Human-in-the-loop is not a fallback, it is the label engine and the safety valve. The uncertain band feeds a review queue; adjudications become high-quality labels, fuel an appeals path for false positives, and let you catch novel attacks the model has never seen before it learns them. Size the queue to reviewer capacity by tuning the band width.
What interviewers probe next
- "Attackers changed behavior overnight and recall cratered, what now?" Expect it: drift monitors and honeypot recall should alarm first, then trigger a fast retrain on freshly adjudicated labels, lean temporarily harder on stable cheap signals and graph clustering (campaigns still cluster even when per-account behavior changes), and widen the human-review band while the model catches up.
- "How do you avoid banning real users?" Asymmetric thresholds with tiered enforcement (challenge before ban), a human-review band and appeals path, precision measured at the enforcement threshold, and shadow-mode evaluation of any new model before it can action accounts.
- "Why a graph model and not just per-account features?" Coordinated inauthentic behavior hides in the per-account view and shows up as clusters (shared devices/IPs, synchronized creation, near-duplicate graphs); a GNN or community detection catches the campaign the request-time model cannot.
- "How do you get labels when you never know the truth at decision time?" Combine human adjudication, downstream confirmations (chargebacks, mass reports), rule-based weak labels, and honeypots, treat them as noisy, and use PU learning since unlabeled is not negative.
Common mistakes
Treating it as a static imbalanced-classification exercise: SMOTE plus optimize F1, no mention of an adversary. Optimizing accuracy or ROC-AUC at 1% prevalence instead of PR-AUC and precision/recall at the enforcement threshold. Picking a single ban/allow threshold and ignoring that a false ban costs vastly more than a miss. Assuming clean labels exist at decision time, when they are delayed by days and weak. Shipping a model with no drift monitoring and no retraining cadence, so it silently decays as attackers adapt. And designing no human-in-the-loop, which removes both the appeals path and the source of your best labels.
Key takeaways
- Two tiers: a sub-50ms cheap-signal gate plus a slower behavioral/graph model for coordinated campaigns.
- Labels are scarce, weak, and delayed; engineer them from review, downstream outcomes, rules, and honeypots, and treat unlabeled as not-yet-caught.
- Set the threshold by asymmetric cost: a false ban is much costlier than a miss, so tier the response (challenge before ban) and route the uncertain middle to humans.
- The distribution is adversarial; monitor drift, retrain fast, keep some signals secret, and judge online with PR-AUC and honeypot recall, not accuracy.