When a Project Manager (PjM) interviewer asks how you would pull a slipping project back on track, or which tasks you would protect if the timeline tightened, they are testing whether you can tell the difference between a delay that matters and one that does not. Most schedule problems are not about the whole plan being late. They are about one specific chain of work being late, while everything else has room to spare. The Critical Path Method is how you find that chain.

The Critical Path Method (CPM) identifies the longest sequence of dependent tasks that determines the minimum possible duration of a project. This is also how the Project Management Institute (PMI) defines it in its PMBOK Guide. Tasks on that sequence have no slack; tasks off it have some. When two chains tie for longest, a project has two critical paths, and both have zero slack. If you cannot name your critical path, you cannot say which slip threatens the deadline and which one is noise, and that distinction is most of what schedule management actually is.

The Core Idea: The Longest Dependent Chain Sets the Date

A project is a network of tasks, some of which depend on others finishing first. You cannot test the integration before it is built. You cannot launch before the security review clears. When you map those dependencies and add up the durations along each possible path through the network, one path is longer than all the others. That is the critical path, and its length is the shortest time the project can possibly take.

The consequence is the thing interviewers care about. A task on the critical path has zero room to slip: if it runs a day late, the whole project runs a day late, because nothing downstream can start until it finishes. A task off the critical path has room, because other work is happening in parallel and will not be finished sooner even if this task waits.

This is why "everything is behind" is almost never true and almost never useful. Usually a few tasks on one chain are behind, and the rest have slack you can borrow from.

Float: The Slack That Tells You What to Ignore

Float, also called slack, is the amount of time a task can slip without pushing out the project's end date. It is the single most practical concept in the method, because it tells you where to spend your attention and where not to.

A task with two weeks of float is not urgent even if it is technically late this week. A task with zero float is on the critical path, and it gets your attention regardless of how small it looks. The discipline is resisting the instinct to chase whatever is loudest and instead chasing whatever has the least float. A noisy stakeholder complaining about a task with ten days of slack is a distraction. A quiet dependency with zero float sliding by a day is the actual emergency.

Interviewers sometimes push one level deeper and ask about the two kinds of float. Total float is how long a task can slip before it delays the project's end date. Free float is how long it can slip before it delays the earliest start of the next task. A task can have plenty of total float and no free float: slipping it will not move the launch, but it will push back whoever depends on it next, which matters when that next task belongs to someone else's schedule.

Float also moves. When a task on a parallel path slips enough, that path can become the new critical path, and work you were ignoring suddenly sets the deadline. Recalculating after every significant change is what separates managing a schedule from just holding a Gantt chart.

Schedule Compression: Crashing and Fast-Tracking

The reason the critical path matters most is that it is the only place compression works. If you want to finish sooner, shortening a task with float does nothing: the deadline is set elsewhere. You can only pull in the date by shortening the critical path itself. There are two ways to do it, and naming both is a strong interview signal.

Crashing means adding resources to critical-path tasks to shorten them: more people, overtime, or outside help. It costs money and it has diminishing returns, because nine people cannot always finish a task nine times faster. Crashing trades cost for time.

Fast-tracking means running critical-path tasks in parallel that were originally planned in sequence, starting the next one before the previous one fully finishes. It usually needs no extra budget, but it adds risk, because you are building on work that is not yet locked, and rework becomes more likely if the earlier task changes. That rework, and the extra coordination, can end up costing more than the time saved. Fast-tracking trades risk for time.

Both operate on the same underlying constraint the Iron Triangle describes: you cannot pull in the date for free, so you name whether cost or risk is going to absorb the change.

Compression also has a ceiling. As you shorten the critical path, a parallel path that was nearly as long becomes the new critical path, and from then on, shortening the original path gains nothing. The worked example below shows it happening.

A Worked Example: Six Tasks, One Compression Request

Here is a small launch plan, the kind an interviewer might sketch on a whiteboard. Durations are in working days, and each task can start only when the tasks it depends on are done.

Task	Days	Depends on	Earliest start → finish	Float
A. Finalize requirements	5	None	day 0 → 5	0
B. Build the integration	15	A	day 5 → 20	0
C. Test the integration	10	B	day 20 → 30	0
D. Security review	22	A	day 5 → 27	3
E. Write user documentation	8	A	day 5 → 13	17
F. Launch	2	C, D, E	day 30 → 32	0

Working forward, each task starts when its slowest predecessor finishes. Launch cannot start until testing finishes on day 30, so the project takes 32 days. Working backward from day 32 gives each task its latest start, and the gap between earliest and latest start is its float. The critical path is A → B → C → F. The security review has 3 days of float, and the documentation has 17.

Now the sponsor asks to launch five days earlier. Crashing the build, adding an engineer to cut it from 15 days to 10, shortens the integration path to 27 days. But the project now finishes on day 29, not 27, because the security review path (5 + 22 + 2 = 29 days) has become the longest. Three days gained, not five, and the security review has quietly become critical. To get the last two days you have to shorten that path too, for example by fast-tracking: starting the security review on the draft requirements two days before they are final. Both paths now take 27 days, so the project has two critical paths, and a slip on either one moves the launch.

That is the shape of answer interviewers want: find the path, name the float, and check what becomes critical after you compress.

How the Critical Path Shows Up in Interview Questions

Interviewers rarely ask "define the critical path." They ask a scenario that rewards reasoning with it.

Typical questions: "A task is running three days late. How do you decide whether it is a problem?" Or "The sponsor wants the launch pulled in by two weeks. Walk me through how you would approach it."

What a strong answer does:

It asks first whether the late task is on the critical path, because a slip with float is not the same as a slip with zero float. For a compression request, it says the date can only move by shortening the critical path, then names the two levers: crashing, which adds resources and spends money, and fast-tracking, which overlaps tasks and adds rework risk. It closes by naming which trade-off it would recommend and why, rather than promising to simply try harder.

What a weak answer does: treats every delay as equally urgent, or promises to "make up the time" without saying which chain of work actually sets the date. That reads as someone who has watched a schedule slip but never diagnosed why.

Common Mistakes

Treating every delay as critical. Without knowing float, you cannot tell an emergency from a non-event. Chasing the loudest task instead of the one with the least float is the most common tell.

Forgetting the path moves. The critical path is not fixed at kickoff. A big enough slip on a parallel path makes it the new critical path. A candidate who never recalculates is managing a snapshot, not a schedule.

Compressing tasks with float. Adding people to a task that is not on the critical path burns budget and moves the date not at all. Compression only works on the critical path.

Ignoring the cost of compression. Crashing spends money and fast-tracking adds risk. An answer that pulls in the date without naming which one it is spending has not actually made a trade-off.

Assuming unlimited people. The method assumes any task can start as soon as its dependencies finish. If two parallel tasks need the same engineer, they cannot actually run in parallel, and the real critical path runs through that person. Check for shared resources before trusting the calculated path. Critical chain project management, introduced by Eliyahu Goldratt in his 1997 book Critical Chain, is built around exactly this constraint.

The Critical Path Method in a Project Manager Interview

The Critical Path Method comes up most often in execution and scheduling scenarios, and it pairs naturally with the RAID log: the RAID log is where a slipping dependency first surfaces, and the critical path is how you decide whether that dependency actually threatens the date or has slack to absorb the slip. Naming the critical path, reasoning from float, and choosing deliberately between crashing and fast-tracking is a strong signal that you manage schedules by structure rather than by anxiety.

For the full interview process this framework fits into, What Is a Project Manager Interview? Complete Overview for First-Timers covers every stage of the loop and what each round tests.

Cala Voice runs you through execution and scheduling scenarios built around exactly this kind of dependency reasoning, so you can practice walking through a critical path and a compression decision out loud before it comes up in a real interview.

Start your preparation →

The Critical Path Method: Scheduling and Dependency Questions in Project Manager Interviews