An initial phone screening is conducted by a recruiter, who also asks very basic technical questions at the end. From there, a HackerRank test is scheduled with two problems, and you are given 36 hours to complete it.

The HackerRank questions consisted of one fairly easy problem and one moderately difficult problem. Both had time constraints for large file sizes, so unless you write high-performing code, you will not pass all test cases. Although I did not pass all 12/12 test cases for each problem, I was still informed that I passed. From there, I was scheduled for an on-site interview.

The on-site interview consisted of four 1-on-1 interviews, each lasting an hour, for a total of four hours. Two of these were technical.

• The first technical interview focused entirely on algorithms. Study your 'Cracking the Coding Interview' book; the examples come out of this book! I was given two questions to write out on a whiteboard.
• The second interview was behavioral. You are given three broad questions, and you are expected to provide roughly a 10-minute answer for each in STAR format (e.g., 'Tell me about a time X happened and how did you resolve it?'). They are looking for team players, people who are open, and most importantly, someone they can identify with. I was asked many follow-up questions about the real-life stories I shared. You should practice telling these stories and be ready to really sell how you overcame the issue and how it made you and/or your team better. Ten minutes provides ample time to offer significant context and detail, as the interviewer wants to relate to you!
• The third interview was another technical interview. This one focused more on explaining the architecture you worked with in depth. There were many questions where the interviewer simply wanted to hear you talk through technical concepts. I believe this was to gauge your comfort and confidence in explaining technologies and demonstrating understanding. I was also asked to whiteboard a basic architectural strategy for implementing certain classes.
• The fourth interview was a case study. This is important! The case study has no wrong answers. Don't overthink it; just ask questions! I asked questions endlessly until we had clarified everything. It's not meant to be difficult, nor is it meant to be overthought; there is no trick. It's simple engineering: identify problems, assess why things were done a certain way, offer solutions, etc. I was also given a paper with terribly written code and asked to clean it up as much as possible.

The interviewers were all incredibly friendly, professional, intelligent, and relatable. Most importantly, they helped me along and made me feel comfortable. None of the interviewers were ever condescending, which is something I have encountered frequently elsewhere. If you get stuck, they are there to offer hints and guidance. Even with my own code, I made a few small mistakes, but when they pointed them out, I was able to correct them immediately. This greatly helped alleviate my pre-interview anxiety. At no point did I feel uncomfortable, and they did not ask textbook questions or expect perfect syntax.

The interview process from start to finish was well executed, and it was the best I have experienced. They genuinely aim to assess your reasoning ability, creativity, understanding, and personality. This approach may filter out some highly technical coders who are poor communicators, but that is their prerogative.

I received an offer the following day. Overall, the interview wasn't difficult, but I believe the interviewers have a keen sense for identifying those who are exaggerating and those who truly know what they are doing. Read your book! Practice case studies. Practice reciting behavioral questions in the mirror.

Given two arrays of characters, add them together like an addition problem and return them in a char array. ['3', '5', '9'] ['1', '2', '8', '4'] = 1284 + 359 = 1643 = ['1', '6', '4', '3']

Tell me about a time you didn't get along with a coworker, and what did you do to resolve it.