As most people have described, the interview process is lengthy, rigorous, and time-consuming. My first step in the interview process was to take a simple and short HackerRank coding challenge. I finished under the time limit with a clean solution. A couple weeks later, a recruiter reached out to set up a one-on-one culture fit phone interview that lasted 30 minutes. I was not informed that this was a culture fit phone call until 15 minutes before the phone call, and I had assumed this phone call would be similar to Google’s phone interview style. This was frustrating because I had no idea what to expect going in to a talk with a senior developer. After the phone call, TTD reached out with an open-ended N-Way Set Associative Cache design and implementation problem, as described in other reviews. The gave the option of developing this cache in C# (with which I had no experience), Java (with which I have moderate experience), and Python (with which I have 5+ years of experience). I was under the assumption that TTD would have a developer fluent in Python – this came back to bite me later in the process. I had quite a few email exchanges with a developer about the requirements, assumptions I could make, early-stage design decisions, and other similar questions. While the responded quickly, I rarely felt that the developer read through my entire question, as each was kind-of answered, but somewhat off the point I was getting at. I then built out my cache in about a week, complete with package build instructions, verbose testing, 10 pages of documentation, and a bunch of error handling. They got back to me within a few business days about some follow-up questions that they had about my design. The questions seemed a little arrogant and it certainly seemed like the questions came from someone unfamiliar with Python (i.e. did not know how threads are handled in Python vs. other languages like Java/C#). I felt that I answered these questions verbosely, justifying the parts of my designs I felt were a good thought and acknowledging where some of my flaws were, and several solutions on how to fix these issues were I to iterate my design. While TTD is one of the only companies that I’ve interviewed with that gives you feedback for why they decided to pass (awesome practice by the way, in theory, it should be helpful), the reason I got rejected was extremely frustrating and will likely turn me away from applying to TTD in the future: - The feedback said I implemented something that was like a web service (not a cache) with thread pools. Never once did I implement threading because of how Python handles threads, although I did explain that in a different language, threading the cache would be a great idea and I explained what changes would need to be made to make it thread-safe. - The feedback said that I was allowed to submit a second solution after my first completely missed the mark. I only ever submitted a single solution, and this comment makes me think they confused me with another candidate as I never submitted the type of code they’re referring to. - I added in some functionality that was not requested in the prompt. This complicated the code a bit but added in optimizations for several cases that I’ve experienced in the past. It was clear that TTD has a very strict vision for what they want you to make, and stepping outside that with other consideration was mere “overcomplication”. - Based on the runtime of a read operation they expected, it was clear to me that they did not accurately describe what data structure they were looking for. - The feedback then said that I did not even consider multi-threading. This directly conflicted with their first feedback point and showed that they did not read my documentation or my response to their clarifying questions. I commend TTD for committing so much developer time to review a candidate’s entire caching library. I felt, in theory, that this a fairer way of interviewing someone compared to a couple whiteboard interviews on data structures. However, I walked away feeling that they did not value design decisions that may be different from what they thought of when coming up with the prompt, that the developers did not read through my documentation or responses thoroughly (they missed my point entirely several times), and that the time that I put into the coding challenge was not valued. My advice: - Don’t add in anything beyond basic functionality and some type/error handling, design something that is built for the most basic case - DO NOT design your solution in anything but C#, it is clear that the developers do not know these other languages as well as they know C# and it will hinder your chances in this step - Suggest a phone call instead of responding to follow up questions over email? I did not feel that they read through my responses, merely they skimmed them - Clarify, clarify, clarify