Abnormal Ai·Software Engineer·Onsite - System Design / Architecture
May 2026
Abnormal AI's software engineering interview dropped me into a real security-event processing codebase and asked me to extend it in two meaningful ways. It was a hybrid of system design and live coding, which I wasn't fully prepared for. The problems were meaty and the follow-ups had real teeth.
- How would you design a rule suppression system that lets operators suppress specific detection rules under certain conditions, while keeping the suppression auditable so compliance can still see what was hidden and why?
- Should suppression run before rule evaluation to save compute, or after a rule fires so you get a full audit trail of what would have alerted? How does the auditing requirement change your answer?
- How do you handle overlapping suppressions, and do you support time-bounded suppressions like maintenance windows with automatic expiry?
- Redesign the enrichment layer so customers can enable, disable, reorder, or add enrichment logic without touching platform code. Implement the plugin interface, a registry, the composed chain, and config-driven assembly.
- Compare the decorator pattern to a plain ordered pipeline for enrichment. When does each approach win?
- How would you safely run untrusted customer plugins, including sandboxing, resource limits, and restricting what APIs the plugin can call?
- How do you hot-reload suppression config or enricher plugins without dropping in-flight events or double-processing them?
- A customer says an alert that should have been suppressed still fired. How do you debug the composed enrichment chain and the suppression matching logic?
- How would you version the plugin interface so existing customer plugins keep working when the platform upgrades?
“This one took me a minute to scope properly.”