Friend Requests I: Overall Acceptance Rate - Solution & Explanation

EasyPremiumFree on FleetCodeDatabase4 min readAsked at: Meta

Problem Statement

Table: FriendRequest

+----------------+---------+
| Column Name    | Type    |
+----------------+---------+
| sender_id      | int     |
| send_to_id     | int     |
| request_date   | date    |
+----------------+---------+
This table may contain duplicates (In other words, there is no primary key for this table in SQL).
This table contains the ID of the user who sent the request, the ID of the user who received the request, and the date of the request.

Table: RequestAccepted

+----------------+---------+
| Column Name    | Type    |
+----------------+---------+
| requester_id   | int     |
| accepter_id    | int     |
| accept_date    | date    |
+----------------+---------+
This table may contain duplicates (In other words, there is no primary key for this table in SQL).
This table contains the ID of the user who sent the request, the ID of the user who received the request, and the date when the request was accepted.

Find the overall acceptance rate of requests, which is the number of acceptance divided by the number of requests. Return the answer rounded to 2 decimals places.

Note that:

The accepted requests are not necessarily from the table friend_request. In this case, Count the total accepted requests (no matter whether they are in the original requests), and divide it by the number of requests to get the acceptance rate.
It is possible that a sender sends multiple requests to the same receiver, and a request could be accepted more than once. In this case, the ‘duplicated’ requests or acceptances are only counted once.
If there are no requests at all, you should return 0.00 as the accept_rate.

The result format is in the following example.

Example 1:

Input: 
FriendRequest table:
+-----------+------------+--------------+
| sender_id | send_to_id | request_date |
+-----------+------------+--------------+
| 1         | 2          | 2016/06/01   |
| 1         | 3          | 2016/06/01   |
| 1         | 4          | 2016/06/01   |
| 2         | 3          | 2016/06/02   |
| 3         | 4          | 2016/06/09   |
+-----------+------------+--------------+
RequestAccepted table:
+--------------+-------------+-------------+
| requester_id | accepter_id | accept_date |
+--------------+-------------+-------------+
| 1            | 2           | 2016/06/03  |
| 1            | 3           | 2016/06/08  |
| 2            | 3           | 2016/06/08  |
| 3            | 4           | 2016/06/09  |
| 3            | 4           | 2016/06/10  |
+--------------+-------------+-------------+
Output: 
+-------------+
| accept_rate |
+-------------+
| 0.8         |
+-------------+
Explanation: 
There are 4 unique accepted requests, and there are 5 requests in total. So the rate is 0.80.

Follow up:

Could you find the acceptance rate for every month?
Could you find the cumulative acceptance rate for every day?

Approach Overview

Problem Overview: You are given two tables: friend_request (all sent requests) and request_accepted (requests that were accepted). The task is to compute the overall acceptance rate, defined as accepted requests / total requests. The result must be rounded to two decimal places, and if there are no requests the answer should return 0.00.

Approach 1: Aggregate Counts with Subqueries (O(n) time, O(1) space)

The most direct solution counts rows in each table and divides them. Use one subquery to count total friend requests and another to count accepted requests. SQL aggregation functions like COUNT() scan the tables once, so the time complexity is O(n), where n is the number of rows across both tables. Wrap the division with ROUND(..., 2) to format the result to two decimal places, and use IFNULL (or COALESCE) to return 0.00 when the denominator is zero. This approach is clean and works well because the problem only asks for a global metric, not per-user statistics.

This technique relies on basic SQL aggregation rather than joins. The database performs two independent table scans and returns a single scalar value. Problems like this commonly appear under Database and SQL practice because they test your ability to combine aggregate functions with conditional handling.

Approach 2: COUNT DISTINCT Pair Aggregation (O(n) time, O(1) space)

Another safe pattern counts unique request pairs from each table using COUNT(DISTINCT ...). In friend_request, count distinct (sender_id, send_to_id). In request_accepted, count distinct (requester_id, accepter_id). This guards against duplicate rows if the dataset contains repeated entries. Divide the accepted pair count by the request pair count and round the result using ROUND. The database still performs linear scans over the tables, giving O(n) time and constant extra memory.

This pattern appears frequently in analytics-style queries where relationships are represented by pairs. Understanding how COUNT(DISTINCT ...) works with composite keys is part of core aggregation query design.

Recommended for interviews: The aggregation approach using COUNT() with ROUND and IFNULL. It shows you understand SQL aggregates, edge-case handling when no rows exist, and how to compute ratios directly inside a query. Interviewers expect a concise one-query solution rather than procedural logic.

Solution

Code

MySQL

Try this approach in the editor →

Detailed Complexity Analysis

Approach	Time	Space	When to Use
Aggregate counts with subqueries	O(n)	O(1)	Best general solution when only total counts are needed
COUNT DISTINCT pair aggregation	O(n)	O(1)	When duplicate request rows may exist and unique pairs must be enforced

Video Solution

FACEBOOK/META LeetCode 597 "Friend Requests I" Interview SQL Question Detailed Explanation • Everyday Data Science • 2,846 views views

Watch 5 more video solutions →

Frequently Asked Questions

Is Friend Requests I: Overall Acceptance Rate easy or hard?

Friend Requests I: Overall Acceptance Rate is categorized as an Easy database problem. It focuses on basic SQL aggregation, ratio calculation, and handling empty result sets.

Friend Requests I: Overall Acceptance Rate Python/Java solution

This problem is designed for SQL rather than Python or Java. On platforms like LeetCode, the expected answer is a MySQL query that computes the acceptance rate using COUNT and ROUND in a single statement.

How to solve Friend Requests I: Overall Acceptance Rate in O(n)?

Use SQL aggregates instead of joins or procedural logic. Count accepted requests from request_accepted and divide by the count of sent requests from friend_request. Apply ROUND(result, 2) for formatting and IFNULL to return 0.00 when the request table is empty. Each COUNT operation performs a linear scan, giving O(n) complexity.

What is the best approach for Friend Requests I: Overall Acceptance Rate?

The standard solution uses SQL aggregation. Count total rows in the friend_request table and divide the number of rows in request_accepted by that value. Wrap the division with ROUND(..., 2) and IFNULL to handle cases where no requests exist. This runs in O(n) time because the database performs simple table scans.

Is Friend Requests I: Overall Acceptance Rate asked at Google/Amazon/Meta?

Database aggregation problems similar to this appear in SQL interview rounds at companies like Amazon, Meta, and Google. The question tests understanding of aggregate functions, handling edge cases, and writing concise analytical queries.

What data structure is used in Friend Requests I: Overall Acceptance Rate?

The problem operates on relational database tables and uses SQL aggregation functions rather than traditional data structures. The key operations involve COUNT, DISTINCT, ROUND, and NULL handling over tabular data.

What is the time complexity of Friend Requests I: Overall Acceptance Rate?

The query runs in O(n) time where n is the total number of rows in the involved tables. Aggregate functions such as COUNT() scan the table once. Space complexity is O(1) because the query only returns a single computed value.

Ready to solve this problem?

Practice Friend Requests I: Overall Acceptance Rate with our built-in code editor and test cases.

Practice on FleetCode

Combine Two Tables

Second Highest Salary

Problem Info

DifficultyEasy

Acceptance41.6%

Approaches1

Reading time4 min

Asked at