This was a question already reported on the forum: a file system problem. I got through the first two parts basically on the first try. The interesting thing was that the interviewer kept interrupting me while I was writing, asking what this function does and why I wrote it that way. I said it would be clear once I finished writing. When I was done I walked him through it with an example, and he quietly went "mm" a couple of times. Afterwards I looked up his background and he is a senior staff engineer, so he probably wasn't unable to read my code. He was either questioning my approach or unhappy about something else.
With about 10 minutes left he had me do part 3. Besides the cd that was mentioned on the forum, there was one more requirement: support relative paths. That means changing the code from the earlier parts, which is also where mistakes tend to happen. I finished writing with less than 5 minutes left, but ran into a problem while testing, probably a bug in how I handled relative paths. I figured a typical interviewer would call time here and move on to Q&A, but he said I could keep debugging. So I looked at the test cases again, tried changing a few things without success, and then told him where I guessed the problem might be. By then we were already 3 minutes over, and he gave a perfunctory reply and ended the interview, with no Q&A at all. A day later I was notified they would not be continuing.
The whole experience was on the negative side, and I felt like I just couldn't connect with the people at this company.
Discussion
Loading comments…