LinkedIn Site Reliability Engineer Interview Questions | Glassdoor.co.in

LinkedIn Site Reliability Engineer Interview Questions

Updated 16 Apr 2019
46 Interview Reviews

Experience

Experience
75%
5%
20%

Getting an Interview

Getting an Interview
63%
14%
9%
9
5

Difficulty

3.0
Average

Difficulty

Hard
Average
Easy

46 Candidate Interview ReviewsBack to all Interviews

Filter

Filter

Sort: PopularDateDifficulty

Helpful (9)  

Site Reliability Engineer Interview

Anonymous Interview Candidate in Mountain View, CA (US)
No Offer
Positive Experience
Difficult Interview

Application

I applied through an employee referral. The process took 2 days. I interviewed at LinkedIn (Mountain View, CA (US)) in April 2013.

Interview

Had an initial phone interview with a recruiter going over the company and position and a small handful of easy technical questions.

Second interview was also over the phone with two engineers and was very technical. Covered some lower level Linux and monitoring.

Was pretty nervous during second interview and bonked on some of the questions.

Overall it was a positive experience, the recruiter got back to me the day after my initial technical interview to let me know I would not be moving on which I appreciate not sitting around or having to bug them for a 'no'.

Interview Questions

  • Asked me how the kernel new to connect to a remote machine. Wasn't too sure if they were asking the lower level c calls, general OS theory, or just basic files / networking components (routing table).

    Also asked basic monitoring questions like how to monitor query times (bonked on this, just couldn't think well being nervous)   2 Answers

Other Interview Reviews for LinkedIn

  1.  

    Site Reliability Engineer Interview

    Anonymous Interview Candidate in Mountain View, CA (US)
    No Offer
    Negative Experience
    Average Interview

    Application

    I applied through a recruiter. The process took 2 days. I interviewed at LinkedIn (Mountain View, CA (US)) in February 2013.

    Interview

    Recruiter sent an inMail via Linkedin to me multiple times through a period of 8 months.
    i finally gave in and decided to take a phone screen, it was purely waste of my time. I took two 1hr phone screens with two different persons. First round was in depth discussion about my present company and my work at my previous company and such.

    Second screen was rather technical but its very easy, it was mostly syadministration stuff about kickstart, configuration management etc. I personally didnt felt there's a strong sense or interest for a good technical screen. Interviewer tells me he really enjoyed the conversation, would like to meet me in person and i should expect to hear from recruiter/staffing for onsite soon.

    After waiting for two more days i sent a follow-up email to recruiter asking for feedback and left a vm, but there's no response for another week. I followed up after another week then recruiter mails me "she's sorry that i havent received(?) the email sent to me on the interview day that, team'd like to pass". Irony is that this a template sent at 4:00pm where as the second screen lasted till 5:34pm that day. Seriously ???

    I've have personally known people who moved to Linkedin from my previous company and shared this feedback, the response i heard was the interview process could be a sham to meet the hr quota and someone could've handpicked for the position. My contact shared feedback that bureaucracy and back-filling is much rampant at Linkedin even though it's relatively younger and small.

    Interview Questions

    • sysadmin basics, how's the boot process for a linux machine.   Answer Question

  2. Helpful (39)  

    Site Reliability Engineer Interview

    Anonymous Interview Candidate in Mountain View, CA (US)
    No Offer
    Positive Experience
    Difficult Interview

    Application

    I applied through a recruiter. The process took 1+ week. I interviewed at LinkedIn (Mountain View, CA (US)) in September 2013.

    Interview

    The interview process consists of two phone screens: a technical phone screen and then a programming-oriented phone screen. The technical phone screen covered a lot of questions that basically boil down to: do you know what's going on on your systems? For example, what can you glean from the Apache logs on a webserver, and how would you know how performance was being impacted. (too many users hitting the server, or not enough resources allocated, etc)

    There were also operating system level questions. A few off the top of my head:

    - If you have an executable program (a binary) and you made a copy of that program, and then changed permissions on the copy, would a diff show that the file had been changed?

    - When you run a program from the shell, why doesn't the program log you out when it's done running? If you wanted this behavior, how would you run the program? (answer: exec)

    - Talk me through what happens when you make an ssh connection to a remote machine. Be able to be specific, such as the identification string exchange, algorithm negotiation, key exchange, etc.

    - Name as many TCP flags as you can. (URG, ACK, PSH, RST, SYN, FIN - mnemonic: Unskilled Attackers Pester Real Security Folks.)

    - What protocol(s) do/does DNS use when you run an nslookup. (answer: normally UDP, but TCP is used for zone transfers and if a record is too long to be returned via UDP)

    - Describe the difference between TCP and UDP, advantages and disadvantages of both.

    - When I try to connected to a remote machine using (for example) ssh, how does ssh know how to get to that remote machine. (be able to describe routing, default routes, and host name lookup.)

    The programming portion of the interview tests your ability to program in the scripting language of your choice. You can use common languages such as Perl, Python, Ruby, or PHP. You cannot use Bash or other shell interpreters (no sh, ksh, csh, etc)

    This part of the interview tripped me up a little bit, as most of my programming is oriented towards systems engineering problems. I write scripts to parse logs, distribute files, perform backups, etc. I don't do a lot of CS type programming. Unfortunately, the screener threw several of these types of problems at me, and it kinda threw me for a loop. I was able to solve these problems, but I'm sure I didn't instill the screener with a lot of confidence.

    - Write a perl program that prints a 12x12 multiplication table matrix.

    - Write a program that reverses the contents of a file, byte for byte.

    - Write a program that counts from 1 to 100. For each number, print a certain string if the number is evenly divisible by 6. Print a different string if the number is evenly divisible by 4. Print yet another string if the number is evenly divisible by 24. If none of these cases match, print the number.

    - Write a program that descends through a directory tree and prints all files. (hint: recursion is your friend here.)

    - Given an Apache log file, print the timestamp hour, minute, and second, followed by the number of times any log entry occurs during that time. (hint: if you're programming in perl, a hashed array works great here.)

    Interview Questions

    • You need to distribute a terabyte of data from a single server to 10,000 nodes, and then keep that data up to date. It takes several hours to copy the data just to one server. How would you do this so that it didn't take 20,000 hours to update all the servers? Also, how would you make sure that the file wasn't corrupted during the copy?   6 Answers
  3. Helpful (4)  

    Site Reliability Engineer Interview

    Anonymous Interview Candidate
    No Offer
    Average Interview

    Application

    The process took 3 weeks. I interviewed at LinkedIn.

    Interview

    Interview process began with an initial phone screen, followed by a technical q&a phone screen, and a coding phone screen. After that, there was an on-site interview with several people encompassing a wide range of topics - linux internals, web architectures, troubleshooting, hands-on diagnostics, and soft skills. The whole process was very well organized and very transparent.

    Interview Questions

    • Linux kernel internals got pretty in depth, as did questions about system architecture for high-performance websites   1 Answer

  4. Helpful (21)  

    Site Reliability Engineer Interview

    Anonymous Employee in Mountain View, CA (US)
    Accepted Offer
    Positive Experience
    Difficult Interview

    Application

    I applied through an employee referral. The process took 3 weeks. I interviewed at LinkedIn (Mountain View, CA (US)) in January 2014.

    Interview

    It was one of the most organized interview process I have participated. Thumbs up to Linkedin and the recruitment team. They were always giving me feedback during the process.

    1. It started with the phone screen by the recruiter with a few basic technical questions just to filter the candidates.

    2. After that you are scheduled with 2 technical phone interviews with other Site Reliability Engineers. The first is generic and include everything that you can imagine, from linux to network, fundamentals, databases, troubleshooting, etc. The second is a code interview, you both share a document and you are given a few operational challenges to solve. You pick the language to use.

    I really enjoyed that because I'm not a software engineer and I'm used to code stuffs to solve operational problems and that's what they want for a SRE.

    3. If you pass the phone interviews then you are set to go onsite and have the full day interview with more SREs. The onsite is similar to the first generic phone interview, but now all those topics are interviewed by an expert in that area and go as deep as you can keep answering him. This is the challenge part :)

    4. Once I was done with the onsite interview it took around 1 week to get the offer, but during that week I got a lot of feedback from the recruiter and she said I passed the process and they were discussing the offer and the SRE team that I would fit.

    I really enjoyed the process, it was more difficult than what I expected and the communication was great with the recruiters.

    All the steps above are communicated to you once you pass each of them, including the interview topics you are expected to have.

    Interview Questions

    • I can't talk about the questions, but one of the topics the recruiter will tell you is about Linux Internals and that is definitely the most difficult.   1 Answer

    Negotiation

    The negotiation was very easy and quick. Once I got the offer I asked for some changes and they returned to me during the weekend with the new offer.


  5. Helpful (66)  

    Site Reliability Engineer Interview

    Anonymous Interview Candidate in Mountain View, CA (US)
    No Offer
    Positive Experience
    Average Interview

    Application

    I applied through a recruiter. The process took 2 weeks. I interviewed at LinkedIn (Mountain View, CA (US)) in July 2014.

    Interview

    The initial communications were through a recruiter that works for LinkedIn. They contacted me about the job offer and we moved on to interviews.

    I interviewed with an engineer who did a very high-level asking of questions related to web architecture and how I would go about scaling X or Y. It was not very technical, although you were encouraged to speak your mind about technical topics.

    Based on the feedback received by that interview we moved on the another phone interview that was a programming interview. You were allowed to pick a language (I picked python) and they asked you 4 questions.

    Each question built on the other questions and it was a timed interview (60 minutes). The questions you were asked were taken straight out of CS 101 text books; given input, if input is divisible by 2 do X, if divisible by 6 do Y, if divisible by both do Z, else print something.

    Interestingly, because I haven't done any of these "simple" coding problems for upwards of 10 years, I found this portion of the interview the most difficult. For me it was difficult because these questions just are not what you come across in the real world. The majority of the code things I do today involve fixing bugs here and there and monkey patching code to make it work. Also, you typically have some context and foresight into a problem before you start coding. Being dropped a simple 1 + 2 question is nothing you'd ever encounter working in the real world; it's all academic as far as I'm concerned.

    I felt like I failed the programming interview, but surprisingly, I got a call back saying they wanted to do an on-site interview.

    They flew me out to Mountain View and I spent a full day with a number of their engineers going through what they called "modules". This is where it got interesting.

    I took special care to look at their culture. I noticed that the building is very quiet, there is not a lot of personal "schwag" hanging around people's areas. Not a lot of smiling engineers...curious.

    The modules included you having semi-technical one-on-one interviews with an engineer. There were some engineers that were VERY technical and weren't much interested in the chitchat that can happen where you talk about what you might currently be working on.

    The easiest module was the "lunch" module where you ...well...ate lunch, haha. I was expecting this to be a group thing though and instead it was just a you + 1 engineer who ate at the cafeteria. The engineer was the only one that I really "liked" after meeting them all, but still it was a one-to-one interaction. I was really hoping for a group effort.

    Throughout the WHOLE on-site interview process I got the sinking feeling that individuality trumps groups at LinkedIn. This bums me out because I currently operate in a fairly strong group position and if I am moving to a new position where I am more isolated, I really don't want that.

    Also, its so quiet. Creepy quiet. Like none of the engineers talk to each other. My current position there is ALWAYS something going on and a lot more background noise to remind you that "you're around people". I didn't get that feeling from LinkedIn.

    After the interview I just went back and cooled off in the hotel before my flight left the next day. Because of the 2 hour time difference, it was a good idea to plan for staying 3-ish days; 1 to get there, 1 to interview and 1 to leave.

    Interview Questions

    • There were two and they both happened during the live-debugging portion of the interview.

      All of the live debugging questions revolved around a simple website that had something broken in it. You were to fix the brokenness to be able to move on to the next page. In total there were 4 questions, each getting progressively more difficult to debug.

      The first question was a simple permissions problem on a file being requested by the client. The ownership of the file (a blank text file) was too restrictive, so it was raising an error. You could verify this in the apache web logs.

      The second error was due to a permission problem too, however this time the file was hidden in a sub directory of the main web site. You could only determine this by looking at the apache configuration file to see that the shtml file was located somewhere else. After that, change the permissions to fix.

      The third was a head scratcher. The filename in question was raising a 500 error and showing urlencoded characters in the filename in the web log. Looking at the name of the file on disk though, showed nothing out of the ordinary.

      It turns out that the unicode representations for the characters in the file name are printed in the terminal as english ascii characters. The only way you can tell that this is the case is to open the file and do a search for the filename itself and see if it matches. For example, if the correct filename is called "challenge1.shtml" you can search for that exact string but NOT find the unicode version of it.

      Once you find the incorrect file name, delete it and type the correct file name (in this case "challenge3.shtml" into the file and the page works.

      The final question was a segfault occurring in apache. It resulted in no information being returned to the client. You could see this occurring in the apache web logs as well as the Chrome tools.

      The apache web logs noted that a core file was dumped. This challenge required that you know a little bit about gdb and C programming. Basically, you need to run the core dump through gdb.

          gdb /path/to/apache /path/to/core/dump

      It will spew out a lot of stuff. In particular, it mentions that there is something happening in an apache module; mod_rewrite or something...it doesnt really matter.

      The output also points to the C source file for that module which is, conveniently on disk. Open that file in vi and jump to the line number mentioned in the gdb output (line 1861 or something). There you will see that if the filename matches challenge4.shtml to SIGSEGV; there's your smoke gun.

      They dont ask you to fix the final challenge, only to explain what the strstr is doing. The error in question basically looks like this

      if (strstr($r->filename, "challenge4.shtml") != NULL) {
          SIGSEGV
      }

      Just point out to them that, yeah, it's segfaulting when I ask for that file.   9 Answers
    • There was a paper presented to you with a number of nagios alerts and you had to rate them in the order you would approach fixing them.

      For example, one of them was a production host being 100% offline.

      Another was an environment alert about an entire cab that was overheating. Another was the tablet vip being down, another was a load average for the main website being really high.

      There were also a number of them that were QPS (queries per sec) related and included several security related alerts like XSS QPS and failed logins QPS   2 Answers

  6. Helpful (2)  

    Site Reliability Engineer Interview

    Anonymous Interview Candidate in Mountain View, CA (US)
    No Offer
    Negative Experience
    Average Interview

    Application

    I applied through a recruiter. The process took 1 day. I interviewed at LinkedIn (Mountain View, CA (US)) in February 2016.

    Interview

    Phone screener consisted of jr. level Linux questions. Outline of general interview topics were provided (data structure, API, and file system I/O). Interview was scheduled, but scheduler failed to provide timezone, leading to confusion and delay (could not have been the first time).

    Interviewers were focused on ability to code, less than ability to grasp concepts. Interview was strictly test-based, so be a good tester.

    Interview Questions

    • Parse a log except, providing a csv of the count of each proc per DTTM.   3 Answers

  7. Helpful (3)  

    Site Reliability Engineer Interview

    Anonymous Interview Candidate in Mountain View, CA (US)
    No Offer
    Positive Experience
    Average Interview

    Application

    I applied through an employee referral. The process took 1+ week. I interviewed at LinkedIn (Mountain View, CA (US)) in January 2016.

    Interview

    First there was a phone screen by recruiter. It was quite easy but if some questions are tricky. You don't need to get all of them right. During the interview the recruiter told me that she will put me through to next stage. A fews days later I took the coding interview. There were 4 questions. First was a fizz buzz type question. Second and third were both log parsing. Last one was involved in Linkedin RESTful api calling and recursion. I had problem understanding the third question during the process so I didn't make it. But I found it was actually quite easy afterwards.

    By the way, I am not sure whether they called through phone or internet, the voice quality was really not good. It seems to be the case for Facebook too.

    Interview Questions

    • Print all statistics of every process name and its log for every minute of a piece of system log.
      In other word, use minute as row title, print all statistics in the corresponding minutes.   2 Answers
  8. Helpful (2)  

    Site Reliability Engineer Interview

    Anonymous Interview Candidate in Mountain View, CA (US)
    No Offer
    Positive Experience
    Average Interview

    Application

    I applied through a recruiter. The process took 4+ weeks. I interviewed at LinkedIn (Mountain View, CA (US)) in December 2015.

    Interview

    Contacted by recruiter via LinkedIn, initial phone screen and then an onsite in Mountain View. The whole process took about a month. Recruiters were very communicative and flexible in scheduling of interviews. Interview consisted of five ~45 min modules ranging from code review, incident management to architecture. I would rank the difficulty as medium (compared to Amazon, Google and Bloomberg). Your success will depend on answering the questions the way interviewers want. Ask a lot of questions to figure out what they want. I did not receive an offer party because of the way my answers were misconstrued as not having particular experience when in fact I did have significant experience in that area. The recruiters gave me some feedback which is not the norm. As far as what to "review" before the interview, I don't have a great answer since the topics touch a large number of DevOps topics

    Interview Questions


  9. Helpful (11)  

    Site Reliability Engineer Interview

    Anonymous Interview Candidate in San Francisco, CA (US)
    Declined Offer
    Positive Experience
    Average Interview

    Application

    I applied through a recruiter. The process took 4 weeks. I interviewed at LinkedIn (San Francisco, CA (US)) in January 2016.

    Interview

    Phone screen with recruiter, basic questions about linux os and networking. Coding screen with actual SRE via collabedit, focused on file system, log parsing, deployment. Invited to interview onsite after coding screen. Very good feedback after every module. I really love the culture at this place, they seem to have things figured out.

    Interview Questions

    • What is the most rewarding problem that you've overcome in your work?   1 Answer

Don't Miss Out On a Job You Love
Upload a CV to easily apply to jobs from anywhere. It's simple to set up.