How to Use a RAID Log to Answer PjM Interview Questions
The RAID log is the Project Manager's core tool for surfacing risk before it becomes a crisis. Here is what each of the four letters means, how the log actually gets used, and how to reach for it in an interview answer.
By The Cala Voice Team ·When a Project Manager (PjM) interviewer asks how you would build a risk log or track dependencies across teams, they are testing one thing: do you have a repeatable system for surfacing problems before they land, or do you improvise? Candidates who answer with a vague "I keep an eye on risks" signal the second. Candidates who reach for a RAID log signal the first.
RAID stands for Risks, Assumptions, Issues, and Dependencies. It is a single living document that tracks the four categories of thing most likely to derail a project, each with an owner and a next action. It does not predict the future. It makes sure nothing important is being watched by nobody.
The Four Categories
Risks
Risks are potential future problems that have not happened yet. Each one is logged with a likelihood, an impact, a mitigation plan, and an owner. The discipline is not listing every conceivable thing that could go wrong, but ranking the few that genuinely threaten the project and deciding, in advance, what you would do about each.
Assumptions
Assumptions are the things you are treating as true in order to plan, but have not verified. "The vendor will deliver the integration by week six." "The second team has capacity in the fall." Assumptions matter because an unvalidated assumption is a risk in disguise: if it turns out false, it becomes a live problem. Logging them makes them visible so they can be checked rather than silently relied on.
Issues
Issues are problems that have already materialized. The distinction from a risk is the single most useful idea in the framework: a risk might happen, an issue has happened. An issue needs an owner and a resolution path now, not a mitigation plan for later. Conflating the two is a common tell that a candidate has not actually run a project under pressure.
Dependencies
Dependencies are the things your project needs from someone else, or that someone else needs from you, in order to proceed. On a cross-team project these are where delivery most often stalls, because a blocked dependency in one team can quietly halt work in another. Logging them with owners and dates is how you catch a slip before it cascades.
How a RAID Log Actually Gets Used
The value of a RAID log is not the document, it is the cadence around it. A log that gets written once at kickoff and never opened again is theater. A useful one is reviewed on a regular rhythm, weekly on most projects, where each open item is checked: has this risk changed likelihood, has this assumption been validated, is this issue resolved, has this dependency slipped. Every item has a named owner, because a risk that belongs to everyone belongs to no one.
The best answer to a risk question in an interview describes this living process, not just the four categories. Anyone can recite the acronym. Describing how you run the review, assign owners, and escalate a dependency that is about to slip is what signals real experience.
How the RAID Log Shows Up in Interview Questions
Interviewers rarely ask "what is a RAID log" directly. They ask a scenario that rewards using one.
Typical questions: "Walk me through how you would build a risk log for a project you are starting today." Or "How do you track dependencies across teams that do not report to you?"
What a strong answer does:
It reaches for the RAID structure explicitly, separates risks (might happen, tracked with likelihood and impact) from issues (already happened, need resolution now), calls out that assumptions convert to risks if left unvalidated, and treats cross-team dependencies as the highest-attention category. Then it describes the review cadence and the fact that every item has an owner.
What a weak answer does: lists categories of things to watch without a system for reviewing them, or blurs risks and issues together, which reads as someone who has kept a task list but never run structured risk management.
Common Mistakes
Confusing risks and issues. A risk is potential, an issue is active. Managing them the same way means either panicking about hypotheticals or ignoring live problems.
Treating the log as a document, not a process. The acronym is trivial. The cadence and ownership are the skill.
Ignoring assumptions. Unlogged assumptions are the quiet source of most project surprises. Naming them is half the value of the framework.
Dependencies without owners or dates. A dependency you are tracking but not actively chasing is a slip waiting to happen.
RAID in a Project Manager Interview
The RAID log comes up most often in execution and risk questions, and it pairs naturally with the Iron Triangle: the RAID log is how you spot the threat, and the Iron Triangle is how you reason about the trade-off once a risk forces scope, time, or cost to move. Naming both, and the review cadence that keeps the log alive, is a strong signal that you run delivery by system rather than by instinct.
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 risk scenarios built around exactly this kind of structured risk management, so you can practice walking through a RAID log out loud before it comes up in a real interview.