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

I interviewed with an engineer who asked high-level 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 from that interview, we moved on to another phone interview that was a programming interview. You were allowed to pick a language (I picked Python), and they asked you four questions.

Each question built on the others, and it was a timed interview (60 minutes). The questions were taken straight from CS 101 textbooks: 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 hadn'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 are not what you encounter in the real world. The majority of the coding I do today involves 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 would 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 callback 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 engineers going through what they called "modules." This is where it got interesting.

I took special care to observe their culture. I noticed that the building was very quiet; there wasn't a lot of personal "swag" lying around people's areas. Not a lot of smiling engineers... curious.

The modules included semi-technical one-on-one interviews with an engineer. There were some engineers who 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 you and one engineer who ate at the cafeteria. The engineer was the only one 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, it's so quiet. Creepy quiet. Like none of the engineers talk to each other. My current position has 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 three-ish days: one to get there, one to interview, and one to leave.

There were two live-debugging portions during the interview.

All of the live debugging questions revolved around a simple website that had something broken. The task was 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, raising an error. This could be verified in the Apache web logs.

The second error was also due to a permission problem. However, this time the file was hidden in a subdirectory of the main website. This could only be determined by looking at the Apache configuration file to see that the shtml file was located elsewhere. After that, changing the permissions fixed the issue.

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

It turned out that the Unicode representations for the characters in the filename are printed in the terminal as English ASCII characters. The only way to tell this was happening was to open the file and perform a search for the filename itself to see if it matched. For example, if the correct filename was "challenge1.shtml", searching for that exact string would NOT find the Unicode version.

Once the incorrect filename was found, it was deleted, and the correct filename (in this case "challenge3.shtml") was typed into the file, and the page then worked.

The final question involved a segfault occurring in Apache, resulting in no information being returned to the client. This could be seen in the Apache web logs as well as Chrome DevTools.

The Apache web logs noted that a core file was dumped. This challenge required knowledge of gdb and C programming. Essentially, you needed to run the core dump through gdb:

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

This would output a lot of information. In particular, it mentioned an issue occurring in an Apache module, likely mod_rewrite.

The output also pointed to the C source file for that module, which was conveniently on disk. Opening this file in vi and jumping to the line number mentioned in the gdb output (around line 1861) revealed the problem. If the filename matched "challenge4.shtml", a SIGSEGV was triggered – the smoking gun.

The task was not to fix the final challenge, but to explain what strstr was doing. The error in question looked something like this:

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

The response was to point out that, yes, it was segfaulting when that file was requested.

There was also a paper presented with a number of Nagios alerts. The task was to rate them in the order they should be approached.

For example, one alert was for a production host being 100% offline. Another was an environment alert about an entire rack overheating. Another was the tablet VIP being down, and another was a high load average for the main website.

There were also several QPS (queries per second) related alerts, including security-related alerts like XSS QPS and failed logins QPS.