After a recruiter reached out to me via LinkedIn, she gave me a 30 minute quiz where she asked me basic Linux questions.
Next, she directed me to another recruiter who asked me one basic data structures/algorithms based question and then a file parsing question.
I applied online. The process took 4 weeks. I interviewed at Meta in Jan 2019
Interview
3 step process.
First, the recruiter sent a link for a Linux related quiz. These were all related to Linux commands.
After that there was an Algorithmic Round, in which the questions were pretty basic, Leetcode easy, but the focus was not in complexity but systemic design, and exploring alternate implementations for better feature coverage.
Third, there was a systems round which was related to Linux Internal and Troubleshooting a system under load. All relevant topics for this round could easily be read up in Brendan Gregg's blog and his book.
Not sure where I went wrong, was expecting an acceptance offer.
Interview questions [4]
Question 1
How would you troubleshoot a system in which you are not able to start an application on the server?
I applied online. The process took 6 weeks. I interviewed at Meta in Dec 2018
Interview
You first had to complete an 20 question quiz, then a coding phone interview, and lastly a systems phone interview. Afterward, you would get told offer or no offer.
The 20 question quiz is all multiple choice. You will have 18 minutes to complete it, which means they give you about 54 seconds for each question. Mine were all based on linux and networking, essentially proving that you know your way around the linux shell and are at least competent in networking. A good way to prep for this would be to install linux on your computer (I recommend Ubuntu or Debian) and use it from day-to-day. Try forcing yourself to use the shell instead of the graphical interface. It'll make you much more familiar with how it works and best prepare you for the quiz.
The phone interviews were the most challenging. In the coding interview, I had two problems. A "warm up" and a "difficult" one. They weren't particularly difficult problems, but if read incorrectly you could easily mess them up. If you take your time and think out loud, you'll do fine.
The second phone interview was the systems interview, it was very holistically. I wrote no code in this interview and instead got an open ended question regarding real life situations that might occur. One question that is similar to one I got is "'httpd' is not serving files from '/var/www/html'. Why might this be happening? How might you go about diagnosing and fixing this?". Be sure to know exactly where your knowledge ends. If you do not know something, do not waste their time acting like you do. They want to see the breadth of your knowledge, and if you don't know something tell them and they'll move on to something else which you might. It's okay to speculate and apply other knowledge to your situation. For example, "I've used W before on X system and it behaved in Y way. I'm unsure whether or not it would apply to our scenario with system Z, but I would first look into this because of that experience."
Interview questions [2]
Question 1
We have a database running unusually slow in production. Why might this be happening?