Project Manager interview questions for freshers

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?

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?

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.

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.

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.

• Project: a temporary effort with a defined start and end. It creates a unique product or result.
• Program: a group of related projects managed together. This gives benefits you cannot get by managing them one by one. An example is a platform migration with several workstreams.
• Portfolio: a collection of projects and programs chosen and managed to meet strategic goals. They do not need to be related.

Each role owns a different outcome. On small teams the roles overlap.

I build a dashboard so anyone can see project health without asking me.

I compare real progress with the baseline at regular times. I use measures that are not opinions.

I measure success against both delivery and business results.

A project manager owns delivery of the whole project: scope, schedule, budget, risk and stakeholders. A Scrum Master is a servant leader. They help the team follow Scrum, remove impediments (blockers) and improve.

The PMP (Project Management Professional) is the PMI certification that proves project management knowledge. The exam covers three domains: people, process and business environment. It includes predictive, agile and hybrid approaches.

A dependency is a link where one activity relies on another.

Types of logical link:

• Finish-to-start (FS): B starts after A finishes. This is the most common.
• Start-to-start (SS): B starts when A starts.
• Finish-to-finish (FF): B finishes when A finishes.
• Start-to-finish (SF): rare.

The kickoff gets everyone to agree on why the project exists and how it will run. I prepare ahead, then keep the meeting short and focused on decisions.

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.

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 sprint burndown chart shows remaining work (story points or hours) against the days of the sprint. An ideal line goes from the starting total down to zero.

Refinement is ongoing work on the product backlog. The team adds detail, estimates, and order so items are ready for coming sprints.

Planning poker is a way for the team to agree on relative estimates.

A sprint goal is one clear aim for the sprint. It gives the team focus and some flexibility. The team agrees on it in sprint planning. It stays fixed during the sprint, but the backlog items can be renegotiated.

A cross-functional team has all the skills needed to turn backlog items into a usable increment. These include development, testing, design, and operations.

The Scrum Master makes sure the event happens and stays within 15 minutes. The developers run it.

The SM teaches the team to focus on the sprint goal. They note impediments to follow up later. They stop outsiders from turning it into a status report. If the team can run it without the SM, that shows maturity.

MoSCoW sorts requirements into four groups.

• Must have: the release fails without it
• Should have: important but not vital
• Could have: nice to have if time allows
• Won't have (this time): agreed to be out of scope

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

DORA metrics measure how well a team delivers software:

Vertical scaling (scale up) means giving one machine more CPU, memory, or disk. It is simple and needs no code change. But there is a hardware limit, resizing often needs downtime, and you still have one point of failure.

A tech lead owns the technical direction of the team's work. An engineering manager owns the people and the way the team delivers.

I plan the first 90 days before the person arrives.

I give feedback soon after the event, in private. I focus on behaviour and impact, not personality.

A blameless postmortem is a written review of an incident. It looks at how the system and process allowed the failure. It does not look at who made the mistake.

People mostly stay for meaningful work, growth, freedom to decide, fair treatment, and a good manager. Pay matters, but it rarely fixes the others.

A collision happens when two different keys give the same bucket index after hashing. The hash space is limited, so collisions cannot be avoided.

A good review culture finds bugs early, spreads knowledge, and stays respectful.

I treat each new request as a change request and show its impact.

• Thank the client for the idea and ask for the business reason.
• Check it against the signed scope and baseline.
• Estimate the effort, cost and schedule impact with the team.
• Give options: add it with more time or budget, swap it for a lower priority item, or move it to a later phase.
• Get written approval before starting, then update the backlog or plan.
• Stop repeats by agreeing a change process and holding regular demos, so gaps show early.

In agile, the product owner reorders the backlog and the team delivers the most valuable work first.

What they are checking: Whether you control scope without damaging the relationship

I am honest about the miss, find out why, and make changes.

• In the sprint review, show honestly what is done. Unfinished work is not shown as done.
• Talk to the product owner about reordering the leftover items in the backlog.
• In the retrospective, look for causes: taking too much work, unclear stories, dependencies, changes during the sprint, or interruptions.
• Pick one or two actions, for example smaller stories or a time buffer.
• Use the real velocity (work finished per sprint) for the next forecast.
• Tell stakeholders what happened and what is changing.

One miss is just data. I watch the trend.

What they are checking: Whether you turn failure into learning

I find the gap between what the client expected and what we delivered, then close it fast.

I act early, in private, and fairly.

I reduce the uncertainty without stopping the team.

I listen, because the team usually knows the work better.

I focus on finishing the sprint goal with the time left, and I stay honest.

I give the client the visibility they need with little extra work.

I learn the context quickly, build relationships, and create a baseline.

I stay calm, fix the problem, and learn from it.

I create clarity, trust and learning habits.