Teamwork, Conflict and Difficult People

Nearly every job involves working with other people, and most workplace problems are people problems. Interviewers therefore ask about teamwork and conflict in some form in almost every interview. They are not expecting a story in which everyone agreed. They want to know how you behave when interests, styles or priorities collide: do you listen, stay professional, look for the underlying issue, and move the work forward? This chapter covers the common questions, a method for handling conflict (and for describing it), sample answers, and the traps.

1. What is being assessed

• Collaboration: do you contribute to a shared goal and help others succeed?
• Communication: do you speak up early, listen carefully, and keep people informed?
• Emotional control: do you stay respectful under disagreement?
• Problem solving with people: can you find common ground, or escalate wisely?
• Accountability: do you own your part, and avoid blaming?
• Influence without authority: can you persuade peers?

2. The questions you will hear

• Tell me about a time you worked in a team and what your role was.
• Describe a disagreement with a teammate. How did you resolve it?
• Tell me about a time you disagreed with your manager.
• Describe a time when a teammate was not pulling their weight.
• How do you deal with a difficult colleague or client?
• Tell me about a time you had to work with someone whose style was very different from yours.
• Have you ever had to give someone difficult feedback?
• Tell me about a time you helped a struggling teammate.
• How do you handle team members who do not communicate?

3. A method for resolving conflict (and for telling the story)

1. Pause and understand. Before reacting, make sure you know the other person's actual position and concern. Ask open questions: "Help me understand what worries you about this approach."
2. Separate the person from the problem. Focus on the issue and the goal, not on character.
3. Find the shared goal. Almost always both sides want the project to succeed. Say so.
4. Talk privately first. Raise the issue directly, with the person, before involving others.
5. Generate options. Propose two or three ways forward, and consider a small test or compromise.
6. Use data. Replace opinion versus opinion with a measurable comparison (a prototype, a benchmark, customer feedback, a trial period).
7. Agree the next step and who does what, in writing if needed.
8. Escalate appropriately. If the issue remains, bring in a manager or mentor with a clear, neutral summary: not as tattling, but to get a decision.
9. Repair the relationship. Follow up, acknowledge help, and keep working together.

Describe your story along these steps, because they show a mature process.

4. Sample answers

Disagreement with a teammate (technical or approach)

Question: "Tell me about a disagreement with a teammate."

"In our final-year project, my teammate Arjun wanted to use a NoSQL database, while I thought a relational database was better because our data had clear relationships. We were each convinced, and the discussion was becoming repetitive. I suggested we stop arguing and compare, so we wrote down the five queries the application needed most and spent an evening building each one in both options. It turned out that three of the five were awkward in his approach, but the other two were simpler. We agreed on the relational database and kept one collection in the other system for the activity log, where it was a better fit. The result was a design neither of us had started with, and we both understood why. I learned that when two people are stuck, a small test of the real requirements settles things better than another round of opinions."

It shows listening, data, compromise and a learning.

Disagreement with a manager

Question: "Tell me about a time you disagreed with your manager."

"During my internship, my manager asked me to implement a report as a nightly batch job. I thought a live query would be more useful, because users wanted fresh numbers. I did not argue in the team meeting. I asked for ten minutes afterwards and said I understood the batch approach was simpler to maintain, and showed a small prototype that returned the live figures in under two seconds, and asked what concerns he had. He explained that the database was shared and heavy queries slowed other teams. So I proposed a small cache refreshed every five minutes, which gave nearly live data and protected the database. He approved it. I learned that disagreement goes best when I ask what constraint the other person is protecting, and offer something that respects it."

Key features: private conversation, respect for the decision-maker, evidence, solution that addresses their concern.

Teammate not contributing

Question: "What did you do when a teammate was not pulling their weight?"

"In a four-person course project, one teammate had missed two deadlines for his section, and the rest of us were beginning to take over his work. Instead of complaining to the faculty, I messaged him privately and asked whether something was blocking him. He admitted he was overloaded with an internship and had not understood part of the task. We split his section into smaller pieces, I sat with him for an hour to explain the part he was stuck on, and we set short checkpoints every two days. He delivered the rest on time. I learned that a missed deadline is often a symptom of confusion or overload, so I now start with a question rather than an accusation."

It gives the person a fair chance, then shows action. If the situation had not improved, the next step would be to involve the lead: "If he had still not delivered, I would have raised it with our team lead, with specifics about what was outstanding and the impact on the deadline."

A difficult person

Question: "How do you handle a difficult colleague?"

"I try to find out what makes the person difficult in that context. In one internship project a senior developer was curt in code reviews and I found it discouraging. I asked him to walk me through his comments in person, and learned that he was under pressure from a release and was writing short comments to save time. After that, I made my pull requests smaller and added a note about what to focus on, and he became more constructive. I do not assume bad intent; usually there is a reason, and a direct, friendly conversation helps."

Teamwork success

Question: "Tell me about a time your team achieved something difficult."

"Our robotics club had three weeks to prepare for a regional competition after one of the main members dropped out. Rather than panic, we listed the tasks, rated each by risk, and reassigned them according to who could learn what fastest. I took over the sensor calibration because I had done something similar before, and pair-programmed with a junior for the navigation code. We had two late nights and a failed test run in the second week, but we found a wiring fault and fixed it. We placed third out of twenty-two teams. What I value from it is how clearly we divided the work and checked in each evening for ten minutes."

5. Teamwork vocabulary that rings true

Show the behaviours, not the labels:

• You ask questions to understand before responding.
• You share credit ("Priya's idea about caching made the difference").
• You ask for and give help specifically.
• You flag problems early, before they become emergencies.
• You document and hand over cleanly.
• You disagree and commit: argue the case, then support the decision.
• You adapt your style to others (some want detail, some want a summary).

6. Giving and receiving feedback

Giving difficult feedback: be specific and timely, describe the behaviour and its impact, ask for their view, and agree on a change. Do it privately. "In the last two stand-ups you have not updated the team about your task. I worry that we may be blocked without knowing. Could we agree on a short update each morning?"

Receiving feedback: listen without defending, ask for examples, thank the person, and act. Follow up later to show change.

7. When the other person is the problem

Interviewers sometimes press: "What if you tried everything and the person still would not cooperate?" A reasonable answer:

"I would document specifically what is blocking progress, talk to my lead with facts about the impact and what I had already tried, and ask for help in resolving it. I would try to keep working with the person professionally while the issue is addressed."

Avoid answers that suggest you either give up or go straight to a manager at the first friction.

8. Remote and cross-functional teams

Modern teams are distributed and mixed. Be ready to talk about:

• Writing clear asynchronous updates and documents.
• Clarifying assumptions across time zones and cultures.
• Working with non-engineering colleagues (design, sales, operations) by learning their vocabulary and constraints.
• Keeping people informed proactively when you cannot be reached instantly.

9. Common mistakes

• A story with no conflict at all ("we never disagreed"). It sounds unrealistic or sheltered.
• Making yourself the hero and the other person the villain. Interviewers imagine how you will describe them one day.
• Gossip and blame.
• No specifics: no names (you can change names), no decisions, no result.
• "I told them what to do." Influence is not instruction.
• Avoidance: "I just let it go" for a serious problem.
• Escalating immediately to a manager without first talking to the person.
• Winning the argument but damaging the relationship.

10. Practice questions

1. Describe a time you disagreed with a teammate and how it ended.
2. Tell me about a time you disagreed with a manager or teacher.
3. What did you do when someone on your team was not delivering?
4. Describe the most difficult person you have worked with and how you handled it.
5. Tell me about a time you gave someone constructive feedback.
6. Tell me about a time you helped a teammate succeed.
7. How do you handle a team in which two members are constantly in conflict?