I applied online for a remote SRE role and had a quick chat with a recruiter via Zoom. She was a lovely person, and it seemed like everything was going well. In fact, she didn't really do anything other than make a connection and then give the next steps.
I didn't realize that this is where the problems would begin.
The next steps were unclear; she rattled off a series of things that would happen: a technical coding problem, code review, values interview, hiring manager interview, then more coding, then more values, and then... it was all so much, so quick.
I did, however, understand that the next step was the coding challenge. I was asked to provide an availability window for the two-day challenge to begin. It was all automatic, so everybody being on vacation wouldn't be a problem at all.
The invite came right on time, and then it came again; I was invited twice. No worry though, I'm reading through the thing and knew to leave a comment in the issue/pull request, and somebody would help. The GitHub issue outlining the challenge encouraged candidates to commit their code in stages so the progress on it could be walked through in the technical interview. Well, I spent a couple of hours on it and made the pull request, planning to spend a final hour the next day to polish it.
It turns out the information the lovely recruiter gave me was wrong, and my access was closed right away, with the steps not completed. I tried to get in touch with somebody, and luckily I got an email. The email explained that the challenge was actually only eight hours, and that it was unfair for me to have more time, but, go ahead. But I didn't have the right access(!), luckily I was able to work around it with a fork.
I wasn't impressed with the bad information and how that was handled. Applicants beware: Verify with your recruiter just how long you have to work on it, and plan for less time just in case.
Evidently, my code was alright enough to qualify for the next round of Zoom interviews. Again, I would have to provide availability, which I did, even though one of the two emails I received to do so wasn't valid. The sequence of interviews wasn't explained well at all because when we got to them, it turned out that one of the two from the first interview wasn't there. In the second interview, the subject was completely different, with the interviewers literally reading from a sheet of paper (laughing about how strict the process was). The coup de grâce was the final interview. The individual explained that if the recruiter wasn't responding quickly, to skip them and just email him because, "Have you read Glassdoor? They're not very good." I'll admit that it was a red flag, and that working with that kind of attitude was kind of a danger. We had a nice enough chat, however, where he led off with, "The answers don't matter, I just care how you answer," which is a bit rubbish because why are we even here if what I say doesn't matter?
Anyways, we wrapped up, and he said he wasn't sure about some things he had reservations about; he never asked questions to clarify or probe further. I volunteered additional sources, which addressed one of his concerns.
Almost an entire week passed with zero contact from anybody at GitHub, and it wasn't until I emailed that I was told, "Yeah, we're really busy this week." Okay, that happens. Three days later, the recruiter emails back to say they're going with other candidates.
Along the way, there was no acknowledgement of me expressing additional interest in a similar role that was published after my application was in. I wasn't given any kind of explanation other than, "we're going with other candidates."
Most of the people in the interviewing process seemed like very nice people, but were restricted by the system they find themselves in. However, the system needs to be improved so that candidates are provided an equal, fair, and consistent experience. It is also bad form to trash talk your coworkers, so maybe work on that?
Solve this Ruby coding problem
The following metrics were computed from 2 interview experiences for the GitHub Site Reliability Engineer role in Remote, Oregon.
GitHub's interview process for their Site Reliability Engineer roles in Remote, Oregon is extremely selective, failing the vast majority of engineers.
Candidates reported having very negative feelings for GitHub's Site Reliability Engineer interview process in Remote, Oregon.