Sort Threats by Severity and Exploitability - Video Solutions

Problem Overview: You receive a list of security threats where each item includes two ranking signals: severity and exploitability. The goal is to order the threats so the most dangerous ones appear first. Sorting must prioritize higher severity, and when two threats share the same severity, exploitability becomes the tie‑breaker.

Approach 1: Brute Force Pairwise Ordering (O(n²) time, O(1) space)

A direct way to solve the problem is to repeatedly compare every pair of threats and swap them if they are out of order. The comparison rule checks severity first and then exploitability when severities match. This behaves similarly to simple algorithms like bubble sort or selection sort. The implementation is straightforward and clearly expresses the ordering rule, but it performs poorly for large inputs because it scans the array multiple times. Time complexity is O(n²) and extra space remains O(1).

Approach 2: Custom Comparator Sorting (O(n log n) time, O(log n) space)

The practical solution uses a standard library sort with a custom comparator. Each comparison evaluates two fields: first compare severity, then exploitability if severities are equal. Most modern languages allow passing a comparator or key function to the sort routine. Under the hood, algorithms like Timsort or introsort handle the heavy lifting. You iterate once to call the sort function, and the comparator ensures threats are ordered correctly. The runtime is O(n log n) with O(log n) auxiliary stack space depending on the implementation.

This approach works naturally with arrays because the elements can be compared directly during sorting. If threats are represented as objects or tuples, the comparator simply extracts the two attributes and applies the ordering rule. Many implementations convert the ranking rule into a tuple key like (-severity, -exploitability) so that a single built‑in sort operation handles both priorities.

Approach 3: Counting / Bucket Sort (O(n + k) time, O(k) space)

If severity and exploitability values come from small bounded ranges, a non‑comparison sort can outperform general sorting. You create buckets for each severity level and place threats accordingly. Within each bucket, threats are ordered by exploitability using another counting pass or small local sort. This reduces the runtime to O(n + k), where k represents the range of possible values. The tradeoff is additional memory proportional to the number of buckets.

Recommended for interviews: The custom comparator sorting approach is what interviewers expect. It demonstrates that you can translate a multi‑field ranking rule into a deterministic comparison while leveraging efficient built‑in algorithms. Showing the brute force idea first proves you understand the ordering logic, while the O(n log n) solution highlights practical problem‑solving with sorting on top of a simple array structure.