1. Technical Assessment - Ruby questions with multiple-choice answers and some writing questions about improving their codebase, as well as looking at issues and code reviews. You are given a week to submit it.

2. Technical Recruiter Screening - Call with the Tech Recruiter went well. I shared how impressed I am with the company and how I would love to work for GitLab. He conducted his tech screening, which led to getting several interviews set up within only hours after the interview. He also let me know what the interview steps would be if a candidate is proceeded to the next stage. They scheduled several interviews ahead of time. However, at any point if they decide to not proceed with a candidate, those interviews will be cancelled. I think there might be an interview with the VP of QA too, but most of their process is all outlined in their public handbook. Highly recommend reading them.

3. Interview with the Hiring Manager, 60 minutes - I was ready for this and was very much looking forward to it, but I withdrew. See the end of this review for my reasoning.

4. Interview with 10 members of their QA Team, 60 minutes - I withdrew.

5. Another Technical Assessment - This one was very well laid out. I was impressed, to be honest, and would still work on it in my free time. Without even meeting, I can tell this Sr. SDET was very thorough and organized. It was definitely a large project filled with several tasks. Fork their repo and submit an MR for the given assessment. You have one week to do this. This is while you have two other interviews scheduled with them for 60 minutes each, and if you are like me, you probably have other interviews.

6. Technical Interview, 60 minutes - Technical portion of the interview (not sure what it all entails, but I would assume technical interview questions) and code review of the MR. This invite included 12 people in total!

7. Interview with the Director of QA

When I saw this position with GitLab, I was super excited to work there. They are always remote, mostly because I like their tech. Everything is public. There is so much you can learn. Very documentation-heavy, which I found helpful if you don't go overboard.

As much as it would be awesome to interview with them, I did not want the stress of their large number of people in interviews. Seriously, it is intimidating when it is a 4/5 panel team, but knowing 12+ people have to give feedback on you is just unrealistic to me. They give you a salary calculator, and it seems to be on the lesser side for NW. The ranges with some other companies were much higher. Also, if I got through to the final stage, the pay would have been less than what I was paid in my last position. Yet, I was still interested because I thought it is 'GitLab', and one of my favorite products. If I had made it to the final stage, the total of people who would have interviewed me would be about 24 people. That was too intimidating for me and too stressful. I withdrew!

Overall, they were prompt and well-organized, even though there were some miscommunications on scheduled interviews. Like another reviewer said, one thing to note: GitLab did not give ridiculous Algorithm/Data Structure LeetCode type exercises (the current trend). Instead, their tech assessments were fair and reasonable for this role/position. To conclude, having interviews scheduled with a large number of people (for example, 10+ people) seems like it says they are not confident in their own skills to find the right fit without needing the entire engineering team. It is a poor management (time/cost) of engineering resources.

Rate your Ruby experience.

Some Ruby coding concepts.

Testing techniques.

Troubleshooting techniques using their merge requests, issues, or codebase.

Tech task: complete one of the items in their 'open' issues.