Enforce Business Rules

private Boolean datesOverlap(Date startA, Date endA, Date startB, Date endB) {
    return startA <= endB && startB <= endA;
}

A direct translation of Lesson 1's formula into a small, well-named private helper — this is Module 12's habit of extracting a clearly-named private method, applied from the very start rather than as an afterthought.

public void beforeInsert(List<Leave_Request__c> newRequests) {
    Set<String> employeeNames = new Set<String>();
    for (Leave_Request__c req : newRequests) {
        employeeNames.add(req.Employee_Name__c);
    }

    List<Leave_Request__c> existingRequests = [
        SELECT Id, Employee_Name__c, Start_Date__c, End_Date__c
        FROM Leave_Request__c
        WHERE Employee_Name__c IN :employeeNames AND Status__c != 'Rejected'
    ];

    for (Leave_Request__c newReq : newRequests) {
        for (Leave_Request__c existing : existingRequests) {
            Boolean sameEmployee = newReq.Employee_Name__c == existing.Employee_Name__c;
            Boolean overlaps = datesOverlap(newReq.Start_Date__c, newReq.End_Date__c, existing.Start_Date__c, existing.End_Date__c);

            if (sameEmployee && overlaps) {
                newReq.Start_Date__c.addError('This leave request overlaps with an existing request.');
            }
        }
    }
}

Two nested loops — both purely in-memory (Module 25's key requirement), no SOQL or DML inside either one. Every new request is checked against every relevant existing request, and addError() blocks any genuine overlap with a clear message.

Nested loops can look alarming, but bulk-safety is specifically about SOQL queries and DML statements, not about loop nesting itself — Module 25 never said "avoid nested loops," it said "avoid SOQL/DML inside a loop." This nested comparison runs entirely against data already fully loaded in memory (newRequests and existingRequests), so it costs zero additional queries or DML statements no matter how many times it iterates.