Project Manager interview questions

Projects are temporary and unique, while operations are continuous and repeatable.

• A project is a temporary effort with a clear start and end, undertaken to create a specific result, like launching a website or moving an office, and it ends once that result is delivered.
• Operations are ongoing, repetitive work that keeps the business running, like payroll or customer support, with no planned end.
• This distinction matters because projects require temporary planning and delivery, while operations require stable, repeatable processes.

A project manager keeps people, plans, and decisions aligned so the agreed result can be delivered.

• A project manager plans the work, coordinates the people doing it, tracks progress, and removes obstacles so the project delivers on time, within budget, and to the agreed scope.
• Day to day that means updating the schedule, running check-ins, chasing blockers, managing risks, and keeping stakeholders informed.
• The core of the job is coordination and communication, not doing the technical work itself.

The triple constraint describes the trade-offs among scope, time, and cost, with quality affected by each choice.

• The triple constraint is the balance between scope, time, and cost, the three competing limits every project juggles, with quality usually sitting in the middle.
• The idea is that changing one affects the others: adding scope pushes out time or cost, and cutting the deadline usually means reducing scope or adding resources.
• A project manager's job is to manage that trade-off consciously rather than pretending you can expand all three at once.

Project scope defines the agreed boundaries of what the project will and will not deliver.

• Scope is the agreed definition of what the project will and will not deliver, the boundaries of the work.
• Defining it matters because it sets shared expectations, gives you a basis to plan the schedule and budget, and provides a reference to judge whether new requests are in or out.
• Without a clear scope, everyone assumes something different and the project drifts.

Scope creep is uncontrolled growth in project work, and a clear change process is the main defense against it.

• Scope creep is the gradual, uncontrolled growth of a project's work as small additions get accepted without adjusting time or budget, until the project is overloaded.
• I prevent it by having a clearly documented scope, running new requests through a change process that weighs their impact, and making the trade-off explicit rather than silently absorbing extras.
• It is not about refusing all changes, but about deciding on them deliberately.

A typical project moves from initiation and planning through execution, control, and formal closure.

• A common lifecycle has initiation, where the project is defined and approved, planning, where you detail scope, schedule, budget, and risks, execution, where the work gets done, and monitoring and controlling, which runs alongside execution to track and adjust.
• Finally there is closing, where you deliver, wrap up, and capture lessons learned.
• These phases give a project structure from idea to completion.

A project charter formally authorizes the project and summarizes what it is meant to achieve.

• A project charter is a short document that formally authorizes the project and gives the project manager the authority to use resources.
• It typically contains the project's purpose and objectives, high-level scope, key stakeholders, a rough timeline and budget, and the main risks or assumptions.
• It is created early and acts as the reference point for what the project is meant to achieve.

A statement of work defines the work and deliverables in enough detail for the parties to agree before starting.

• A statement of work is a document that describes in detail the work to be done, the deliverables, timelines, and often the acceptance criteria, especially when working with a vendor or client.
• It is more detailed than a charter and spells out exactly what will be delivered so both sides agree before work starts.
• It reduces disputes later by making expectations concrete.

A deliverable is an output, while a milestone is a significant point in the schedule.

• A deliverable is a tangible output the project produces, like a report, a design, or a working feature, something you can hand over.
• A milestone is a significant point or checkpoint in the schedule, often marking that a set of deliverables is complete, and it has no duration itself.
• In short, a deliverable is a thing you produce, and a milestone is a marker in time.

A work breakdown structure turns the full project scope into smaller pieces that can be estimated and assigned.

• A work breakdown structure breaks the whole project down into smaller, manageable pieces, from major deliverables down to the individual tasks needed to produce them.
• It helps because it makes sure nothing is forgotten, makes estimating and assigning work easier, and gives a clear picture of the total effort.
• It is usually one of the first planning steps after scope is defined.

Project success criteria are measurable conditions agreed with the sponsor and key stakeholders at the start.

• Success criteria are the specific, measurable conditions that determine whether the project succeeded, such as delivering by a date, staying within budget, and meeting agreed quality or acceptance standards.
• They are defined at the start, together with the sponsor and key stakeholders, so everyone agrees what done and successful mean.
• Setting them early prevents arguments at the end about whether the project delivered.

Projects, programs, and portfolios represent increasing levels of coordinated work and strategic scope.

• A project is a single temporary effort to deliver a specific result.
• A program is a group of related projects managed together to achieve a larger goal that they could not deliver alone, and a portfolio is the whole collection of projects and programs an organization runs, managed to align with strategy.
• These represent increasing levels of scale, from one effort to a group of related efforts and then the full collection.

I would gather requirements by identifying stakeholders, exploring their needs, documenting them, and confirming agreement.

• I would identify the key stakeholders and talk to them to understand what they need and why, using interviews, workshops, or reviewing existing documents.
• I would ask questions to clarify the goal, capture the requirements in writing, and confirm them back to make sure I understood correctly.
• The aim is a clear, agreed list of what the project must deliver before planning the work.

Functional requirements define what a solution does, while non-functional requirements define how well it performs.

• Functional requirements describe what the product or result must do, the specific features or actions, like a user can reset a password.
• Non-functional requirements describe how well it must do it, qualities like performance, security, reliability, or usability.
• Both matter, because a feature that works but is too slow or insecure still fails to meet the real need.

Documented requirements give the team one accessible reference for what must be built and accepted.

• Documenting requirements creates a shared, agreed reference so everyone builds toward the same understanding, and it lets you check the final result against what was asked.
• Undocumented requirements live only in people's heads, get forgotten, and lead to disputes about what was promised.
• I would keep them in a shared, accessible place like Confluence or a requirements document, so the whole team can refer to and update them.

I resolve vague or conflicting requirements through clarification, visible trade-offs, and stakeholder agreement.

• I would not build on a guess; instead, I would ask clarifying questions to turn vague statements into specifics and surface the underlying need behind each request.
• When requirements conflict, I bring the stakeholders together to discuss the trade-offs and align on a decision, rather than quietly picking one side.
• The goal is a clear, agreed set of requirements everyone has signed off on.

I confirm requirements by restating them concretely and asking stakeholders to validate my understanding before work starts.

• I play the requirements back to the stakeholders in my own words, or in writing, and ask them to confirm or correct my understanding before work begins.
• I might use examples, a simple summary, or acceptance criteria to make it concrete, since it is easy to think you agree while picturing different things.
• Confirming early is far cheaper than discovering a misunderstanding after the work is built.

A change request proposes an alteration to an agreed baseline and should be assessed before approval or rejection.

• A change request is a formal proposal to alter something already agreed, like the scope, schedule, or budget, after the plan is set.
• I handle it by assessing its impact on time, cost, and other work, discussing that with the stakeholders, and getting a clear decision to approve or reject before doing anything.
• This keeps changes deliberate and documented instead of quietly derailing the plan.

A reliable schedule combines estimates, dependencies, owners, dates, milestones, and actual team availability.

• I estimate how long each task takes, work out the dependencies between them, meaning which tasks must finish before others start, then sequence them and assign owners and dates.
• I add milestones and account for people's availability, so the schedule is realistic rather than a best-case fantasy.
• The result is a timeline showing what happens when, which I can track against as work proceeds.

I estimate task duration with the people doing the work, historical evidence, and an explicit allowance for uncertainty.

• I would ask the people who will do the work, since they know it best, and look at how long similar tasks took in the past.
• I would account for uncertainty rather than assuming everything goes perfectly, and where useful give a range instead of a single number.
• As a junior I lean on the team's expertise and historical data rather than guessing alone.