Time Speed Distance — Average Speed Trap Delayed ETAs

Time, speed, and distance problems show up everywhere — from Google Maps calculating your arrival time to airline pilots computing fuel burn rates. They're not just textbook puzzles. Any system that involves movement, throughput, or rates is secretly a TSD problem. That's why every major tech company, consulting firm, and bank includes them in their aptitude screening rounds — they test whether you can model a real situation mathematically under time pressure.

The core challenge isn't the formula itself (it's just three words: Distance equals Speed times Time). The real difficulty is knowing which form of the formula to use, how to handle unit mismatches, and how to set up problems that involve multiple moving objects or direction changes without losing track of what's relative to what.

By the end of this article you'll be able to instantly classify any TSD problem into one of five patterns, apply the right formula variant without second-guessing yourself, avoid the three unit-conversion traps that cost candidates marks, and confidently walk an interviewer through your reasoning on the trickiest relative motion scenarios.

Why Average Speed Is a Trap in Time-Speed-Distance Problems

Time-speed-distance problems compute travel time given distance and speed, or derive speed from time and distance. The core mechanic is simple: time = distance / speed. But the trap is averaging speeds over segments. If you drive 60 km at 30 km/h and 60 km at 60 km/h, the average speed is not 45 km/h — it's 40 km/h, because time spent at each speed differs. The harmonic mean governs total time, not the arithmetic mean.

In practice, this means any system that estimates ETA by averaging speeds across legs will be wrong. The correct approach: compute total distance divided by total time. For two equal-distance legs at speeds v1 and v2, average speed = 2 v1 v2 / (v1 + v2). For unequal distances, you must sum distances and sum times separately.

Use this whenever your system predicts arrival times from segment-level speed data — ride-hailing, delivery logistics, fleet management. Getting average speed wrong directly inflates or deflates ETAs, eroding user trust and causing SLA breaches.

The Core Formula: D = S × T and Its Three Forms

The relationship is simple: Distance = Speed × Time. From that you can derive Speed = Distance / Time and Time = Distance / Speed. The trick is picking the right form without second-guessing. Always ask: which variable am I solving for?

Example: A car travels 240 km at 60 km/h. Time = 240 / 60 = 4 hours. If instead you know time and distance, apply the appropriate rearrangement.

In interviews, problems rarely hand you the exact formula you need. They'll give you two quantities and leave the third hidden. Your job is to identify which form to use.

Unit Conversion: The Hidden Trap

You'd be surprised how many candidates lose marks because they use km/h with time in minutes. The rule: convert everything to the same unit system before plugging into the formula.

Example: A train moves at 72 km/h. Express speed in m/s: 72 × (5/18) = 20 m/s.

Common mistake: use 5/18 but apply it the wrong way — multiplying when you should divide. Remember: m/s is a smaller number than km/h, so you multiply by 5/18 to go down.

Relative Speed: When Two Objects Move

When two objects move along the same line, the distance between them changes at their relative speed: - Moving toward each other: relative speed = speed1 + speed2 - Moving in the same direction: relative speed = |speed1 - speed2|

Classic problem: Two trains of lengths 150 m and 200 m move toward each other at 60 km/h and 40 km/h. How long to fully pass each other?

Step 1: Convert speeds to m/s. 60 km/h = 60 × 5/18 = 16.67 m/s. 40 km/h = 11.11 m/s. Step 2: Relative speed = 16.67 + 11.11 = 27.78 m/s. Step 3: Total distance to cover = 150 + 200 = 350 m. Step 4: Time = 350 / 27.78 ≈ 12.6 seconds.

Many forget to add the lengths. Always include both lengths when objects pass each other.

Average Speed: Don't Average Speeds

The most common trap in TSD: taking the arithmetic mean of two speeds to get average speed. That is almost always wrong.

Correct: Average speed = Total distance / Total time.

Example: A car goes 60 km/h for 2 hours, then 40 km/h for 3 hours. Wrong average: (60 + 40)/2 = 50 km/h. Correct: Total distance = (60×2) + (40×3) = 120 + 120 = 240 km. Total time = 2 + 3 = 5 hours. Average speed = 240/5 = 48 km/h.

The harmonic mean (2ab/(a+b)) gives the correct answer only when distances are equal. In this case distances are not equal (120 vs 120? Actually they are equal in this example, 120 each, so harmonic mean would work but that's a special case. Better to stick to total distance / total time.

Boats, Streams, Trains, and Circular Tracks

Real-world TSD extensions test your ability to handle multiple frames of reference.

Boats and Streams: - Downstream speed = boat speed + stream speed - Upstream speed = boat speed - stream speed

Trains passing objects: - Passing a stationary object: distance = train length - Passing a moving object: distance = train length + object length (if moving opposite) or difference (if same direction)

Circular tracks: - Time for two runners to meet when running in same direction = track length / (relative speed) - When running opposite directions = track length / (sum of speeds)

These variations are the bread and butter of interview aptitude rounds. There's nothing new in them — it's still D = S × T with adjusted 'distance' and 'speed' definitions.

Interview Strategy: How to Attack Any TSD Problem in Under 30 Seconds

In aptitude rounds, time pressure is the real test. Here's a repeatable framework:

1. Identify the scenario: single object, two objects (relative speed), average speed, or special case (boats, trains, circular).
2. Write down known variables and their units. Convert all to consistent units immediately.
3. Select the correct formula variant. For relative speed, determine direction.
4. Solve step by step — interviewers want clear reasoning, not fast mental math.
5. Double-check: does the answer make sense? (e.g., time shouldn't be negative, speed should be less than absurd.)

Practice this sequence until it's automatic. Most candidates lose marks not because they don't know the formulas but because they rush and skip unit conversion or misidentify the scenario.

The Catch-Up Problem: When One Object Starts Later

Most juniors screw this up because they treat both objects as independent. They aren't. When a train leaves at 10:00 AM and another leaves at 10:15 AM, the second train has to cover the same distance in less time. The key insight: the distance each travels from the point where the chase starts is identical. Set D₁ = D₂, write the time with a known offset, and solve for the unknown. This pattern appears in all time-speed-distance problems where one object leaves late or has a head start. Don't write two separate equations. Write one: S₁ × T = S₂ × (T - offset). That single equation contains the entire problem.

// io.thecodeforge
public class CatchUpProblem {
    public static void main(String[] args) {
        double speed1 = 60.0; // km/h, leaves at 10:00
        double speed2 = 80.0; // km/h, leaves at 10:15
        double offsetHours = 15.0 / 60.0; // 15 minutes = 0.25 hours
        
        // distance1 = 60 * t, distance2 = 80 * (t - 0.25)
        // set equal: 60t = 80(t - 0.25)
        double t = (speed2 * offsetHours) / (speed2 - speed1);
        double meetingDistance = speed1 * t;
        
        System.out.printf("Meeting time: %.2f hours after 10:00%n", t);
        System.out.printf("Distance from start: %.2f km%n", meetingDistance);
    }
}

The Overtaking Problem: Relative Position, Not Relative Speed

Here's where most production code fails: overtaking problems ask 'how long to close a gap?' not 'when do they meet?' The gap is the distance between two objects at a given moment. If a car is 2 km ahead, and you're faster by 10 km/h, you close that gap at the difference in speeds. Treat the gap as a single distance to be covered at relative speed. Never compute individual times and try to reason about when they align—that's fragile. Use one equation: time = initial gap / (speed₂ - speed₁). Simple. Test it. Ship it.

// io.thecodeforge
public class OvertakingTracker {
    public static void main(String[] args) {
        double speedSlower = 50.0; // km/h
        double speedFaster = 70.0; // km/h
        double initialGapKm = 2.0; // km ahead
        
        double relativeSpeed = speedFaster - speedSlower;
        double hoursToOvertake = initialGapKm / relativeSpeed;
        double minutesToOvertake = hoursToOvertake * 60;
        
        System.out.printf("Time to overtake: %.1f minutes%n", minutesToOvertake);
        System.out.printf("Distance traveled by faster: %.2f km%n", speedFaster * hoursToOvertake);
    }
}

The Meeting Point: Two Objects, One Distance, Two Times

Meeting point problems are the inverse of catch-up. Two objects start at opposite ends and move toward each other. The sum of their distances equals the total path length. Critical insight: time is the same for both when they meet. Write D_total = S₁ × T + S₂ × T. This collapses to T = D_total / (S₁ + S₂). Every meeting problem—trains, runners, cars on a highway—boils down to this. The moment you see 'meet in the middle', think sum of speeds, not subtraction. I've seen four-hour debugging sessions fixed by replacing two separate timers with one addition.

// io.thecodeforge
public class MeetingPointSolver {
    public static void main(String[] args) {
        double speedA = 40.0; // km/h from east
        double speedB = 60.0; // km/h from west
        double totalDistance = 100.0; // km
        
        double timeToMeet = totalDistance / (speedA + speedB);
        double distanceFromEast = speedA * timeToMeet;
        
        System.out.printf("Meeting time: %.2f hours%n", timeToMeet);
        System.out.printf("Distance from east start: %.2f km%n", distanceFromEast);
    }
}