Top 20 Junior Project Manager
Interview Questions, Answered

Waterfall runs a project as a fixed sequence of phases: requirements, design, build, test and release. You agree the requirements up front, and it's hard to change direction once you're under way, so it suits projects where the requirements are clear and unlikely to change. Agile is a family of approaches, such as Scrum and Kanban, that deliver work in small pieces and change course as feedback comes in. In Scrum, for example, the team works in sprints of a month or less. Agile suits projects where the requirements are likely to change or where early feedback is useful. Many organisations use a mix of the two.

Scope sets out what the project will deliver, and what it won't. It's balanced against time and cost: if the scope grows, the schedule or the budget usually has to give. Scope creep is when the scope grows bit by bit without anyone formally agreeing to it. Each addition looks small, but nobody adjusts the timeline or budget to match, so together they push the project late and over budget. To prevent it, write the scope down, use a change request process so every addition is approved with its cost and time known, and get comfortable saying, "Good idea. Let's raise it as a change request and see what it does to the timeline."

A risk register is a list of the things that could go wrong on a project. For each risk it records a description, how likely it is, how much damage it would do, what you'll do about it, and who owns it. The useful part is reviewing it regularly, rather than filling it in once at the start: re-rate each risk, check the planned responses are happening, and raise anything that's getting worse. If a risk actually happens, treat it as an issue and move it to the issue log. On a small project, a short spreadsheet is enough.

Name the ones you've actually used, such as Jira, Trello, Asana, monday.com, Notion, Microsoft Project, Confluence or Excel, and be honest about how well you know each. If you haven't used their tool, say so, and give an example of another tool you picked up quickly. Whichever tool you mention, show that you use it to track tasks, dependencies and progress, and to keep people up to date.

Start with the objective and list the deliverables needed to reach it. Break those into smaller pieces of work (a work breakdown structure) and then into tasks. Estimate each task, note which tasks depend on others, give each one an owner, and build a timeline. A good plan has clear milestones, a known critical path and realistic buffers. The critical path is the longest chain of dependent tasks. It sets the earliest finish date, so a delay to any task on it delays the whole project unless you make up the time. To keep it current, review it every week or so, update progress, raise blockers early and tell stakeholders when things change.

A stakeholder map lists everyone with an interest in the project or influence over it, and places them on a grid by how much influence they have and how interested they are (often called a power/interest grid). It's useful because different stakeholders need different amounts of attention. Manage the high-influence, high-interest people closely. Keep the high-influence, low-interest people satisfied, keep the low-influence, high-interest people informed with regular updates, and keep an eye on everyone else. A senior person who feels ignored can stall a project that is otherwise going well.

RAID stands for Risks, Assumptions, Issues and Dependencies. A RAID log tracks all four in one place for the life of the project. Risks are things that might go wrong. Assumptions are things the plan relies on being true. Issues are problems that have already happened and need sorting out. Dependencies are tasks or deliverables that have to be finished before something else can start. Some teams use the A for actions and the D for decisions, so check which version your team means.

First, find out what's late and why. Check whether the late work is on the critical path. If it isn't, the task may have some slack (float), and a delay shorter than that won't move the end date. Then look at your options: running tasks side by side that were planned one after another (fast-tracking), adding people or money (crashing), or cutting scope. Each has a cost. Fast-tracking adds risk, and new people take time to get up to speed. Tell stakeholders early. Don't hide a delay and hope to catch up quietly. Bring a revised plan with options and your recommendation, and take responsibility rather than blaming the team.

Don't try to please both by splitting the difference. That can leave you with something neither of them wanted. Instead, understand both positions fully before you draw conclusions, and look for the need behind each request. The two may be less opposed than they first sound. Then bring both stakeholders together and work through it, using the project's objectives as the reference point. If they still can't agree, escalate to the project sponsor or steering committee with the trade-offs set out clearly. Write down whatever is decided.

Listen before you act. In your first week or so, read the main project documents: the plan, the RAID log, recent status reports and the stakeholder map. Meet each team member and stakeholder one on one to hear how they see things. Work out the most pressing issues and risks before you suggest any changes. Don't try to fix everything at once. Changes made before you understand the background can cause new problems, and people listen more once they trust you.

Be honest that things are hard. Forced cheerfulness tends to make people trust you less. Keep the team focused on what they can control, mark small wins and milestones, protect them from pressure and politics where you can, and remind them what the project is for. A one-on-one with anyone who seems to have switched off can do more than a pep talk to the whole team.

Start by finding out why. Is it workload, unclear instructions or something personal? If you hear about it early enough, you may be able to remove the blocker or move the deadline. Talk to them directly and privately, and agree a new plan with specific check-ins. As a PM you probably won't be their line manager, so if it keeps happening, raise it with their manager or the project sponsor. Have the conversation before the deadline is missed.

Escalate when the issue is beyond your authority to fix, when it means a real change to scope, cost or timeline, when the decision affects other stakeholders, or when it has stayed unresolved too long despite your efforts. Handle it yourself when it's within your remit, the impact is contained and you can see how to fix it. Don't sit on a problem. By the time you raise it, it may be too late to fix cheaply. When you're unsure, escalate early, and bring the background and a couple of options with you.

Pick one specific example: a uni group project, an event you organised or something from work. Describe the pressure (a tight deadline, fewer people than planned, unclear requirements), what you did to deliver anyway, and how it turned out. Spend most of the answer on how you organised the work, kept people informed and kept things moving. "I worked really hard" doesn't tell them much.

Be honest and pick a real example where things went wrong. Say what happened, how you responded and how it ended. Give the reflection proper time: what you learned, and what you'd do differently. Projects rarely go exactly to plan, so this question is a fair test of how you'd cope in the job.

Describe the competing demands, how you judged which came first (urgency, impact, who was waiting on it), what you decided and what happened. Make it clear you chose the order on purpose and could explain why, rather than reacting to whoever pushed hardest. Mention how you let people know when their work had to wait.

Describe a time you needed someone, such as a peer, a senior colleague or a supplier, to do something and you had no power to make them. Explain how you found out what they cared about, what you appealed to (their interests, a shared goal or the data) and how it turned out. Show that you got there through the relationship and a good argument.

Describe the situation, what the bad news was and how you delivered it. Say the bad news first, then give the background, explain what you're doing about it and offer options where you can. Show that you took responsibility. People generally take bad news better when they hear it early enough to act on it.

Give your own view, and be specific. Qualities worth mentioning: keeping people informed (no surprises), structured thinking (turning a vague goal into a plan), emotional intelligence (reading stakeholders and handling conflict) and staying calm under pressure (making good decisions when things are hard). Then bring it back to yourself: say which of these you think is your strongest, and give a sentence of evidence.

Good questions for PM roles: "What kinds of projects would someone in this role work on in the first six months?" / "Which methodology does the team use, and how strictly?" / "What are the biggest challenges on the team's projects right now?" / "How do project managers work with the technical and product teams here?"