1. Simple phone screen to weed out wildly unqualified candidates - mostly HR questions.

2. One phone interview - coding done in Google Docs. This was a hard question dealing with dynamic programming, but I happened to study this kind of question in depth at school.

3. One-day onsite - 4 interviews and lunch.

• The first two interviews went pretty well.

• The second two went pretty poorly.

  • The first was a modified path-finding question.
  • The second was a very simple optimization question (given a string of text and a bunch of functions for finding the number of pixels for a given character and font size, find the largest font size for which the given string fits on the screen).
  • The third was given a compression decoder, write the encoder (there were a ton of edge cases here, mainly simple, but many edge cases had their own edge cases).
  • The last was a binary tree question (given a binary tree, find the largest subtree for which there are at least two duplicate subtrees within a given binary tree). There are simple, naive solutions, but they were looking for a very fast solution (as I left, the interviewer told me the answer was to hash).

Overall, I felt the whole process was very fair. I didn't get the position, but I don't think I should have. My background isn't in software engineering, and they seemed to be looking for someone who studied CS specifically.

Given the following decoder, write the encoder.

(The encoder should be written to compress whenever possible):

p14a8xkpq -> p14akkkkkkkkpq

(8xk gets decoded to kkkkkkkk. The only other requirement is that encodings be unambiguous)