Applied online, the whole process only took a few weeks. The majority of it was a standard software engineer interview: a phone screen, LeetCode/HackerRank style tests, and technical interviews. It was very, very easy all the way up until the last step.

The last step was an all-day interview consisting of three 1-hour technical interviews in the morning, followed by behavioral interviews after lunch. The three technical interviews were equivalent to hard LeetCode algorithms problems. I knew this in advance and studied nearly 30 hours in the week leading up to the interview, completing all the LeetCode problems I could.

When the interviews started, they told me that process, code quality, optimization, and unit testing were more important than actually completing the problem. All of my interviewers were very friendly, and it was an overall pleasant experience.

I did all three interviews, prioritizing coming up with an optimal solution, explaining my design/development process, and implementing the solutions in a test-driven manner. Each interview started with a short 10-minute chat and an explanation of the problem before starting to code.

I completed the first one, although my solution was slightly suboptimal. The second one was about 90% of the way to a complete solution, which the interviewer said was fine.

The third interviewer explained that the third test was more of a pair programming session and that he would just be evaluating how I work in that environment and how I go about solving a complex problem. We did the 10-minute chat and then spent about 40 minutes going through the problem, brainstorming solutions and designing data structures. It wasn't until this time—50 minutes in—where he told me that I was actually supposed to complete the problem, which I was unable to do, obviously.

I took the one-hour lunch break, and when I came back, the hiring manager or lead (I don't remember his title) told me I wasn't invited to the second half of the interviews. I asked what I could do to improve, and his tone completely changed, as if I was wasting his time by asking why I had failed. He liked my code, my experience, everything, but—you guess it—I failed because I didn't finish.

So, everything the interviewers told me was a lie. They don't care about code quality, process, or good tests. They want you to finish, they want the optimal solution, and they want unit tests. If you get this far, don't chat for 10 minutes, and don't let the third developer waste your time by, you know, actually designing—start coding immediately, or you won't finish.

There must be some miscommunication between the interviewers and the hiring team. The interviewers were all developers and were very friendly and obviously deeply cared about code quality. I was looking forward to potentially working with them. But apparently, the people who make the decision only care about whether or not the interviewee finishes.

They are hard problems. If you don't already know the solutions by heart, you won't finish. They don't want good engineers; they want people that have memorized Cracking The Coding Interview. They aren't professional or transparent with their interviewees; in fact, they outright lie to their interviewees about what they're looking for.

I encountered LeetCode/HackerRank style Hard questions. I'm not sure of their official names, but the first problem involved finding the closest city in a coordinate system, and the second was Huffman coding.

The third question wasn't a LeetCode problem. It required implementing an abstracted compiler build order optimizer. The input consisted of source files, their corresponding build times, and dependencies. The goal was to output the optimal build order.

I'm unsure how anyone is supposed to solve this in less than an hour, let alone the 15 minutes my interviewer gave me after wasting all of my allotted time.