State Street · Primly Community

State Street coding interview and online assessment: format, difficulty, and a few things I wish I knew

quietquit_quincy · 6 replies

Three loops at State Street in the last two years (different roles, one offer, two rejections). Here's what I've learned about how their coding interviews actually work.

Online assessment

HackerRank platform, two problems, 90 minutes. The difficulty consistently sits at what I'd call "comfortable medium" to "medium that requires you to think for a bit." I've seen: Hash map / two-pointer problems String manipulation with multiple edge cases One graph problem (BFS, fairly standard)

They're not looking for DP trick shots. They want to see clean correct code and they do run hidden test cases, so edge cases matter. I've heard from someone who scored perfectly on the OA and still didn't pass because the hidden tests included null inputs they didn't handle.

Language: Java and Python are the most natural fits given their stack, but I've done it in Java and seen others use Go. Pick what you're fastest in.

Live coding rounds (phone screen and onsite)

These are timed 30-45 minutes, one interviewer, collaborative. The interviewer generally tells you upfront whether they want you to code or talk through the approach first. I always ask even if they don't volunteer it.

Once you get to the onsite, the live coding round can spike difficulty. My hardest problem was something involving interval merging with some finance-flavored context ("positions within a time window" type framing). It was a medium but the framing added noise. Stripping the domain language out of the problem first helped.

Things I wish I knew: They do ask you to test your own code. Not just "does this look right" but "walk me through a test case." If you're not used to doing that out loud, practice it. The behavioral questions are woven into coding rounds too, not just their own separate block. Expect "tell me about a time you had to optimize something under a deadline" after you finish a problem. They're a Java shop in a lot of places. If you're a Python person prepping generically, spend time making your Python readable and adding type hints. One interviewer commented positively on my type annotations unprompted.

Overall difficulty relative to other fintech: similar to Fidelity, easier than Two Sigma or Citadel. The bar is real but approachable with solid medium-level prep.

6 replies

pivot_pat

The hidden test cases thing is something I always forget about. I always test like two happy path examples and submit. Do you do anything specific to force yourself to think about edge cases during the OA?

qa_quinn

I keep a mental checklist now: empty input, single element, very large input, negative numbers if numeric, duplicates. For strings: empty string, all same characters, unicode if it seems relevant. Runs through it before I finalize, takes maybe 3 minutes and has saved me multiple times.

pivot_pat

The Java shop observation is interesting. I'm coming from a mostly Python background, currently brushing up on Java because so many fintech roles ask for it. Was the coding interviewer picky about Java idioms or was it more about correctness?

sre_sol

"Stripping the domain language out of the problem" is solid advice for any fintech coding round. The finance framing is basically irrelevant 90% of the time and it's there partly to see if you panic when you don't recognize a term. I've seen candidates spiral because they thought they needed to know what a NAV was to solve the problem. You don't.

growth_gabe

How many coding problems in the onsite? You mentioned 45 minutes but did they fit two problems in or was it one with discussion?

qa_quinn

In my two onsite experiences it was one main problem plus usually a follow-up or extension. So you solve problem A, they ask "now what if the input size is 10x, how does your solution change" or "add this constraint." Rarely two completely separate problems in a 45-minute slot.