HR reached out to me on LinkedIn, and we scheduled the first phone call. HR gave a quick overview of the company and emphasized how intense the work culture is there. HR made it clear that the next round would normally be a one-hour interview, but explained that because the company valued efficiency and speed, they were only giving me 45 minutes.
Then we scheduled the first technical phone screen. The interviewer showed up 6 minutes late, and a shadow interviewer was also there, but the interview still ended at the originally scheduled time. I was worried about running out of time, so I did a quick introduction and jumped straight into the problem.
The question was new to me: implement an in-memory key-value store that supports transactions. The system needs to process a series of commands that assign values to variables, print variable values, and manage transactional blocks. The hard part was handling assignments made to variables earlier within a transaction.
My first instinct was recursion, because the pattern was very obviously recursive. But the interviewer kept pushing me to follow his own approach instead. I didn't really understand why, but I figured that if the interviewer was steering me away from it, there must be something wrong with my recursive solution, so I went along with his direction.
Because I kept having to guess what he wanted, the discussion dragged on for almost 30 minutes. He couldn't explain why his approach was better either. When I really couldn't guess anymore, he finally said he wanted me to use a stack. I was honestly speechless — isn't a stack just the iterative version of recursion? I still don't know why he felt the need to block my original idea. I wasn't expecting the interviewer to go easy on me, but if he hadn't even fully worked through the problem himself and could only handle the one solution he already knew, that's not a great sign for an interviewer's level.
Discussion
Loading comments…