The interview process was fair. 1st is a phone screening, just normal HR questions. 2nd is a screening coding interview. It's a little wordy, so try to read and comprehend as quick as possible. Don't forget to do TDD if you can. As much as they will say code readability is important, it's most important that you make as much progress as possible. Talk about every little thing you are doing, being quiet will only hurt you. 3rd is the onsite with 5 interviews: Manager Interview: Interview with the manager of the role. Normal fit questions. How you handle conflict, what have you previously worked on. Coding Interview: Same as the screening, wordy. Read fast, code fast, and talk the whole time. System Design: Classic system design meeting, nothing special. Bug Squash: This is a weird one. They will put you into a repo that is somewhat convoluted, and see if you can find the bugs and fix them. I honestly could only find the bug, but couldn't quite fix it. My opinion is that this particular bug/interview for Java was pretty dumb. My IDE (IntelliJ) kept throwing errors, and the interviewer was saying there shouldn't be errors there (30 minutes after I was investigating that error). So I basically spent 30 minutes trying to diagnose a thrown error that shouldn't be happening. So that was pretty weak. Honestly, hard to study for, and is a very bad gauge of an engineer. I wish you a good luck on this one. Integration: This is one you should crush. They are going to tell you to get your env setup before the interviews start. THIS IS THE INTERVIEW THAT IS FOR. I was told the env setup was for the bugs, but it's actually for the integration tests too. You will need to be prepared to send requests and parse json (this is said in their prepare doc as well). Whatever dependency you want to use to achieve that, be prepared to be able to import it into the project. The question here is DOUBLE as wordy as the coding interview. Read as fast as humanly possible, because there are a lot of parts. Their comments of, "it's not how far you get, but how you get there", is completely false, but most people know that's usually the case; just want to state it for the ones that didn't know. I was somewhat in control of why I was declined, and I took a lot of learnings from my interviews. I will speculate that the things that pushed me to a no hire were things that were out of my control. A bug repo that was throwing the wrong errors, I'm not sure how I control that. So that's unfortunate. I had the interviewer of the coding interview provide a misleading answer to my question, which he admitted, so I coded it to a different functionality. He didn't correct my logic, until the end. We both could have communicated better, but it ended up hurting my score I'm sure. I wasn't prepared to import a dependency in a different project. So I had to waste a lot of time in the integration interview setting up the dependencies I practiced with. With the small amount of time I had, I had to scramble to read a super long prompt, and pump out 2 parts in less than 20ish minutes. If I had the whole time, I honestly think I could have finished all the parts. There was for sure some things I should have done better, and I underperformed in some parts, but the things out of my control for sure contributed majorly to my declined offer. I'm honestly not sure if I aced the things within my control if it would have been able to overcome the glaring errors from those listed things out of my control. Either way, read the above and learn from my mistakes! It's hard to label it neutral, and not bad, because I lost a whole day to some annoying interviewing blunders by Stripe, but just the people in general I think brings it above bad. The people are insanely nice, not a single one was snobby, and they treated me with respect. I would apply again, and am thrilled with how far I got in the process. I really think that if I had a second chance to do some of the parts, I would have an offer. Good luck!