Robinhood SDE II Interview Experience — Solved the Coding Question, Still Rejected in Under 30 Minutes

Recruiter Call

Main topics they asked about:

• Self-introduction
• The project I worked on that had the most impact, and my role in it
• Why I'm interested in Robinhood
• The top three factors I care about when choosing an offer
• What I'm looking for in my next role
• Compensation expectations
• What other companies I'm interviewing with, and what stage each is at
• Visa status, tech stack, relocation, etc.
• Questions I had for them at the end

Overall it felt like a pretty standard process, and the conversation flowed fine.

Technical Screen

Started with a self-introduction again. The question was Referral Count — basically it's counting the number of descendants for each node, and DFS plus memoization is enough.

After that they asked about complexity and code optimization:

• If you need to sort the top three, you can optimize with a heap
• DFS can also be converted from recursion to an iterative approach using a stack, to avoid recursion depth issues

The follow-up was: if this were a live online scenario with a huge number of nodes that keep getting added, how would you evolve the solution?

My answer was: you could record each node's parent. Every time a new node is added, walk up from that node updating the ancestor counts along the way, so you don't have to re-traverse all the nodes each time.

It had been a long time since I did a coding round, so talking while writing code still felt a bit awkward... Since I'd done this problem before, the whole thing — code plus all the Q&A — wrapped up in under 30 minutes. I still got rejected afterward, and I'm not really sure why.

Looking back on it myself, here's what might have gone wrong:

• Not enough communication — there wasn't much back-and-forth with the interviewer
• My self-introduction was too short — I probably should have talked for 1–2 minutes and gone into a bit more detail
• Don't jump straight into writing the answer — talk more about your thought process, like how you're interpreting the problem and how you get from brute force to an optimized solution
• Don't talk too fast, especially while writing and explaining at the same time — deliberately slow down
• Don't wrap up too quickly — it's better to proactively discuss edge cases, complexity, scalability, and possible extensions

Overall, what this round taught me is that solving the coding problem is just the baseline — showing your reasoning and communication during the interview matters just as much.