During my undergraduate studies, I went through a ton of interviews for internships at nearly every company imaginable. After securing an internship for the summer, I would continue interviewing just to get more practice. I've had both bad and good interviews. My interview at Gusto was somewhere in the middle.

My interview consisted of a "culture/technical fit" phone screen where the interviewer asked about my background and what I was looking for in a company. He was nice and friendly, and answered all of my questions. The next step was a technical phone interview. I destroyed this phone interview with extreme prejudice. The HR leader told me that I received two "Strong Yes" ratings from my interviewers, which was "very rare".

The next step was an onsite interview, consisting of two technical interviews, a behavioral interview, and a "pair programming" interview. I basically bombed my first technical interview, but I also don't think I was given a fair shot at getting it right. When the interviewer arrived, the IDE on his computer was completely misconfigured, and he had to spend several minutes fixing the key bindings so that I could save a file and test it. Further into the interview, his machine could not import one class into another. After he explained the problem, which was quite comprehensive and sprawling, I had perhaps only 30 minutes of actual time to implement a solution to a very large problem after he got his machine to work correctly. Looking at solutions to this problem on GeeksForGeeks, I can see that they use a pre-existing priority queue data structure that takes a comparator as an argument; whereas in this interview, you have to implement the comparator, implement the queue, and then implement the larger problem. After I was rejected, the HR lead gave me feedback and told me that most candidates get more test cases passing. When I told her about the problems my interviewer had getting his machine to work, she responded, "That's a bummer."

The next technical interview went far better than the previous one, but according to the HR lead, I did not get a "Yes" from this interview because I didn't "step back and look at the bigger picture" when implementing the solution. This was even though my solution worked, and the interviewer gave me great feedback during the interview itself ("Yes!", "Perfect", "I like that you did this, I like that you did that"). My solution was well-implemented, clean, and optimal, so I'm not sure what else I could have done better. It's worth noting that this interviewer used CoderPad, whereas the previous interviewer used his own IDE.

The behavioral fit/culture interview is mostly to measure your intellectual curiosity and how you respond to feedback, etc. It's a basic culture fit HR interview. I received a "Yes" from this interview.

HR will claim that you don't need experience in their stack to pass the pair programming section, but that is totally and completely false. Had I known what this interview would have entailed, I would have spent hours studying Rails instead of Gusto's product. You are evaluated on how much you take charge in a foreign codebase, which you will obviously have an easier time understanding if you know the intimate details of Rails and Rspec. I also think it is just difficult to use another person's software development environment and excel in it in an interview setting. Software engineers keybind everything, so it can be nearly impossible to just up and switch to an entirely different setup in the span of an hour, under interview pressure.

Ultimately, I didn't really enjoy the interview as much as I would have hoped. I studied the product quite a bit and used a demo instance of it available on their website for several hours. I also researched their partner integrations and had an hour-plus long discussion with the owner of a small business that uses their product, taking extensive notes. I was very, very eager to work for Gusto. Typically, I try to play it a bit cooler, but I decided to change my approach given my attraction to their product and mission.

Given the dissonance in result and difficulty from one interview to the next, I think Gusto's interview process depends far too heavily on sheer luck. All the questions are sourced from the same pool and vary wildly in difficulty and scope. Some of them are just not suitable as interview questions given the amount of time they must be answered in. I also think the first interviewer's computer problems are completely unacceptable, considering the amount of preparation time I put into researching the product and the company. I sank a number of hours into preparing for this interview, studying the product, etc., and my interviewer couldn't even be bothered to take 5 minutes to prepare the question and his environment.