IT Project Manager Interview Questions & Answers

Landing an IT Project Manager role means proving you can juggle technical complexity, people management, and business strategy all at once. Hiring managers aren’t just looking for someone who knows Agile from Waterfall—they want to see how you’ve actually handled competing priorities, difficult team members, and projects that went sideways.

This guide breaks down the exact IT project manager interview questions and answers you’re likely to encounter, organized by question type. We’ve included real-world sample answers you can adapt to your own experience, frameworks for thinking through tough scenarios, and strategic questions that will help you evaluate if the role is right for you.

Let’s get you ready to walk into that interview with confidence.

Common IT Project Manager Interview Questions

1. How do you typically initiate a new IT project?

Why they ask: Interviewers want to see if you follow a structured approach and understand how to align technical work with business goals from day one. This reveals your organizational skills and stakeholder awareness.

Sample Answer:

“When I kick off a new project, I start with a needs assessment to make sure we’re solving the right problem. I’ll meet with the business stakeholders to understand what they’re trying to accomplish and what success looks like to them—not just what IT thinks needs to happen.

From there, I work with my team to develop a project charter that outlines scope, objectives, timeline, and resource requirements. I document this in a way that everyone can understand, then I get sign-off from key sponsors before we spend serious time and money.

For example, when my company decided to migrate to a new email system, I conducted interviews with department heads to understand their pain points with the current system. That informed our requirements and helped me secure executive sponsorship because I could speak their language—productivity gains, user adoption rates, things that mattered to them. It also meant we didn’t waste resources building features nobody actually needed.”

Tip for personalizing: Replace the email migration example with a specific project you’ve initiated. Focus on one or two concrete details (like how many stakeholders you interviewed or a specific metric you used to secure funding) rather than vague generalities. Mention a tool you actually used to document the charter.

2. Can you walk me through how you manage project scope?

Why they ask: Scope creep kills projects. Interviewers need to know you have a system for saying “no” professionally and protecting the project from endless changes.

Sample Answer:

“Scope management is about being clear upfront and having a process for change. I start by creating a detailed scope statement with the project team and stakeholders—what’s in, what’s explicitly out, and why. I make sure everyone signs off on this before we move forward.

Once we’re executing, I use a formal change control process. When someone requests a change—and they always do—we evaluate it against three things: impact on timeline, impact on budget, and whether it aligns with the original project goals. If it does all three, we can probably absorb it. If not, we document it for a future phase.

I had a situation where we were building a new internal IT ticketing system. About halfway through, the operations team wanted to add asset tracking to the same system. It was a great idea, but it would’ve added four weeks to our timeline. We couldn’t do that without pushing back our go-live date. So I documented it as a Phase 2 enhancement, got stakeholder agreement on that, and kept the project on track. It actually helped us deliver faster and gave operations time to prioritize what asset tracking features they really needed.”

Tip for personalizing: Use a real example where you either successfully managed scope or learned a hard lesson about scope creep. Mention the specific tool you use for change control (Jira, Azure DevOps, etc.). Numbers help—like “added four weeks” or “prevented three out-of-scope requests.”

3. Describe your experience with Agile/Scrum. How have you used it to manage projects?

Why they ask: Agile is now standard in most IT environments. They want to know if you’ve actually lived it or just read about it. They’re also testing how you adapt your management style to iterative delivery.

Sample Answer:

“I’ve managed projects using Scrum for the past four years, and it’s become my default approach for software development and digital initiatives. I’ve acted as a Scrum Master and also as a project manager overseeing multiple Scrum teams.

What I like about Scrum is the predictability and the early feedback loops. We do two-week sprints, I facilitate daily stand-ups where the team syncs for 15 minutes, and we do sprint planning and retrospectives every other week. The retrospectives are where the magic happens—that’s where the team identifies what’s working and what needs to change.

I managed a project where we were rebuilding our customer portal. We started with the Scrum framework and ran eight two-week sprints. By sprint three, we realized the database architecture wasn’t scaling the way we’d expected, but because we were working iteratively, we caught it early and course-corrected. We also got working software in front of users after sprint four, and their feedback actually shaped what we built in the later sprints. We delivered on time, and user adoption was higher than expected because they’d been part of the process.

That said, I’ve also worked on projects where Scrum didn’t fit—like infrastructure migrations or vendor implementations where you need more predictive planning. I’m flexible about methodology and match it to the project type.”

Tip for personalizing: If you haven’t used Scrum, be honest and talk about what you have used. But if you have, be specific about sprint length, how many teams you’ve managed, and a concrete outcome from using it. Avoid generic statements like “Scrum improved communication.” Instead, explain exactly what changed—like “user adoption was 15% higher than our previous projects.”

4. Tell me about your experience managing project risks. Give me an example.

Why they asks: Risk management separates reactive firefighters from strategic project managers. They want to know if you anticipate problems or just react to them.

Sample Answer:

“I view risk management as an ongoing practice, not something you do once during planning. I create a risk register early in the project and update it regularly.

Here’s a real example: We were implementing a new enterprise resource planning system with a tight deadline. During planning, I identified three high-impact risks. The first was that the vendor might not deliver the customization work on time—critical path item. The second was that our team didn’t have deep ERP experience. The third was that we had dependencies on another department’s data migration.

For the vendor risk, I negotiated penalty clauses into the contract and scheduled early delivery milestones so we’d know if they were slipping before it became a catastrophe. For the skills gap, I brought in a consultant early on to help train the team—yes, it cost money upfront, but it prevented rework later. For the dependency risk, I scheduled regular sync meetings with the other department and made sure their deadline had a built-in buffer.

We executed, and one of those risks actually materialized—the other department’s data wasn’t ready on time. But because we’d planned for it and had a contingency, we’d already compressed our timeline for non-dependent activities and were able to absorb the delay. We still went live on our originally planned date.”

Tip for personalizing: Walk through your actual risk register process—how you identify risks, how you rate them, and what your mitigation strategies look like. Bonus points if you can show a risk you didn’t manage well and what you learned from it. Real credibility comes from owning mistakes.

5. How do you handle a project that’s falling behind schedule?

Why they ask: Everything looks great when projects are on track. They want to see how you problem-solve under pressure and make tough decisions.

Sample Answer:

“First, I get really precise about what’s behind and why. Sometimes a project is delayed on all fronts, but more often it’s specific work streams. I’ll do a root cause analysis—is it a resource issue, a technical blocker, a misestimate, or something else?

Once I know the real problem, I have a few levers I can pull. I can reallocate resources to the critical path. I can re-prioritize and defer nice-to-haves to a later phase. I can work with stakeholders to clarify ambiguous requirements that are slowing us down. In some cases, I’ve negotiated scope reductions or timeline extensions if that’s the right move.

I had a project where we were building a data migration tool, and we were about two weeks behind by the middle of the project. I analyzed where the time was going and realized our estimates for data validation were way too optimistic—the data quality was worse than we expected. I could’ve just pushed harder, but that would’ve led to poor quality. Instead, I met with my sponsor, showed her the data, and we made a conscious decision to extend the timeline by two weeks and allocate more resources to validation. We delivered high-quality work, and the stakeholder appreciated the transparency. That bought us credibility for future projects.”

Tip for personalizing: Avoid the “I worked harder and we caught up” story—everyone’s heard it. Instead, talk about a time when you had to make a hard call. Did you extend the timeline? Reduce scope? Bring in more resources? What was the outcome, and what would you do differently? Show that you think about trade-offs.

6. How do you manage communication with project stakeholders?

Why they ask: Technical execution is half the job. The other half is keeping stakeholders informed, managing expectations, and making sure surprises don’t happen.

Sample Answer:

“I map out all stakeholders early and think about what they actually need to know. An executive sponsor cares about budget and delivery date. A department head cares about how the change will affect their team. A team member wants to know their specific task and deadline. Same project, different communication needs.

I establish a communication plan that’s clear and consistent. For example, on my current project, I send a weekly status report to the core team, a monthly dashboard update to steering committee members showing schedule, budget, and risk status, and I do individual check-ins with key stakeholders every two weeks. I’m really intentional about not over-communicating or under-communicating.

The other thing I do is establish a predictable rhythm. If someone knows they’ll hear from me every Friday at 3 PM, they stop worrying. I’ve found that consistency matters more than frequency. And I make sure bad news travels fast—if we’ve hit a problem, I don’t wait for the next scheduled update. I call the sponsor immediately, explain what happened, what I’m doing about it, and what I need from them.

On a server migration project, we hit an unexpected compatibility issue that was going to cost us a week. I didn’t wait. I called the sponsor that day, walked through the technical issue in terms they’d understand, presented three options with pros and cons, and asked what they wanted to do. They appreciated the speed and transparency, even though the news wasn’t great.”

Tip for personalizing: Mention specific communication tools you use and how often you communicate (weekly status reports, monthly steering committee calls, etc.). Give a concrete example of a time you delivered bad news early and how the stakeholder responded. Show that you think about who needs to know what, not just that you communicate frequently.

7. What project management tools are you proficient in, and how have they helped you?

Why they ask: This isn’t about which tool you use—it’s about whether you’re intentional about tool selection and whether you actually use tools to manage, not just for administrative overhead.

Sample Answer:

“I’m proficient in Jira, Microsoft Project, and Azure DevOps. I choose the tool based on the project type. For Agile projects, I use Jira or Azure DevOps because they’re built for iterative work—backlog management, sprint planning, burndown charts. For waterfall or hybrid projects, I often use Microsoft Project for the Gantt chart and critical path analysis.

What matters to me isn’t the tool itself—it’s that the tool gives me visibility and keeps the team aligned. With Jira, I can see in real time which tasks are blocked, what the team is working on, and whether we’re trending toward our sprint goal. I can pull a burndown chart in five seconds and see if we’re on pace. That real-time visibility lets me catch problems early instead of discovering them in a status meeting.

I’ve also used these tools to create dashboards for stakeholders—not detailed task-level stuff, but high-level indicators: Are we on schedule? Are we within budget? What are the top risks? I’ve had stakeholders tell me these dashboards reduced their anxiety because they could see the project status themselves instead of waiting for my weekly email.

One thing I don’t do is let the tool become the tail wagging the dog. I’ve seen teams spend more time updating Jira than actually doing work. I’m disciplined about what data I track and why—it’s always because we need that information to make decisions.”

Tip for personalizing: List the tools you actually use. If you don’t have experience with the tools mentioned in the job description, say so—then talk about how you’d quickly learn them. Mention a specific way a tool helped you (like “I caught a schedule slip three weeks early because of the burndown chart” rather than “the tool helps with visibility”). Show that you’re tool-agnostic and thoughtful about their use.

8. Describe a time when you had to adapt your project plan due to unexpected changes.

Why they ask: IT projects almost always hit surprises. They want to see if you’re rigid and get frustrated by change, or if you’re adaptive and treat change as normal.

Sample Answer:

“We were in the middle of upgrading our network infrastructure when a critical vulnerability was discovered in the current system. It wasn’t related to our upgrade, but it had to be patched immediately or we’d be exposed to attacks. This meant our network team had to divert some of their attention away from the upgrade project to handle the security emergency.

I had two choices: push back the upgrade timeline or figure out how to continue with reduced resources. I ran the numbers—the upgrade had some parallel work streams that didn’t require network team expertise, and some dependencies that did. I worked with the team to reorganize the schedule so that the parallel work continued, and we delayed the dependent work by three weeks while the security incident was resolved.

I also used it as an opportunity to build in buffer time we probably should’ve had anyway. We adjusted our timeline, communicated the new dates to stakeholders, and honestly, delivering three weeks later was fine because the security fix was a higher priority. The key was that we were intentional about the change, not reactive. We made a decision, communicated it, and adjusted once.”

Tip for personalizing: Talk about a change that wasn’t in your control—a business priority shift, a vendor problem, a team member leaving, whatever. Show how you worked with the change instead of resisting it. End with what you learned or how it made you a better project manager.

9. How do you measure project success?

Why they asks: This tells you whether someone is focused on “done on time, on budget” or whether they think about actual business value and outcomes.

Sample Answer:

“I measure success across three dimensions: execution metrics, business metrics, and team health.

Execution metrics are the basics: Did we deliver on time? Did we stay within budget? What was our quality like—how many defects, how much rework? If we’re shipping broken software, we’re not successful, even if we hit the timeline.

But execution isn’t everything. A project could be on time and on budget and still be a failure if it doesn’t solve the business problem. So I also measure business outcomes: Is the software being adopted? Is it solving the pain point we set out to solve? For a customer-facing project, I might track adoption rates. For an internal tool, I might track user satisfaction or time savings. I want to know if the project actually mattered.

Finally, I think about team health. Did we burn people out? Did team members learn something? Would they want to work on projects with me again? If a project is successful on paper but the team is destroyed, that’s not sustainable. And ironically, teams that have good morale tend to execute better on the next project.

On our last project, we delivered on time and under budget—great. But what I’m most proud of is that user adoption of the new system reached 95% within the first month, and on the post-project survey, the team said it was one of the best-run projects they’d been on. That’s success.”

Tip for personalizing: Pick a real project and talk about what success actually looked like. Name specific metrics if you can (95% adoption, $200K under budget, 30-day payback period). Show that you think beyond the delivery date.

10. How do you approach managing a team with mixed technical skills and experience levels?

Why they asks: Most IT teams aren’t homogeneous. They want to know if you can get the best out of people regardless of where they’re starting from.

Sample Answer:

“I assess where people are early—what they know, what they want to learn, where they’re strongest. Then I try to put them in positions to succeed and grow. I pair less experienced people with senior team members on critical work, and I give more experienced people opportunities to lead.

On my last infrastructure project, I had a mix of very senior network architects and some junior engineers who were fairly new to enterprise environments. I could’ve just had the senior people do all the complex work, but that doesn’t scale and the junior people don’t grow. Instead, I worked with the architects to identify what work could be scaffolded—where a junior person could do 80% of the work with an architect reviewing and guiding them. This slowed things down slightly, but we built capability for the future.

I also make it clear what I expect from people at different levels. A senior person needs to own a complex piece of the project and make decisions. A junior person needs to learn the systems and ask questions. A mid-level person needs to start leading some aspects. When people know the expectations, they can step into the role.

The other thing I do is create psychological safety so people will surface problems early. If a junior engineer is stuck and stays stuck because they’re afraid to ask, that’s on me. I want them to say ‘I’m blocked’ within two hours, not two weeks.”

Tip for personalizing: Talk about a specific mix of skill levels and what you did to manage them. Show that you think about development, not just extraction of labor. Mention something concrete like “pairing senior and junior team members” or “having clear role expectations.”

11. Tell me about a time you had to negotiate with stakeholders or vendors to reach a compromise.

Why they ask: IT Project Managers live in the tension between what stakeholders want and what’s realistic. They want to see if you’re a diplomat or a doormat.

Sample Answer:

“We were implementing a CRM system with a vendor who was contracted to do some customizations. About halfway through, it became clear that one of the requested customizations wasn’t going to be possible with the platform’s architecture—it would’ve required rebuilding core functionality. The business stakeholder needed that feature, but the vendor was saying it wasn’t feasible.

I brought all parties together—the business stakeholder, the vendor, and our technical team. I made sure we all understood the constraint clearly: the architecture didn’t support it. Then I worked through alternatives. Could we achieve the same business outcome a different way? Could we use a third-party tool that integrated with the CRM? Could we automate the workaround outside the system?

We ended up with a hybrid approach where we used an integration tool to achieve 95% of what they originally wanted, and it actually ended up being more flexible for future changes. It took some difficult conversations, but we avoided months of wasted customization work, and the stakeholder got a solution that actually worked better than their original request.

The key was framing it as ‘what problem are we trying to solve’ instead of ‘what feature do you want.’ Once we were all looking at the same problem, we could think creatively about solutions.”

Tip for personalizing: Pick a real negotiation where you didn’t just give people what they asked for, and you didn’t just say no. Show the conversation skills: you listened, you understood the constraint, and you worked toward a solution that satisfied the underlying need. Avoid making yourself sound like a superhero—show the messy process of actually getting people to agree.

12. How do you stay current with IT trends and technologies?

Why they ask: Technology changes fast. They want to know if you’re passive and waiting for the world to change, or if you’re actively learning and growing.

Sample Answer:

“I think staying current is part of the job at this point. I read industry publications—I get emails from TechCrunch and follow some project management blogs. I listen to podcasts during my commute. I have a few people I follow on LinkedIn who post thoughtful takes on IT trends.

But more than reading, I try to stay involved in the actual work. I don’t hide in a project management office—I work with the technical teams. I understand what they’re dealing with. If they’re experimenting with Kubernetes, I want to understand what problem it’s solving and why it matters to our projects.

I also carve out time for professional development. I’ve done a few online courses—I did a PM certification a few years ago, and more recently I’ve been taking courses on emerging technologies relevant to my company’s future, even if we’re not using them yet. It helps me have informed conversations about where we should be heading.

And honestly, a lot of what I learn comes from conversations with peers. I’m part of a PM community—we meet quarterly, we have a Slack channel where we share war stories and solutions. If someone’s dealing with a problem I haven’t seen, I learn from that.”

Tip for personalizing: Mention specific sources you actually use (publications, podcasts, communities, courses). Pick one or two things you’re currently learning about and what’s driving your interest. Show that you’re deliberately investing time, not just passively hoping information finds you.

13. Can you give an example of a project that didn’t go as planned? What did you learn?

Why they ask: Everyone fails sometimes. This question is really asking: are you self-aware? Do you learn? Or do you make excuses?

Sample Answer:

“I managed a data center migration that was a learning experience, let’s say. We’d planned for six months, and we were two months in when we realized that the data quality issues were much worse than we’d anticipated. We discovered legacy systems with data inconsistencies that nobody had documented, and we had to do way more data cleansing than we’d budgeted for.

I made some mistakes. I didn’t dig deep enough into the data during the planning phase—I took the stakeholders’ word that the data was in reasonably good shape. And when we discovered the issues, I was initially defensive about the timeline instead of being proactive about solutions.

What I learned: one, always do your own assessment, especially with something as critical as data. Two, when you discover a problem, don’t waste energy defending the old plan—focus on the new reality and options. Three, communicate early with stakeholders. I waited too long to tell them we were in trouble, which hurt my credibility. If I’d been more transparent earlier, we could’ve made different decisions about scope or timeline.

We ultimately fixed the problem, but we went seven weeks over timeline. We delivered a solid migration. But I’m much more rigorous now about assessing data health early, and I’ve made transparency a priority even when the news is bad.”

Tip for personalizing: Pick a real failure. Be specific about what went wrong and what you actually did about it. Take responsibility—don’t blame the stakeholder or the business or the vendor. End with what you genuinely learned and how you changed your practice. This is one of the most credible answers you can give because it shows self-awareness.

14. How would you handle a conflict between team members or between departments?

Why they ask: Projects require cross-functional collaboration. They want to see if you can handle tension maturely or if you avoid conflict.

Sample Answer:

“I’ve learned that conflicts usually aren’t personal—they’re about misaligned incentives or unclear expectations. My first move is to understand what’s actually driving the conflict from each person’s perspective.

I had a situation where our database team and the application development team were clashing over performance requirements. The database team wanted strict performance standards that would’ve constrained the app design. The app team thought the database team was being overly rigid. They were both right from their perspective, but they weren’t talking about the tradeoffs.

I brought them together in a room and had each side explain their concerns. Then I asked clarifying questions: What’s the real performance risk? What’s the business impact if we don’t meet those standards? What are the design tradeoffs? Once both teams understood the actual constraints and tradeoffs, they found a middle ground pretty quickly. They weren’t being stubborn—they just didn’t have the full picture.

If there’s ongoing conflict or if someone’s behavior is affecting the project, I address it directly but privately. I’m clear about what behavior I need to see and what the impact is if it continues. I stay respectful and I don’t take sides, but I’m not ambiguous about what’s acceptable on my team.”

Tip for personalizing: Talk about a real conflict you’ve seen or handled. Show that you understand the human dynamics—people usually aren’t trying to be difficult, they’re operating from incomplete information or misaligned incentives. Demonstrate that you can address conflict without it becoming personal or nasty.

15. What would you do in your first 30 days in this role?

Why they ask: This is forward-looking and reveals how you think about taking on a new position. Do you jump in and start directing, or do you first understand the landscape?

Sample Answer:

“First 30 days, I’m in learning mode. I’d want to understand the current state of projects, the team, and the organizational dynamics. I’d schedule one-on-ones with the key team members and stakeholders to understand what’s working, what’s painful, and what they think needs to change. I’d want to understand the company’s project management maturity—do you have established methodologies? What’s working? What’s not?

I’d review the active projects—their status, their methodologies, whether there are patterns in what’s working and what’s not. I’d look at historical project data if it’s available. Did projects tend to slip? Where? Why? This gives me insight into systemic issues versus one-off problems.

I’d also spend time understanding the tech landscape—what technologies are we using, what are the strategic plans for the next couple of years, what’s the relationship like with key vendors or partners.

By the end of 30 days, I’d have a perspective on where we stand and where I think we could improve. I’d probably have a couple of recommendations, but I’d approach the first 90 days as building relationships and understanding before making big changes. I think new leaders who come in and overhaul everything immediately often miss context that matters. That said, I’m not waiting a year to make improvements either—I just want to make them thoughtfully.”

Tip for personalizing: Show that you’re thoughtful about onboarding yourself. Mention specific things you’d want to understand—project portfolio, team composition, pain points. Show that you’ll listen before you prescribe. Avoid making it sound like you already know what needs to change—you’re a new person, you need to learn the landscape first.

Behavioral Interview Questions for IT Project Managers

Behavioral questions ask about your past behavior to predict your future behavior. The STAR method is your friend here: describe the Situation, what Task you were responsible for, what Action you took, and what Result you got. These questions test your soft skills—leadership, communication, resilience, and how you handle adversity.

Tell me about a time you had to lead a team through a major change or transition.

Why they ask: Change management is critical in IT. They want to see if you can help people move from resistance to adoption.

STAR framework:

• Situation: What was the change? Why was it happening? What was the team’s initial reaction?
• Task: What was your specific responsibility in leading the team through this?
• Action: How did you communicate the change? How did you address concerns? What did you do to help people transition?
• Result: How did the team respond? Did adoption happen? Did people come around?

Sample Answer:

“We were migrating from an on-premise email system to Office 365, and the team was nervous—they’d been on the same system for 10 years. There was a lot of ‘why are we changing something that works?’ I knew that if I just told them to switch, adoption would be slow and we’d get a lot of support tickets.

I started by explaining the ‘why’—not the IT reasons, but the business reasons. They’d get mobile access, better collaboration, disaster recovery, and new security features. I addressed specific concerns: no, you won’t lose your emails. No, we’re not deleting your archive. Yes, there’s training.

I ran hands-on training sessions grouped by role—not everyone needs to learn the same things. I set up a dedicated support channel for the first month and staffed it heavily. I also identified early adopters and empowered them to be peer leaders. They helped answer questions and calmed people’s fears.

It wasn’t perfect—we had some hiccups. But adoption reached 90% on the first day and 99% within two weeks. People felt listened to and supported instead of just told what to do.”

Tip for personalizing: Talk about the emotions and resistance you encountered, not just the logistics. Show that you understand that change is about people, not just technology. Mention something concrete you did to smooth the transition—whether that’s training, communication, or identifying peer leaders.

Describe a time when you had to make a difficult decision without having all the information you needed.

Why they ask: Projects run on incomplete information. They want to see if you can make informed judgments with ambiguity, not just follow a predetermined plan.

STAR framework:

• Situation: What was the decision? Why was time-critical? What information were you missing?
• Task: Why was it your decision to make?
• Action: How did you gather what information you could? How did you weigh the options? How did you make the call?
• Result: What was the outcome? Would you make the same decision again?

Sample Answer:

“We were implementing a new backup solution for our data centers, and we had a window to cut over during a scheduled maintenance window. Two days before the cutover, one of our vendors flagged a potential compatibility issue with our database system that we hadn’t tested. We could delay the cutover and spend a week testing, or we could proceed with the plan and hope it wasn’t an issue.

I gathered what information I could quickly—I talked to the vendor about the likelihood and severity of the issue, I talked to our DBA, and I ran a limited test in our dev environment. The test passed, and the vendor said it was a low-probability issue. But I couldn’t be 100% certain without full testing.

I had to decide: risk the cutover or miss the window and stay on a vulnerable backup system that was getting less vendor support. I presented the analysis to my sponsor—here’s the risk level, here’s what we know, here’s what we don’t. Here are the implications of each decision.

We decided to proceed with some contingencies: we had extra engineering on standby, we had a plan to roll back if needed, and we monitored closely the first 48 hours. The cutover went smoothly. But honestly, if I’d had the information that showed significant risk, I would’ve delayed. The point is, I made the best decision I could with what I had, I involved the right people, and I had a plan if things went wrong.”

Tip for personalizing: Be honest about decisions that didn’t work out too. Talk about a time your call went south and what you’d do differently. Show that you can live with ambiguity without being paralyzed by it.

Tell me about a time you received critical feedback. How did you respond?

Why they ask: This tests ego and growth mindset. Do you get defensive or do you learn?

STAR framework:

• Situation: What was the feedback? Who gave it to you? What was the context?
• Task: How did you initially feel? What was at stake?
• Action: How did you process it? What changes did you make?
• Result: How did things improve? What did you learn about yourself?

Sample Answer:

“A few years ago, I was managing an infrastructure project and a senior technical leader pulled me aside and said, ‘You’re making decisions without enough input from the engineers. You’re managing around them instead of with them.’ I was defensive at first—I thought I was being efficient, making calls quickly so we could keep moving.

But he was right. I was so focused on timelines and deliverables that I wasn’t leveraging the expertise I had in the room. I was also creating a dynamic where the team felt directed rather than engaged.

I took that feedback seriously. I changed my approach. I started asking ‘what am I missing?’ before I made decisions. I facilitated more conversations instead of just deciding and announcing. I involved engineers in problem-solving instead of just telling them what needed to happen.

It made me a better project manager. The team was more engaged, we made better decisions because I had more information, and honestly, projects went smoother. My last two projects, the team rated me significantly higher on collaboration and inclusion than I would’ve rated a few years before. It was hard feedback, but it was exactly what I needed to hear.”

Tip for personalizing: Pick feedback that was actually difficult to hear, not something trivial. Show that you initially had a human reaction (defensiveness, disappointment) but that you worked through it. End with a concrete way your practice changed.

Tell me about a time when you had to influence someone who didn’t report to you.

Why they ask: IT projects require influence without authority. They want to see if you can navigate matrix organizations and build consensus.

STAR framework:

• Situation: What did you need this person or group to do? Why didn’t they have to do it? What was their resistance?
• Task: What was your goal? What constraints did you have?
• Action: How did you approach them? What was your strategy to build alignment?
• Result: Did they come around? What was the outcome?

Sample Answer:

“We needed another team’s infrastructure resources for a project, and that team’s leadership wasn’t prioritizing our work—they had their own projects. I couldn’t just tell them what to do; they didn’t report to me, and their work was legitimately important.

I started by understanding their constraints. I met with their leader and asked about their timeline and what was driving their priorities. I listened more than I talked. Then I made the case for why our project mattered to them: it would reduce their operational burden, it would give them visibility into something they’d been struggling with, it would free up resources they needed later.

I also didn’t ask for all their resources all the time. I asked for what we needed, when we needed it, in a way that they could flex their schedule. That showed I understood their constraints and wasn’t just trying to hijack their team.

It took a couple of conversations, but they came around. We got the resources we needed, and we built a good working relationship. More importantly, I framed it as a partnership—I needed their help, and here’s why it matters to