Mercury · Primly Community

Mercury coding interview / online assessment, format and difficulty

backend_bekah · 4 replies

Went through their OA last month while still employed (lunch-break leetcode is my cardio). Here's the breakdown.

The OA was through HackerRank or their own platform, two problems, 90 minutes. Both problems felt like medium difficulty. One was a standard array/sliding-window type, the other involved a graph traversal. Nothing I'd call hard, but also not trivially easy if you're rusty.

The coding round in the onsite (after clearing the OA) is different. One 45-min session, one problem, interviewer is live on the call. Difficulty felt like a medium-to-hard. The problem I got was related to string parsing with some edge cases around malformed input, which felt fitting given Mercury is processing transaction data and probably cares about robustness.

Things I noticed: They want clean code, not just a solution. I wrote a function with a confusing name and the interviewer asked why I named it that. Small thing, but it stuck. Edge cases matter more than I expected. I got through the core logic fast but we spent the last 15 minutes walking through weird input scenarios. That part felt very intentional. No "gotcha" tricks. No bit manipulation, no memorize-this-pattern stuff. The problems were designed to require actual thinking, not algorithmic trivia. Python and TypeScript both seemed fine as choices.

I wasn't given the option to use any external resources during the live coding round (it was a screen-share setup), so prep the way you'd prep for any traditional whiteboard: fluency without IDE crutches.

Overall: not a grind-300-leetcodes shop. More like, can you write solid code and catch your own bugs? The bar felt reasonable for the seniority level.

4 replies

alex_design

Were the OA problems timed individually or total 90 minutes for both? I always panic-speed on the first one and then have no time for the second.

quietquit_quincy

Total 90 min for both, no per-problem timer. I'd budget ~35 min each and use the remaining 20 to check edge cases on whichever one felt shakier. That worked for me.

pivot_pat

Appreciate the detail. The string parsing thing makes sense for fintech. I'd guess they're thinking about transaction memo fields, routing number validation, stuff like that.

qa_quinn

The edge case emphasis is interesting. That's actually more aligned with how real engineering works than pure algorithm speed. Weird to see a company interview that way.