I had an awesome video-interview with Triplebyte in January but they didn't decide to move forward. No complaints though as they gave a solid heads-up on what to expect, my interviewer was super positive (I felt like he was actually rooting for me), and they gave me solid feedback on my strengths and what concrete actions I should take if I choose to reapply in the future.
These guys are the real deal, so it's pretty neat that they're expanding out to big-names! I wish them the best!
> they gave me solid feedback on my strengths and what concrete actions I should take if I choose to reapply in the future.
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?
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?
Your hash table knowledge is perfectly fine. So is your red-black tree knowledge. Roughly zero percent of programmers implement those during the course of their job, so knowing their characteristics is more than enough.
My question was more along the lines of "there's a lot about red-black trees that I could know, but don't. What does he expect me to know about hash tables that I hadn't already told him?"
It's helpful to remember that nobody knows how to hire good candidates (it's an unsolved problem) so everyone has their own favorite, ineffective techniques. This results in a lot of puzzling behavior, like being told you need more red-black tree knowledge.
There's probably no way to know what they were looking for, short of asking them directly. But you have at least two options: (a) roll your eyes at anyone who tells you that you need more knowledge about red-black trees or hash tables to be an excellent engineer, or (b) realize it's a game, and play it with a passion.
Both routes are perfectly valid, and personally I prefer route (a). But if you're deciding to do route (b), you could study as much as you can on the subjects, quiz yourself on various trivia related to red-black trees, look up related interview questions, etc.
This is a bit of a tangent, but from a motivation standpoint, I've found it's optimal to think of interviews as a lottery ticket with 10% chance of winning regardless of your ability, rather than an as an obstacle that can be failed due to lack of ability. There's no reason to be discouraged when someone rejects you in a world where people reject engineers for reasons that are essentially random.
The exercise was to write a regex parser. He asked me about worst-case behavior, which is an exponential number of states. He asked for a regex with worst-case behavior, which I could provide, mentioning that I knew this because the textbook I used for the project pointed it out. Behold, a worst-case regex template:
(a|b)*a(a|b)^n
This requires at least 2^n states in the DFA.
He asked me to prove that 2^n states were required while he waited. I didn't know the proof and wasn't comfortable trying to produce it while being watched. There's no upper limit to how long producing a proof might take.
These guys are the real deal, so it's pretty neat that they're expanding out to big-names! I wish them the best!