HackTheRounds Interview Experiences

JPMorgan Software Engineer OA Interview Experience (2026) - Stock Price Intervals & Huffman Merge, Offer

JPMorgan 2026 SWE HackerRank OA walkthrough: strictly increasing stock price subarrays via sliding window pair counter and min cost element merge via min heap (

By Anonymous ยท 2026-03-30

Background

I am a final-year CS student targeting the 2026 JPMorgan Software Engineer Program, and the OA landed in my inbox about two weeks after I submitted the online application. I had been prepping in the typical "grind LeetCode mediums" mode and was nervous that JPMorgan's investment-bank reputation meant trick questions. It did not. The 90 minute HackerRank block gave me two classical problems, and what mattered was not raw algorithm depth but boundary discipline and clean output.

Timeline

Total so far: 3 weeks.

OA Format (2 coding, 90 minutes, HackerRank)

Two coding problems, unlimited language choice (I used Python). No behavioral, no personality test, no math multiple choice bolted on. The UI is standard HackerRank. Partial credit is visible after each test-case run, which is how I caught a TLE on Problem 2.

Problem 1: Stock Price Intervals

Problem: Given an array of stock prices and an integer k , count how many contiguous subarrays of length k have strictly increasing prices. Equal neighbors do not count as increasing. If k is larger than the array length, the answer is zero.

Classic sliding window. Instead of re-checking the entire window every step, maintain a counter of how many adjacent pairs in the current window are strictly increasing. The window size is k , so we need exactly k - 1 such pairs for the whole window to be strictly increasing. Slide one position at a time, decrementing the pair dropped from the left and incrementing the pair entering on the right. O(n) time, O(1) space.

I almost wrote the O(n k) naive version out of nerves. I stopped, drew the pair-counter idea on scratch paper, and coded the cleaner version directly. Handling k n as an early return was the one edge case the sample output forced me to notice.

Practice it: [[problem/536?company=37|Count Substrings with Non-Repeating Characters]]

Problem 2: Minimum Cost to Combine Elements

Problem: You have an array of positive integers. In one operation, remove two elements, add their sum back into the array, and pay a cost equal to that sum. Return the minimum total cost to reduce the array to a single element.

This is Huffman coding in disguise. To minimize total cost, you always merge the two smallest values currently available. A min-heap makes this easy: push every element in, then repeatedly pop the two smallest, sum them, add the sum to the running cost, and push the sum back. Stop when the heap has one element. O(n log n) time, O(n) space.

My first submission used sorting plus repeated list insertion and timed out on the large test case. Rewriting with heapq (Python's min-heap module) fixed it. The lesson I want to flag: "pick the two smallest again after each merge" is the exact shape that forces a heap; a sorted array does not stay sorted when you insert the merged sum.

The interviewer does not see your first submission, but the HackerRank UI shows test case status. Watch for TLE specifically on the large random inputs. That is where the heap-vs-sort distinction bites.

What tripped me up

Reading the bound on Problem 1 ("strictly increasing") twice was the only reason I did not blow 10 minutes on the [3, 3, 4, 5] case, where the pair (3, 3) breaks the window even though 4 and 5 are increasing. I had a bad habit last cycle of implementing <= when the problem asks < . Writing the literal inequality in a comment at the top of the function is a micro-fix that has saved me twice now.

For Problem 2, my heap was the right idea but my output format was not. The problem asked for the total cost as a single integer on its own line. My first version printed a trailing newline plus the list of merge steps, which HackerRank flagged as a wrong answer on two test cases despite the cost being correct. Silent output-format failures are the JPMorgan gotcha everyone warns you about.

Result

Submitted with 25 minutes remaining. Both problems hit 100 percent on visible and hidden test cases after the heap fix and output cleanup. Recruiter pushed me forward to the Hirevue behavioral loop the following week.

Tips

  1. For Problem 1, maintain a running count of strictly increasing adjacent pairs in the window. Recomputing the entire window each slide is O(n * k) and will TLE on the largest tests. The pair-counter trick is the only clean way.
  2. Reach for `heapq` on "merge the two smallest repeatedly" problems. Sorted lists do not preserve sort order under insertion. The heap is not an optimization here, it is the correct data structure.
  3. Check the output format twice before submitting. JPMorgan's HackerRank is strict. Print exactly what the sample output shows. Extra newlines, trailing spaces, or debug prints can fail tests that your algorithm passes.
  4. Submit partial solutions early. HackerRank shows per-test-case pass and fail. A brute force that passes 6 of 10 is a free floor while you fix the TLE. Do not wait until your "final" version to hit submit.
  5. Watch for strictly-vs-not-strictly wording. JPMorgan Problem 1 is strictly increasing, which excludes equal neighbors. I wrote the inequality literally in a comment at the top of my function before coding. Costs nothing, catches an off-by-one class bug.
  6. If the merge-cost DP tempts you, stop. Problem 2 looks like it could be matrix-chain-multiplication DP because of the "merge two" wording. It is not. The greedy min-heap is optimal because the cost function is additive and symmetric. Recognizing Huffman on sight saves 20 minutes.