JP Morgan·Software Engineer·Technical Phone Screen·Intermediate

IntermediatePrefer not to say

Apr 2026

Summary

JP Morgan software engineering interview that was basically a live code review session. They handed me some broken code and wanted me to pick it apart across a few specific dimensions, which sounds manageable until you're actually doing it under pressure.

Questions Asked (1)

You are given a code snippet to review. Identify and explain all issues related to improper or missing use of `volatile`, thread-safety problems, Single Responsibility Principle violations, and hardcoded values. Then rewrite the relevant parts to fix them.

Technical Trade-offsSystem DesignRoot Cause Analysis

Author's notes

This was the whole interview, basically.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by systematically scanning the code for each category of issue: volatile misuse, thread-safety, SRP violations, and hardcoded values. For each issue, explain the risk and then propose a concrete fix, prioritizing correctness and maintainability. Conclude by summarizing the refactored code and the trade-offs made.

Pro tip: Demonstrate awareness of the Java Memory Model and concurrency utilities like AtomicInteger, and emphasize that fixing SRP and hardcoded values improves testability and configurability—key for enterprise environments like JP Morgan.

1. Identify volatile and thread-safety issues

Check for shared mutable state without proper synchronization, missing volatile on flags, and non-atomic compound actions. Explain how these can cause visibility and race conditions.

2. Spot SRP violations

Look for classes or methods doing multiple unrelated things, such as mixing business logic with configuration or I/O. Explain how this reduces cohesion and increases coupling.

3. Find hardcoded values

Identify magic numbers, strings, or configuration values embedded in code. Discuss how these hinder flexibility, testing, and deployment across environments.

4. Propose and implement fixes

For each issue, suggest a specific fix: use volatile or atomic classes for thread-safety, extract responsibilities into separate classes, and externalize configuration. Show refactored code snippets.

5. Summarize and discuss trade-offs

Recap the changes and explain any trade-offs, such as increased complexity or performance implications. Highlight how the fixes improve correctness and maintainability.

Key Points to Mention

Java Memory Model: volatile ensures visibility but not atomicity; use synchronized or atomic classes for compound actions.
Thread-safety techniques: immutability, synchronization, concurrent collections, and atomic variables.
Single Responsibility Principle: each class should have one reason to change; separate concerns like logging, configuration, and business logic.
Hardcoded values: externalize to constants, properties files, or dependency injection for configurability and testability.
Testing and maintainability: refactoring improves unit testing and reduces risk of bugs in production.
Real-world impact: in financial systems, concurrency bugs can lead to data corruption or financial loss, so rigorous review is critical.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.