Angle Between Hands of a Clock

📋

Problem

Imagine you want to build a smart clock app that shows the exact angle between the hour and minute hands at any given time.

Given two integers hour and minutes, return the smaller angle (in degrees) formed between the hour and the minute hand on a clock.

1 ≤ hour ≤ 120 ≤ minutes ≤ 59

Edge cases: hour = 12, minutes = 59 → angle close to 5.5 degreeshour = 1, minutes = 0 → angle is 30 degreeshour = 6, minutes = 0 → angle is 180 degrees

</>

IDE

def angleClock(hour: int, minutes: int) -> float:public double angleClock(int hour, int minutes)double angleClock(int hour, int minutes)function angleClock(hour, minutes)

def angleClock(hour: int, minutes: int) -> float:
    # Write your solution here
    pass

class Solution {
    public double angleClock(int hour, int minutes) {
        // Write your solution here
        return 0.0;
    }
}

#include <vector>
using namespace std;

double angleClock(int hour, int minutes) {
    // Write your solution here
    return 0.0;
}

function angleClock(hour, minutes) {
    // Write your solution here
}

Common Bugs to Avoid

Wrong: 90.0Ignoring continuous hour hand movement; hour hand angle computed as hour * 30 only.✅ Add minutes * 0.5 to hour hand angle: hour_angle = (hour % 12) * 30 + minutes * 0.5.

Wrong: 174.5Not normalizing angle difference to smaller angle; returning absolute difference only.✅ Return min(diff, 360 - diff) instead of abs(hour_angle - minute_angle).

Wrong: 30.0Ignoring minutes in hour hand angle near boundary times like 11:59.✅ Include minutes * 0.5 in hour hand angle calculation.

Wrong: Non-zero at 12:00Not using hour % 12 or mishandling zero minutes.✅ Use hour % 12 and compute minute angle as minutes * 6.

Wrong: TLEUsing loops or recursion instead of direct formula.✅ Use direct O(1) formula for angles without iteration.

✓

Test Cases

Consider edge times like 12:59 or 6:00 to test your formula's correctness.

Watch out for common mistakes like ignoring continuous hour hand movement or not normalizing angles.

Think about the time complexity of your solution; it should be constant time.

t1_01basic

Input{"hour":3,"minutes":30}

Expected75

⏱ Performance - must finish in 2000ms

At 3:30, hour hand at 105 degrees, minute hand at 180 degrees, angle difference is 75 degrees.

💡 Calculate hour hand angle as (hour % 12) * 30 + minutes * 0.5.

💡 Calculate minute hand angle as minutes * 6.

💡 Return the minimum of the absolute difference and 360 minus that difference.

Why it failed: Incorrect angle output; likely missed adding minutes * 0.5 to hour hand angle. Fix by computing hour_angle = (hour % 12) * 30 + minutes * 0.5.

✓ Correctly computed the angle using continuous hour hand movement.

t1_02basic

Input{"hour":12,"minutes":0}

Expected0

⏱ Performance - must finish in 2000ms

At 12:00, both hands point at 0 degrees, so angle is 0.

💡 Remember hour hand at 12 is 0 degrees (hour % 12).

💡 Minute hand at 0 minutes is 0 degrees.

💡 Angle difference is zero, so return 0.

Why it failed: Returned non-zero angle at 12:00; likely forgot to mod hour by 12 or mishandled zero minutes. Fix by using hour % 12 and correct minute angle.

✓ Correctly handled zero angle case at 12:00.

t2_01edge

Input{"hour":12,"minutes":59}

Expected5.5

⏱ Performance - must finish in 2000ms

At 12:59, hour hand at 12*30 + 59*0.5 = 359.5 degrees, minute hand at 59*6=354 degrees, angle difference is 5.5 degrees.

💡 Check hour hand angle includes minutes * 0.5 for continuous movement.

💡 Normalize angles within 0-360 degrees.

💡 Return min(diff, 360 - diff) to get smaller angle.

Why it failed: Angle off by large margin; likely ignored continuous hour hand movement or failed normalization. Fix by adding minutes * 0.5 and normalizing difference.

✓ Correctly computed small angle near 0 degrees at boundary time.

t2_02edge

Input{"hour":1,"minutes":0}

Expected30

⏱ Performance - must finish in 2000ms

At 1:00, hour hand at 30 degrees, minute hand at 0 degrees, angle difference is 30 degrees.

💡 Calculate hour hand angle as (hour % 12) * 30.

💡 Minute hand angle is minutes * 6, here zero.

💡 Return absolute difference as smaller angle.

Why it failed: Returned incorrect angle; likely forgot to mod hour by 12 or mishandled zero minutes. Fix by using hour % 12 and correct minute angle.

✓ Correctly handled single hour with zero minutes.

t2_03edge

Input{"hour":6,"minutes":0}

Expected180

⏱ Performance - must finish in 2000ms

At 6:00, hour hand at 180 degrees, minute hand at 0 degrees, angle difference is 180 degrees.

💡 Calculate hour hand angle as (hour % 12) * 30.

💡 Minute hand angle is zero at 0 minutes.

💡 Return min(diff, 360 - diff) to get smaller angle.

Why it failed: Returned angle other than 180; likely failed to compute absolute difference or min with 360 - diff. Fix by returning min(diff, 360 - diff).

✓ Correctly computed straight angle at 6:00.

t3_01corner

Input{"hour":12,"minutes":15}

Expected82.5

⏱ Performance - must finish in 2000ms

At 12:15, hour hand at 0 + 7.5 = 7.5 degrees, minute hand at 90 degrees, angle difference 82.5 degrees.

💡 Check continuous hour hand movement with minutes * 0.5.

💡 Avoid treating hour hand as fixed at hour * 30 only.

💡 Fix by adding minutes * 0.5 to hour hand angle.

Why it failed: Returned 90 degrees instead of 82.5; bug is ignoring continuous hour hand movement. Fix by computing hour_angle = (hour % 12) * 30 + minutes * 0.5.

✓ Correctly handled continuous hour hand movement.

t3_02corner

Input{"hour":3,"minutes":59}

Expected35.5

⏱ Performance - must finish in 2000ms

At 3:59, hour hand at 3*30 + 59*0.5 = 179.5 degrees, minute hand at 354 degrees, angle difference 174.5, smaller angle 35.5 degrees.

💡 Normalize difference by min(diff, 360 - diff).

💡 Avoid returning absolute difference only.

💡 Fix by returning min(diff, 360 - diff).

Why it failed: Returned 174.5 instead of 35.5; bug is missing min(diff, 360 - diff) normalization. Fix by returning min(diff, 360 - diff).

✓ Correctly normalized angle difference to smaller angle.

t3_03corner

Input{"hour":11,"minutes":59}

Expected5.5

⏱ Performance - must finish in 2000ms

At 11:59, hour hand at 359.5 degrees, minute hand at 354 degrees, angle difference 5.5 degrees.

💡 Check hour hand angle includes minutes * 0.5.

💡 Avoid treating hour hand as discrete positions only.

💡 Fix by computing hour_angle = (hour % 12) * 30 + minutes * 0.5.

Why it failed: Returned 30 degrees instead of 5.5; bug is ignoring continuous hour hand movement. Fix by adding minutes * 0.5 to hour hand angle.

✓ Correctly handled continuous hour hand movement near boundary.

t4_01performance

Input{"hour":12,"minutes":59}

Expectednull

⏱ Performance - must finish in 2000ms

Single calculation O(1) must complete instantly even at max constraints.

💡 This problem is O(1) time complexity.

💡 No loops or recursion needed.

💡 Direct formula calculation suffices.

Why it failed: TLE due to unnecessary loops or recursion; fix by using direct O(1) formula without iteration.

✓ Solution runs in constant time as expected.

Practice

1. You need to find the smallest positive number that is divisible by two given integers, and also find the greatest integer that divides both. Which approach guarantees the most efficient and reliable solution for this problem?

easy

A. Use a brute force search checking multiples and divisors until the answer is found.

B. Use a greedy algorithm that picks the largest divisor first and tries to build the LCM.

C. Apply the Euclidean algorithm iteratively to find GCD, then compute LCM using the GCD.

D. Use dynamic programming to store intermediate divisors and multiples for both numbers.

Solution

1. Step 1: Understand the problem requirements

   The problem requires finding the greatest common divisor (GCD) and least common multiple (LCM) of two integers efficiently.

2. Step 2: Evaluate approaches

   Brute force is inefficient for large inputs. Dynamic programming and greedy approaches do not naturally fit this problem. The Euclidean algorithm efficiently computes GCD in O(log(min(a,b))) time, and LCM can be derived from GCD.

3. Final Answer:

   Option C -> Option C

4. Quick Check:

   Euclidean algorithm is the standard optimal method for GCD and LCM [OK]

Hint: Euclidean algorithm efficiently finds GCD and LCM [OK]

Common Mistakes:

• Thinking brute force is efficient enough
• Confusing greedy with Euclidean algorithm

2. Consider the following Python code that checks if a number is happy using a known unhappy cycle set. What is the output when the input is 7?

def isHappy(n: int) -> bool:
    unhappy_cycle = {4, 16, 37, 58, 89, 145, 42, 20}

    def digit_square_sum(num: int) -> int:
        total = 0
        while num > 0:
            digit = num % 10
            total += digit * digit
            num //= 10
        return total

    while n != 1 and n not in unhappy_cycle:
        n = digit_square_sum(n)
    return n == 1

print(isHappy(7))

easy

A. True

B. False

C. The code runs indefinitely (infinite loop)

D. Raises an exception

Solution

1. Step 1: Trace digit_square_sum for input 7

   7 -> 7² = 49; next iteration: 4² + 9² = 16 + 81 = 97; then 9² + 7² = 81 + 49 = 130; then 1² + 3² + 0² = 1 + 9 + 0 = 10; then 1² + 0² = 1 + 0 = 1.

2. Step 2: Check loop termination condition

   Since n reaches 1, the loop exits and returns True.

3. Final Answer:

   Option A -> Option A

4. Quick Check:

   7 is a known happy number and code returns True [OK]

Hint: 7 leads to 1 after sum-of-squares iterations [OK]

Common Mistakes:

• Confusing unhappy cycle detection
• Miscomputing digit squares
• Assuming infinite loop

3. You are given a set of points on a 2D plane and need to find the maximum number of points that lie on the same straight line. Which approach guarantees an optimal solution for this problem?

easy

A. Use a greedy approach by sorting points and connecting consecutive points only.

B. Use a divide-and-conquer approach by splitting points into halves and merging results.

C. Use dynamic programming to build up solutions based on subproblems of smaller point sets.

D. Use a nested loop to consider every pair of points, compute slopes as reduced fractions, and count points sharing the same slope from each base point.

Solution

1. Step 1: Understand problem requirements

   The problem requires finding the maximum number of points on a single line, which depends on slopes between points.

2. Step 2: Identify approach that handles all pairs and slope normalization

   Only the nested loop approach with slope normalization (reduced fractions) correctly groups points on the same line and handles duplicates and vertical lines.

3. Final Answer:

   Option D -> Option D

4. Quick Check:

   Nested loops with slope hashing is the standard optimal approach [OK]

Hint: Check if approach handles all pairs and slope normalization [OK]

Common Mistakes:

• Assuming greedy or DP solves this geometry problem optimally

4. What is the time complexity of the iterative Euclidean algorithm used to compute the GCD of two integers a and b, where a ≥ b > 0?

medium

A. O(min(a, b))

B. O(a + b)

C. O(1)

D. O(log(min(a, b)))

Solution

1. Step 1: Identify the Euclidean algorithm's iteration count

   The Euclidean algorithm reduces the problem size roughly by at least half every two iterations, leading to logarithmic steps in the smaller number.

2. Step 2: Conclude time complexity

   Therefore, the time complexity is O(log(min(a, b))). Linear or constant time complexities are incorrect.

3. Final Answer:

   Option D -> Option D

4. Quick Check:

   Euclidean algorithm runs in logarithmic time relative to smaller input [OK]

Hint: Euclidean algorithm halves problem size quickly [OK]

Common Mistakes:

• Assuming linear time proportional to min(a,b)
• Confusing with brute force complexity

5. Suppose you want to find the nth ugly number but now the problem allows reusing the same ugly number multiple times in the heap without tracking duplicates. Which modification to the algorithm is necessary to maintain correctness and efficiency?

hard

A. Use three pointers to generate multiples in sorted order instead of a heap to avoid duplicates without tracking.

B. Remove the seen set and rely on the heap to naturally order numbers, accepting duplicates.

C. Keep the seen set but reset it periodically to allow reuse of numbers after some iterations.

D. Use a hash map to count occurrences of each ugly number and only push when count is below a threshold.

Solution

1. Step 1: Understand the impact of removing duplicate tracking

   Without a seen set, duplicates flood the heap, causing inefficiency and incorrect nth number.

2. Step 2: Identify alternative approach to avoid duplicates

   The three-pointer method generates ugly numbers in sorted order without duplicates by merging multiples of 2, 3, and 5.

3. Step 3: Conclude the necessary modification

   Switching to the three-pointer approach avoids duplicates inherently, maintaining correctness and efficiency.

4. Final Answer:

   Option A -> Option A

5. Quick Check:

   Three-pointer approach is standard for duplicate-free generation without extra sets [OK]

Hint: Three-pointer method avoids duplicates without extra memory [OK]

Common Mistakes:

• Assuming heap alone can handle duplicates efficiently
• Trying to reset or partially track duplicates incorrectly
• Using counters without clear threshold logic