Member-only story
How a Tough JP Morgan Interview Forced Me to Master Design Patterns
I thought I knew C# until a tough JP Morgan interview exposed my gaps in design patterns. Discover how I turned failure into mastery with real-world examples and expert insights
It was one of those days where the stakes felt unusually high. The email had come in two weeks earlier: an invitation to interview for a senior software engineering position at JP Morgan.
The company name alone carried weight, an unspoken expectation of excellence. I had years of experience in C#, a deep understanding of backend development, and had built scalable systems, but something about this opportunity made me feel an undercurrent of unease.
The first round was smooth. It was an HR discussion followed by a technical screening. The usual questions: experience with C#, system design, handling high-volume transactions, and a few algorithm-based problems. I was confident. But it was the final round — the panel interview — that changed everything.
Three interviewers
One lead architect, a senior engineer, and a hiring manager. The setting was direct and professional and had the intensity that hinted at a rigorous session ahead. After a brief introduction, the architect took the lead.
“Can you walk us through how you design a loosely coupled system?” he asked.
I smiled. This was familiar territory. I discussed dependency injection, inversion of control, how to reduce coupling using interfaces, and how factories can be leveraged for object creation. I even threw in a real-world example from one of my past projects.
He nodded, seemingly satisfied. But then he followed up with something that made my stomach drop.
“Great. Now, can you refactor this piece of code using appropriate design patterns?”
He pasted a block of C# code in the shared document:
public class PaymentProcessor {
public void ProcessPayment(string type) {
if (type == "CreditCard") {
Console.WriteLine("Processing credit card payment");
} else if (type ==…
