I applied through a recruiter. I interviewed at LinkedIn
Interview
Pretty much exactly as others described here -- a recruiter pinged me about the position via LinkedIn, had a short call, there was a coding interview, a technical interview, and then a multi-hour interview with different teams that included several parts (code review, system architecture & design, incident response, behavioral meeting with a hiring manager, and hands-on troubleshooting).
Interview questions [1]
Question 1
Systems are bouncing after a new version is deployed and rollback fails -- what do you do, do you/how do you escalate, what do you include in your post-mortem/future mitigation steps?
I applied online. The process took 3 months. I interviewed at LinkedIn (Sunnyvale, CA) in Mar 2020
Interview
Fairly standard interview process for these types of companies. An initial screening, followed by two rounds of phone interviews, and finally an on-site interview. The on-site interview had to be swapped for a virtual interview due to COVID-19.
PROS:
- The coding portions of the interview were all relevant to the job. They were not just toy examples.
- The turnaround time after each interview was extremely quick
- Most people were easy to talk to, which made each interview feel relatively quick
- You set your own pace for the interview rounds. Some of my rounds were over a month apart.
- The recruiters ask for your feedback to them after each round
- The interviews were actually easier than I thought they'd be, except the last round I wasn't given as much guidance on what to study as the first two rounds, so I spent time on useless info.
CONS:
- The interview questions were more like a shotgun blast across a wide range of topics rather than focusing on anything in particular. It went from as low level as how/when shared libraries are loaded when starting an application to as high-level as designing video streaming service.
- Before the final round, you are handed off to a different recruiter
- Based on browsing this site, they seem to use the same questions for each candidate. It makes me feel like they are just a cog in the wheel with no real input to the process. With nothing being tailored to the candidate, it feels like they don't actually care about your strengths and weaknesses outside of their own perceptions.
- The interviewers do not look at your own LinkedIn profile or resume until they are in the process of interviewing you. Therefore their questions against your background are either stock or ad-lib. There is little to suggest most interviewers care about your history or interests.
- They count on their name a little too much to persuade you that its worth taking a hit to your salary and/or quality of living. Especially if you are relocating from a more affordable area. The benefits are not substantially different from my current employer.
- Some disconnect between recruiters and interviewers, which is pretty common. For example, I repeatedly said this would be a change in both domain and roles for me, and I wasn't sure I'd be a good fit, even though I was interested and more than willing to learn. I do have extensive experience other tech domains. I was assured that there would be an extensive training process for the role, and the experience, while important, didn't matter quite as much as the ability and interest to learn the job. The feedback I received after the final interview indicated that experience was in fact one reason I didn't get the job; they wanted someone who could hit the ground running, even though the position was being held open indefinitely and there would be a training period after hire.
- Feedback was almost non-existent after the last interview. Whereas I talked directly with the recruiter after every other round, the last round feedback was left as a voicemail. They did not solicit my feedback.
TIP: Go through the second Google SRE book, the workbook.
Interview questions [11]
Question 1
How do make a variable in a shell script available after the script exits (assume the shell script was sourced)?
You have Gigabytes of data that needs to periodically be synced from a producer to a large number of consumers. How do you approach it? Hint: the data set isn't necessarily entirely new each time it needs to be synced, so only sync the data that has changed.
You take over a new service and discover it has no monitoring. What monitoring would you put in place within the first week to ensure the service is working? Within the first month? How do you monitor failures which are local to a region?
You will be asked to role play a scenario where the number of registrations for a service has dropped to 0 for the past 6 or so hours, setting off an alert. You will have to go through an incident response and elevation. You will be asked to write simple reports that are suitable for giving high-level status to a manager.
You will be shown several architecture diagrams and asked various questions, like "what happens when database X goes down?", or "How to speed up requests from service Y?". Caching plays a big role in almost all responses.
You will be asked to do live troubleshooting of an Apache (httpd) web service. You will not be given many details by the recruiter, so it's easy to study the wrong thing here. It ended up that you need to be familiar with the httpd config file and Aliases. You need to be familiar with how to change Linux filesystem permissions, but you can ignore that you are running on RedHat and you won't need to touch SELinux permissions. Be careful of one problem where they will have two nearly-identical file names, except one has a hypen and the other Unicode dash character. They look very similar in many fonts. Make sure you know how to do a simple GDB backtrace. You will be asked to debug a segfault and work around it (via simple file rename).
You will have to perform a code review of several pieces of code. Focus on logic errors, not stylistic issues. I don't remember all the code samples, but one was about doing file backups, where they manually implemented extension parsing and copied over ".1" files to ".2", etc. without ensuring the order of the copy.
I applied through a recruiter. The process took 2 weeks. I interviewed at LinkedIn in Dec 2019
Interview
First there was a short screen call with the recruiter.
The second phase was a 1 hour coding interview with a number of questions requiring you to write some code. The questions increase in complexity plus I was asked some solution-specific questions. By the end of interview I got to 6th question. In general I had a good experience about it. They use coderpad as a platform. The only thing I would say is a lack of preparation materials compared to other companies (like Facebook or Google). After that the interviewer contacted me next day and scheduled the next interview.
The third interview was a systems-like. There were three questions. As for the previews interview there were not a lot of preparation material. I was given a link to Google's SRE book, but I can't say that it was very useful. Although it helped me to understand what kind of answers they were expecting from me. Another thing is that they do not use anything to write down the questions. It was a pure phone call. So I spent some time trying to figure out the details and what where the questions about. In general that was also a positive experience. The only thing I did not like is that some questions are too vague and you have short time answering it. After the interview there were no follow up from the recruiter.
Interview questions [2]
Question 1
1. Write a sort of FizzBuzz
2. Use rest api to get a JSON and traverse it
3, Parse a log file and process the data
4. Parse the same file in a more advanced way (regex, grouping, etc.)
5. The same file but parse it continuously (the file can be rolled-over, etc.)
Side questions: advantages and disadvantages of a recursion, rewrite a recursion in a non-recursive way, etc. (depends on what do you write)
1. Explain in details what is happening when you type curl https://...
2. Copy a huge set of files over 10000 nodes, keep the files updated, check the consistency
3. How to organize a monitoring in a n-node cluster running a web application