I applied through their project track. It was described as a low-pressure way to write your code ahead of time and talk about it in the interview.
The interview was, instead, about making changes to my project while Ammon watched. (Also, there was a request to derive a formal proof while Ammon watched. I didn't get it.) After which I got a rejection saying that my project was great but my interview performance was so poor that they wouldn't move forward.
I complained that this wasn't actionable feedback, but the only way they ever responded to that complaint was "I stand by that", from someone other than my interviewer. Am I wrong to consider "you do poorly in interviews" hopelessly vague?
They contacted me, much later, to ask me to be a test subject for a new interview. New interviewer asked me about hash tables, and I responded to his questions with this information:
- Hash tables are the generalization of an array to being indexed by "whatever you want" rather than an integer; they have similar performance characteristics to arrays.
- If a hash code is larger than the size of your hash table's backing array, you would generally handle that by storing the item at index (hash_code % array_size).
- When two objects have the same hash, one strategy is to store them in "buckets", linked lists of everything present in the table at that hash key; another strategy is quadratic probing (where when the index you want is full, you repeatedly square the index until the space you're looking in is empty). Quadratic probing has the downside that when you delete an entry from the table, you have to leave a placeholder in the backing array saying "something used to be here".
- If a hash table gets too full, you generally create a new backing array of double the size and rehash everything into the new backing array. The size doubles rather than increasing by some constant amount so that the amortized time requirement for inserts will be constant.
- Amortized time complexity for a set of operations is the average time complexity per operation (not in expectation, but as measured after the operations have happened).
He also asked me about red-black trees. I could say that red-black trees were a self-balancing binary tree with the property that the length of any path root-to-leaf in the tree was within a factor of two of any other path, and that I wouldn't be able to write a red-black tree off the top of my head.
New interviewer, believing that I would be interested in reapplying to triplebyte, did give me feedback on what concrete actions I should take in order to do so. Specifically, he said I should focus on studying red-black trees (OK, fair enough, I guess) and hash tables. I thought I had pretty good coverage, purely within the interview, of hash tables. Is that wrong?