Documenting a bad phone interview experience. I don't know if this is typical for OCI, but here's my advice: if you can tell early on you're going to have a hard time communicating with the interviewer, just reschedule.
The interviewer was some old guy, and his accent was incredibly, incredibly heavy. That said, there's nothing to be done about that in general — my own team has several people with heavy accents too, so as long as I listen carefully it's usually not a problem. But this guy somehow couldn't understand what I was saying either. He had me repeat myself over and over throughout the call. Unbelievable.
Worse, the coding question was something he was making up and revising as he went — typing it out, thinking, then changing it, over and over again.
To boil down the final version of the problem: you're given a stream of login events for a bunch of userIds, and you need to answer, at any point in time, which userId was the earliest to log in and has logged in exactly once so far. There are two operations — one records a user login, the other returns the "first user" — and both are supposed to be O(1). He said logins would be relatively infrequent, but lookups would happen a lot.
The problem itself was actually pretty simple — the real issue was that the interviewer never clearly said what he wanted. At every step I kept checking my approach with him, and he never said there was a problem with it. My first reaction on seeing the problem was that it was basically a simplified LRU cache, so I briefly said I could do it with something like a doubly linked list. He just looked confused, like he didn't know what a doubly linked list was. So I figured maybe I was overcomplicating it, and asked if he just wanted any user who had logged in exactly once — he said yes. So I wrote a simple version with two sets. But after I finished, he told me that wasn't what he wanted — he wanted the user who had logged in first among those who'd logged in exactly once. Fine, I said, so for the second version I switched to a queue plus lazy deletion, which also works — I told him the average complexity was still O(1), just O(n) in the worst case, but O(1) on average. He wasn't satisfied with that and wanted worst-case O(1) every time. By this point I was getting pretty close to losing it, but I held it together and told him, well then it's back to my first idea — the simplified doubly linked list — and implemented the code again.
So over the course of thirty-some minutes, I ended up writing three different versions of the same problem. I'm sure that every single time, before I wrote anything, I told him my approach and confirmed the expected output with him first. It felt like this guy didn't even know what result he wanted himself — or maybe he just genuinely couldn't understand what I was saying.
Overall, it was a really bad experience. Reflecting on it, going forward I need to align more with the interviewer during the discussion — the example I used at the start was too simple. With an interviewer like this who has communication issues, it's better to throw out more test cases upfront to confirm you're both on the same page, so they don't keep changing their mind on you. On the other hand, interviewing is a two-way filtering process too. The OCI interview experience was really bad — my advice is if you get an interviewer you're going to struggle to communicate with, definitely ask to switch.
Discussion
Loading comments…