Project Manager interview questions and answers

A project moves through five process groups: initiating, planning, executing, monitoring and controlling, and closing.

• Initiating: define the business need, write the project charter, find the stakeholders, and get approval to start.
• Planning: define the scope and the WBS, estimate effort and cost, build the schedule, and plan risks, communication, quality and people.
• Executing: build the team, do the work, manage what stakeholders expect, and hold regular meetings.
• Monitoring and controlling: compare progress with the baseline, manage risks and changes, report status, and fix problems.
• Closing: get acceptance, hand over to operations, release the team, write down lessons learned, and archive records.

In software projects these groups overlap. In agile, the cycle repeats every sprint or release.

What they are checking: Do you know a clear project lifecycle, and can you explain what happens in each phase?

A project charter is a short document that formally approves the project. It gives the project manager the right to use resources. The sponsor usually issues it.

Typical contents:

• Project purpose and business case
• Goals and measurable success criteria
• High-level scope and main deliverables
• Major milestones and a rough timeline
• Summary budget
• Key stakeholders, sponsor and project manager
• High-level risks, assumptions and constraints
• Approval signatures

It is short (one to three pages) and stays stable. The project plan is detailed and changes often. Without a charter, the team has no agreed reason for the project.

What they are checking: Can you tell the difference between approval of a project and detailed planning?

The charter approves the project at a high level. The plan describes how the work will be done.

The plan is a set of smaller plans: scope, schedule, cost, quality, resource, communication, risk and procurement. It also has baselines for scope, schedule and cost.

What they are checking: Do you know both documents and why each one exists?

Scope management defines what is in and out of the project. It makes sure only that work gets done.

• Collect requirements and write a clear scope statement with exclusions.
• Break the scope into a work breakdown structure (WBS).
• Get written sign-off on the scope baseline.
• Send every new request through change control. Log it, check the effect on time, cost and quality, and get approval from the sponsor or change board.
• Check deliverables with the customer at acceptance points.

To control scope, compare the actual work with the baseline. Say "yes, with this impact" or "not now". Never quietly accept extra work.

What they are checking: Do you protect scope with a process instead of random yeses?

A WBS breaks the total scope into smaller, easy-to-manage deliverables. It shows what must be produced, not when or by whom.

• Level 1 is the project. Level 2 is the major deliverables or phases. Lower levels break these into work packages.
• Work packages are small enough to estimate, assign and track (often 8 to 80 hours of effort).
• The 100 percent rule: the WBS includes all the work in scope and nothing outside it.
• A WBS dictionary describes each element.

Example for a website: Design, Development (frontend, backend, database), Testing, Deployment, Training. The WBS is used for estimates, schedules and the budget.

What they are checking: Can you break down scope, and do you know why a WBS is used?

Scrum has five events inside the sprint.

• Sprint: a fixed time box (one to four weeks) that contains all the other events.
• Sprint planning: the team picks backlog items and agrees on a sprint goal and a plan.
• Daily scrum: a 15 minute check by the developers. They look at progress toward the goal and adjust the plan for the next 24 hours.
• Sprint review: the team shows the work done to stakeholders and gets feedback to update the backlog.
• Sprint retrospective: the team looks at its own process and agrees on improvements.

Backlog refinement is an ongoing activity, not a formal event. As a PM, I use these events to keep things visible without extra status meetings.

What they are checking: Do you know the events of the framework and why each one exists?

I estimate bottom-up from the WBS and use more than one method. I treat estimates as ranges, not promises.

• Ask the people who will do the work.
• Use analogous estimates from similar past projects for early numbers.
• Use three-point estimation: (optimistic + 4 x most likely + pessimistic) / 6.
• In agile, use story points and relative sizing with planning poker.
• Add contingency for known risks and a management reserve for unknown ones.
• Improve estimates as we learn more (the cone of uncertainty).

I write down the assumptions behind each estimate. I also compare actuals with estimates to make the next ones better.

What they are checking: Do you use clear estimation methods and explain uncertainty?

A risk register is a living list of risks. It also holds the analysis and the response plan for each one.

Each entry usually has:

• ID and description (cause, event, impact)
• Category (technical, resource, external, schedule)
• Probability, impact and a score
• Owner
• Response strategy: avoid, mitigate (reduce), transfer, or accept for threats. Exploit, enhance, or share for opportunities.
• Actions to reduce the risk, a backup plan, and a trigger
• Status

I review it every week with the team. I add new risks and close old ones. A register nobody reads is useless, so the top five risks go into the status report.

What they are checking: Do you manage risk actively instead of listing it once?

I look for risks early, repeat this often, and follow each risk until it is closed.

• Identify: team workshops, lessons from past projects, checklists, assumption checks, and interviews with vendors and stakeholders.
• Analyze: score probability and impact on a matrix. For big projects, use expected monetary value.
• Plan responses: avoid, reduce, transfer or accept. Give each one an owner and a trigger.
• Monitor: review the register in weekly meetings. Watch for new risks and side effects.
• Fund: use a contingency reserve for known risks and a management reserve for unknown ones.

Example: a key integration depends on a third-party API. To reduce the risk, I build a mock early and test it in sprint one. I also note a fallback in the register.

What they are checking: Is your risk process continuous, and does it lead to action?

The critical path is the longest chain of dependent tasks in the schedule. It sets the shortest possible project length.

• Tasks on it have zero float. A delay in any of them delays the end date.
• Tasks off it have float (slack) and can slip a little.
• Use CPM. Build a network diagram. Do a forward pass for early start and finish, then a backward pass for late dates. Float = late start minus early start.

To make a project shorter, you must shorten the critical path. You can crash it (add resources, which costs more). You can also fast-track it (do tasks in parallel, which adds risk). Watch for a second path becoming critical.

What they are checking: Do you understand schedule logic, not just the colors on a Gantt chart?

Earned value compares planned work, finished work and actual spend. It shows schedule and cost performance in one method.

• Planned Value (PV): the budgeted cost of work scheduled so far.
• Earned Value (EV): the budgeted cost of work actually finished.
• Actual Cost (AC): what you really spent for that work.

Every change goes through integrated change control. This way we understand the effect before work starts.

I list everyone who is affected by the project or can affect it. Then I plan how to work with each group.

I make the conflict visible and link it to the project goals. Then the right decision-maker chooses with full information.

A status report gives stakeholders a quick and honest view of the project. I send it weekly to the team and sponsor, and monthly to executives.

I protect the date by talking about scope and priority early. I do not push the team into burnout.

First make things stable and tell people. Find the root cause after that.

The triple constraint is scope, time and cost, with quality in the center. Changing one changes the others.

• Shorter schedule: add cost (more people) or cut scope.
• More scope: more time or more cost.
• Smaller budget: cut scope, or accept a longer schedule or lower quality.

Scope creep is uncontrolled growth of scope after the baseline. Time, cost and resources do not change to match it.

A risk is a possible future event that could affect the goals. An issue is a problem that has already happened.

• Risk: "The vendor may deliver late." It has a probability, and you plan responses.
• Issue: "The vendor delivered late." It is certain, and you must fix it now.

Agile is a way of building software in small steps. The team delivers often, gets feedback often, and adapts to change.

The Agile Manifesto states four values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The items on the right still matter, but the items on the left matter more. Twelve principles back these values. Examples are early and regular delivery, welcoming changing requirements, a steady work pace, and regular reflection.

What they are checking: Whether you know the basics, not just buzzwords

Scrum has three roles (called accountabilities) in one Scrum Team.

• Product Owner: makes the product as valuable as possible. They own and order the product backlog and speak for stakeholders.
• Scrum Master: makes sure Scrum is understood and used. They coach the team, remove impediments (blockers), and help run the events.
• Developers: the people who build a usable increment each sprint. This includes programmers, testers, and designers. They manage themselves and own the sprint backlog.

There is no project manager role or boss inside the team. A Scrum Team usually has ten people or fewer.

What they are checking: Whether you know the Scrum roles exactly

Scrum has five events.

• Sprint: a fixed period of one month or less. All the work happens inside it.
• Sprint planning: the team decides why the sprint is valuable (the goal), what can be done, and how to do it.
• Daily scrum: a 15 minute meeting. The team checks progress toward the sprint goal and adjusts the plan.
• Sprint review: the team shows the result to stakeholders and updates the product backlog.
• Sprint retrospective: the team looks at how it worked and plans improvements for the next sprint.

Each event is a chance to inspect and adapt. This is the core of Scrum.

What they are checking: Whether you can explain each event and its purpose

Scrum has three artifacts. Each one has a commitment.

• Product backlog: an ordered list of everything the product might need. Commitment: the product goal.
• Sprint backlog: the sprint goal, the chosen backlog items, and the plan to deliver them. Commitment: the sprint goal.
• Increment: a usable, joined-up step toward the product goal. Commitment: the definition of done.

Artifacts are transparent, so everyone has the same view of the work.

What they are checking: Whether you know the artifacts and their commitments

Agile is a mindset made of values and principles. Scrum is one specific framework that puts them into practice.

• Agile: a broad idea. Many methods follow it, such as Scrum, Kanban, XP, and Lean.
• Scrum: defines roles, events, artifacts, and fixed-length sprints.

You can be agile without Scrum, for example with Kanban. You can also use Scrum in a mechanical way, with meetings but no teamwork or change. That is not really agile.

What they are checking: Whether you can separate the idea from the framework

A user story is a short description of a feature from the user's point of view: "As a [role], I want [goal] so that [benefit]."

A good story follows INVEST:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

It also has acceptance criteria, often in Given/When/Then form. Example: Given I am logged in, when I click reset, then I receive an email within a minute. The talk around the story matters more than the card.

What they are checking: Whether you can write and judge stories

Story points are a relative unit for the size of work. They combine effort, complexity, and uncertainty. They are not hours.

• Teams use a Fibonacci-like scale (1, 2, 3, 5, 8, 13). They compare each story to reference stories.
• Velocity is the total story points of items fully done in a sprint. Only stories that meet the definition of done count.
• Average the last three to five sprints to forecast how much the team can take.

Velocity is a planning tool for one team. Do not use it to compare teams.

What they are checking: Whether you understand relative estimates and use velocity properly

The definition of done (DoD) is a shared checklist. An item must pass it to count as complete and ready to release. Acceptance criteria belong to one story only.

A story is done only when it meets both. A weak DoD causes hidden work and unusable increments.

What they are checking: Whether you can separate the shared quality bar from one story's needs

Sprint planning starts the sprint. The team decides what to build and how.

• Topic one: why is this sprint valuable? The Product Owner suggests how to add value, and the team agrees on a sprint goal.
• Topic two: what can be done? Developers pick backlog items based on their capacity and recent velocity.
• Topic three: how will the work get done? The team breaks the items into tasks.

Outputs: the sprint goal and the sprint backlog (the chosen items with a plan). The time limit is 8 hours for a one month sprint. It is shorter for shorter sprints.

What they are checking: Whether you can describe the planning flow

Kanban is a flow-based method. It shows work on a board and limits work in progress (WIP). Scrum works in fixed-length iterations.

Kanban suits support and maintenance work, where tasks arrive at random times. Scrum suits product work with planned increments. Scrumban mixes both.

What they are checking: Whether you can choose between them

No. The Scrum Master is a servant leader. They are accountable for how well the team uses Scrum.

Issue types: epic (a large body of work), story, task, bug, and sub-task.

A typical workflow is: To Do, In Progress, In Review (or Code Review), In Testing (QA), Done. Each status is a column on the board. Transitions can have rules. For example, you can require a resolution when an issue moves to Done.

Treat it as learning, not blame. Then make the next sprint better.

Protect the sprint goal, but stay flexible for the business.

They look at different things.

They are different sizes of work.

• Epic: a large body of work that spans several sprints. Example: "online payments".
• User story: a smaller piece of user value that fits in one sprint. Example: "pay by card".
• Task (or sub-task): the technical steps a developer does to finish a story. Example: "build payment API".

A good retrospective is safe, structured, and ends in actions.

Start with the team and the problem, not the trend. A well-structured monolith is the right default for a small team and a new product. Microservices help when separate teams need to deploy and scale parts of the system on their own.

My rule: split only when there is a clear pain. Examples are teams blocking each other on releases, one part with very different scaling needs, or a strict need to isolate faults. Before that, build a modular monolith with clean boundaries. Then a later split is cheap. The common failure is a distributed monolith. It has many services that still deploy and fail together. You pay all the cost and get none of the benefit.

What they are checking: Whether you weigh team and operations cost, not just technical fashion

SQL databases store data in tables with a fixed schema. They support joins and ACID transactions (changes are all-or-nothing), and they scale up easily. NoSQL is a group of stores (document, key-value, wide-column, graph). They have flexible schemas and scale out easily. They often give up strict consistency for availability and speed.

Choose by access pattern:

• Related data, reports, and multi-row transactions (payments, orders): SQL.
• Huge write volume, simple lookups by key, or document shapes that change often (sessions, catalogues, event logs): NoSQL.
• Many teams use both. PostgreSQL holds the main data, and Redis or a document store handles specific jobs.

Do not choose NoSQL only because it sounds scalable. One well-indexed PostgreSQL server handles far more than most products ever need. Giving up joins and transactions has a real cost.

What they are checking: Whether you choose storage from access patterns and consistency needs, not hype

Stateless means each request carries everything the server needs. That includes the identity token, parameters, and body. The server keeps no client session between requests.

Why it matters:

• Any server can handle any request. A load balancer can use simple round robin, and you can add or remove servers freely.
• A crashed server loses no user session.
• Requests are easier to cache, log, and replay.

State does not disappear. It moves. Login usually uses a signed token such as a JWT. Saved data lives in a shared database or cache. If you must keep a session, store it in Redis, not in server memory. The cost is slightly larger requests, because credentials travel with each call.

What they are checking: Whether you connect a REST rule to a practical scaling result