1. Tell me about a time when you disagreed with a teammate's approach to solving a problem. How did you handle it?

During my internship, a teammate wanted to hardcode database credentials in the application configuration file for faster deployment, while I suggested using environment variables for security. I first listened to their reasoning about time constraints, then calmly explained the security risks and showed them how environment variables could be set up in just five minutes. We compromised by implementing the secure approach together, which actually saved time in code review. This taught me that disagreements often come from different priorities, and finding common ground leads to better solutions.

2. Describe a situation where you made a mistake at work and had to tell your manager or team about it.

I once submitted code that passed local testing but broke a critical feature in staging because I didn't account for a specific edge case in the data format. I immediately notified my manager and the team before the issue was discovered, took ownership of the fix, and wrote unit tests to prevent similar failures. I also documented the edge case in the team wiki so others could learn from my mistake. This experience showed me that owning mistakes early and transparently actually builds more trust than hiding them.

3. Give an example of when you had to work with someone who had a very different work style than yours. How did you adapt?

I worked with a teammate who preferred detailed written documentation before coding, while I naturally worked more iteratively with quick feedback loops. Instead of pushing my style, I started sharing brief written summaries of my approach before starting tasks, which gave them the clarity they needed. In return, they became more open to my suggestion to do quick 15-minute check-ins mid-task instead of waiting for final code review. We found a middle ground that leveraged both our strengths and actually reduced misalignment.

4. Tell me about a time when you received critical feedback that you initially disagreed with. How did you respond?

During a code review, a senior engineer suggested my SQL query was inefficient and recommended rewriting it with a different join approach. My first instinct was defensiveness because my version worked correctly, but I paused and asked them to explain the performance implications. After understanding their reasoning around index usage and query execution plans, I rewrote the query their way and saw a 40 percent performance improvement. I thanked them for the feedback and realized that 'working correctly' doesn't mean 'working optimally,' which completely shifted my perspective on technical feedback.

5. Describe a conflict with a teammate over project priorities or deadlines. How did you resolve it?

My teammate and I disagreed on whether to refactor legacy code or build a new feature for an upcoming deadline. I thought the refactor was essential to prevent technical debt, while they wanted to ship the feature on time. We brought our concerns to our tech lead, who helped us see that we could spend two days on targeted refactoring of only the sections affecting the new feature, satisfying both concerns. This taught me that escalating thoughtfully to someone with broader context is better than letting frustration build, and that 'either-or' conflicts often have 'both-and' solutions.

6. Have you ever had to give feedback to someone senior or with more experience than you? Walk me through that conversation.

I noticed our team's senior developer was writing very complex functions that were hard for the rest of us to understand and test. Instead of criticizing directly, I asked if we could schedule a learning session and mentioned that I was struggling to write unit tests for one of their modules. I framed it as my gap, not theirs, and asked if they'd walk me through their thought process. During that conversation, they realized their code was unintentionally difficult to test, and they appreciated the gentle feedback. We worked together to refactor for clarity, and they later thanked me for speaking up respectfully.

7. Tell me about a time when you had limited information to make a decision, and that decision later caused a conflict with your team. How did you handle it?

I made an architectural choice to use a specific library for API integration without consulting the team, assuming it was the fastest path forward. When my teammate started building the authentication layer, they found the library's approach conflicted with our existing patterns, and we had to partially redo work. I immediately apologized for not checking first, acknowledged the impact on their timeline, and we decided together on a better approach. I learned that even with time pressure, a 10-minute conversation prevents hours of rework, and that seeking input is not a sign of weakness but of respect.

8. Describe a situation where you disagreed with how a project was being managed or organized. What did you do?

Our sprint planning was causing confusion because stories weren't clearly broken down into tasks, leading to duplicate work and missed dependencies. Instead of complaining, I suggested we try a structured task-breakdown template during the next planning session and volunteered to help draft it. I showed the team an example of how clearer stories could save time, and they agreed it was worth a one-sprint pilot. The template stuck, and planning meetings became more efficient. This taught me that pointing out process problems is only half the battle; offering a concrete solution makes your concern constructive rather than critical.

9. Give an example of when you and a teammate had different views on code quality standards or technical debt. How did you navigate that?

I wanted to add comprehensive error handling to our API endpoints, while my teammate thought it was over-engineering for a junior project and wanted to move faster. Rather than debating in a vacuum, I suggested we write a few examples side-by-side showing maintainability and user experience with versus without proper error handling. Seeing the concrete difference, my teammate agreed that basic error handling saved future debugging time. We compromised on a practical subset of error cases that mattered most, and both felt heard. It reinforced that showing impact through examples works better than arguing philosophy.

10. Tell me about a time when you felt frustrated or annoyed with a team member. How did you handle it without letting it affect your working relationship?

A teammate frequently missed code review deadlines, which blocked my progress and delayed deployments. Instead of venting to others or sending a frustrated message, I asked them for a one-on-one conversation. I learned they were overwhelmed by other urgent tasks and didn't realize the impact. We worked out a system where review requests included context about urgency, and I offered to help prioritize their workload. The relationship actually strengthened because I addressed the behavior directly and empathetically rather than letting resentment build. It showed me that frustration is often a signal that communication is missing, not that someone is difficult.

11. Describe a time when you had to deliver bad news to your team or stakeholders—whether about a missed deadline, a failed feature, or a problem you discovered.

While testing a feature two days before launch, I discovered a critical bug in the payment processing integration that would require at least a week to fix properly. Rather than hoping it would pass unnoticed, I immediately documented the issue, estimated the fix, and presented options to my manager: delay launch, ship with a workaround and fix later, or reduce scope. I came prepared with impact analysis and recommendations rather than just complaints. The team decided to delay and fix properly, and my manager appreciated the transparency and thoroughness. I learned that delivering bad news with context and solutions is far less damaging than surprises at the last minute.

12. Tell me about a conflict you had that you didn't handle well at the time. What would you do differently now?

Early in my first role, I got defensive when a peer questioned my database schema design in a meeting, and I shut down the conversation by saying 'it works fine.' Later, I realized they had valid concerns about query performance that I'd missed. I didn't follow up, which soured the relationship and we avoided collaborating for weeks. Now I would take a breath, thank them for the feedback, ask what specific concerns they had, and suggest discussing it offline after I'd had time to think. I've learned that defensiveness in the moment costs far more than a few minutes of humility, and that skilled people often disagree because they see different trade-offs, not because one person is right.