I submitted my resume through a friend and had a phone screen interview, followed by an onsite interview. I believe I was interviewed by six people, including one junior engineer, a few senior engineers, and a few managers. The questions they asked were generally reasonable and smart engineering questions.

I had not prepared for a grueling technical interview. As I am coming from a fairly demanding management position, I am less fluent with coding than I once was. Still, I believe I have a right to call myself an excellent developer, especially in the skills one gains with significant experience, such as architecture and systems optimization.

I had an off day and definitely did not nail all the technical algorithm writing parts of the interview. To be totally frank, the reason (other than just being "off") is that I was rusty, and very few people do that kind of coding anymore (i.e., "write logic to find a cycle in a linked list"). This is because it's abstracted away in modern languages.

It's important that developers know how low-level algorithms work, but to expect them to build highly optimized, syntactically accurate algorithms for obscure problems is not interviewing for the skills that will really be needed in most of these jobs. I think what it does is find the super-smart, just-out-of-school engineers, but it does a disservice to those who have moved on to higher-level engineering problems.

Forcing me to do it on a whiteboard rather than giving me a computer is also the sort of thing that I would expect a progressive company like Google to have done away with by now. Who composes real code on a whiteboard in real life?

Anyhow, I was turned down for my technical performance, which I genuinely resent as it's a misjudgment.

In a directory name containing an arbitrary number of "/.." parts, like "/a/b/c/d/../../e", implement an algorithm that removes all instances of "/.." along with the preceding directory to reduce away all "/.." syntactically.

Now adapt the algorithm to be run on a VERY long string, which must be broken into pieces and solved using MapReduce.

Yeah, not trivial.