During my undergrad I went through a ton of interviews of internships at nearly every company under the sun. After securing an internship for the summer I'd continue interviewing just to get more practice. I've had bad interview 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, what I was looking for in a company, that sort of thing. 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 got two "Strong Yes" ratings from my interviewers which was "very rare".
The next step is 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 binding so that I could save a file a test it... After we got further, his machine could not import one class into another. So after he explained the problem, which was quite comprehensive and sprawling, I perhaps had 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 preexisting priority queue data structure that takes a comparator as an argument; whereas in this interview you have to implement the comparator, implement the queue, 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 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 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, 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've 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, how you respond to feedback, etc.. 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 code base, 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 key bind everything, so it can be nearly impossible to just up and switch to an entirely different set up 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+ long discussion with the owner a small business that uses their product, and took 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 just completely unacceptable, considering the amount of preparation time I put in to researching the product and the company. I sunk 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 prepare his environment.
