Loading...
Nail the trickiest behavioral question at JPMorganChase interviews with a STAR-format breakdown, exact phrasing, and real coaching on what interviewers are really testing.
Let's be real ā when an interviewer at JPMorganChase asks, "Describe a time you disagreed with your manager's technical decision," most candidates freeze. Some go too soft: "Oh, I always trust my manager." Others go too hard: "My manager was wrong and I proved it." Both of those answers will quietly end your chances.
Here's the thing most people miss: this question isn't a trap about conflict. It's a signal check. The interviewer wants to see if you have the technical conviction to push back respectfully, the communication skills to make your case with data, and the professional maturity to move forward gracefully ā win or lose.
At a firm like JPMorganChase, where engineering decisions carry real financial risk and regulatory weight, they need engineers who speak up. Silence in a codebase handling billions of dollars in transactions is dangerous.
Let's walk through exactly how to answer this.
Before you craft your answer, understand the signals they're looking for:
A strong answer shows you raised the concern early, framed it technically, presented alternatives, respected the final call, and documented your reasoning.
A weak answer either shows no disagreement ever (not credible), a conflict where you "won" by going around your manager (red flag), or a story where you sulked and disengaged (career-limiting move).
STAR = Situation, Task, Action, Result. You've heard it before. Here's how to apply it specifically to a technical disagreement.
Don't waste time on backstory. Give context that makes the technical disagreement understandable in 2-3 sentences.
"We were redesigning our payment processing service to handle a 10x spike in transaction volume. My manager proposed switching our primary data store from PostgreSQL to a NoSQL solution to improve write throughput."
Notice what's in there: scale, a concrete technical decision, and a clear reason behind that decision. The interviewer now has a real engineering context to evaluate.
What was your responsibility, and what specifically made you uneasy?
"I was the lead engineer on the project and responsible for the migration plan. My concern was that our transaction model required strong ACID guarantees ā something NoSQL databases sacrifice for performance. In financial transactions, eventual consistency isn't acceptable."
This is where you demonstrate technical depth. You're not just saying "I disagreed" ā you're naming the exact engineering tradeoff: ACID compliance vs. write throughput.
This is worth spending the most time on. Walk through exactly how you handled it:
Step 1: Validate your concern before raising it.
Don't go to your manager with a gut feeling. Show that you did your homework.
# Prototype to benchmark write throughput vs. consistency guarantees
# Simulating 10,000 concurrent transactions with rollback requirements
import threading
import time
import psycopg2 # PostgreSQL
from pymongo import MongoClient # MongoDB as NoSQL candidate
def simulate_postgres_transaction(conn, transaction_id):
try:
cursor = conn.cursor()
cursor.execute("BEGIN")
cursor.execute(
"INSERT INTO payments (id, amount, status) VALUES (%s, %s, %s)",
(transaction_id, 100.00, 'pending')
)
# Simulate mid-transaction failure
You ran benchmarks. You built a proof of concept. Now you have data to bring to the conversation, not just an opinion.
Step 2: Request a 1-on-1, not a public challenge.
Never ambush your manager in a group meeting. That puts them on the defensive and makes you look politically tone-deaf. Ask for private time and frame it as seeking input, not delivering a verdict.
"Hey, I've been digging into the NoSQL migration and I have some data I'd love to get your thoughts on. Do you have 30 minutes this week?"
Step 3: Present your case as a tradeoff analysis, not a critique.
This is the nuance that separates good engineers from great ones. You're not saying your manager is wrong. You're saying: here's what we gain, here's what we risk, and I want to make sure we've considered both.
Bring a comparison table. Literally show up with something like this:
| Criteria | PostgreSQL (Current) | MongoDB (Proposed) |
|---|---|---|
| Write Throughput | ~8,000 TPS | ~25,000 TPS |
| ACID Compliance | Full | Partial (session-level) |
| Rollback Guarantee | Atomic | Eventual consistency risk |
| Regulatory Risk (SOX) | Low | Medium-High |
| Migration Complexity | Low | High (schema redesign) |
"I built a small benchmark and pulled our transaction failure rate from last quarter ā we have about 0.3% rollback events. With NoSQL, those partial failures could result in data inconsistencies we'd have to reconcile manually. Given our SOX audit requirements, I wanted to flag this before we committed."
Step 4: Propose an alternative.
Don't just identify a problem ā bring a solution. In this case:
-- Alternative: PostgreSQL with connection pooling + read replicas
-- Achieves horizontal read scaling while preserving ACID writes
-- PgBouncer config for connection pooling (pgbouncer.ini)
-- [databases]
-- payments = host=primary-db port=5432 dbname=payments
--
-- [pgbouncer]
-- pool_mode = transaction
-- max_client_conn = 10000
-- default_pool_size = 200
-- Read replica routing for reporting queries
CREATE EXTENSION IF NOT EXISTS pglogical;
-- Route read-heavy analytics queries to replica
-- Route write/transactional queries to primary
-- This achieves ~20,000 effective TPS without sacrificing ACID"My suggestion would be to explore PostgreSQL with connection pooling via PgBouncer and read replicas for our analytics workload. We get close to the throughput target without touching our transaction guarantees."
Step 5: Accept the outcome and commit fully.
This is the part most candidates forget to mention ā and it's critical for JPMorganChase, which values team alignment strongly.
"My manager heard me out, asked good questions, and ultimately decided to move forward with a hybrid approach ā keeping PostgreSQL for the core transaction service but using MongoDB for non-critical event logging. I disagreed with the full NoSQL migration but fully supported the hybrid decision. I wrote the migration runbook and made sure the team understood where the boundaries were."
"The hybrid system launched successfully. We hit our throughput targets, had zero data consistency incidents in the first six months, and the approach was praised during our SOX audit. More importantly, my manager told me afterward that my raising the concern early saved the team from a much more complex rollback scenario they hadn't fully mapped out."
If you can add a number ā latency improvement, incidents avoided, audit passed ā do it. Numbers signal engineering maturity.
"I can't think of a time I disagreed with my manager." Every engineer has had this moment. It might not have been dramatic ā maybe it was a library choice, a deployment approach, or a testing strategy. Think smaller. The quality of the reflection matters more than the scale of the conflict.
Telling a story where they were clearly right and the manager was clearly wrong. Real technical decisions involve tradeoffs, not heroes and villains. If your story sounds like "my manager wanted to do X and I proved them wrong," reframe it to emphasize the collaborative process.
Forgetting the "commit" part. If you end your answer without describing how you supported the final decision ā even if it wasn't yours ā interviewers at JPMorganChase will wonder whether you're a team player or a passive-aggressive resistor.
Being too vague technically. Saying "my manager wanted to use a different architecture" tells the interviewer nothing. Name the specific technologies, the specific tradeoff, the specific risk. That's what proves you're a senior engineer, not just someone with an opinion.
Badmouthing the manager. Even subtle negativity ā "my manager didn't really understand the implications" ā is a red flag. The interviewer will wonder if you talk about them that way too.
Here's example dialogue you can model and adapt:
Interviewer: "Tell me about a time you disagreed with a technical decision your manager made."
You: "Sure ā I have a good example from my time at [Company]. We were scaling our payment processing service and my manager proposed migrating from PostgreSQL to a NoSQL database to handle the increased write load. I had concerns about ACID compliance given our regulatory requirements, so let me walk you through how I handled it..."
(Walk through STAR as outlined above)
You: "The key for me was making sure I came to that conversation with data, not just instinct. I didn't want to be the engineer who just says 'I don't think this is a good idea' ā I wanted to be the engineer who shows up with benchmarks, a comparison of tradeoffs, and an alternative proposal. And once the decision was made, I was all-in on making it successful."
That closing reflection is gold. It shows self-awareness and maturity.
JPMorganChase interviewers will probe deeper. Here's what they'll ask and how to handle it:
"What would you have done if your manager had rejected your concerns entirely?" ā Talk about escalation paths (skipping level only as a last resort with high-stakes issues), documenting your concern in writing, and still committing professionally to the team's direction.
"How did your relationship with your manager change after this?" ā Ideally it got stronger. Describe how voicing concerns respectfully, with data, builds trust over time.
"What would you do differently?" ā Show growth. Maybe you'd raise it earlier, or involve other stakeholders sooner, or run the benchmark in a more controlled environment.
"Was the final decision the right one?" ā Be honest, but diplomatic. "In hindsight, the hybrid approach worked well. There are things I'd optimize, but the outcome validated the decision."