Interview Question

Site Reliability Engineer Interview

-

LinkedIn

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.

AnswerAdd Tags

Interview Answers

11 Answers

4

FYI, in 2020, this is still relevant.

Anonymous on

4

Relevant in 2021 too.

Anonymous on

2

OP here. Yes, for my interview on site they only asked two

Anonymous on

1

Sure. It's going on almost 3 years ago though, so I'm not sure how useful I will be. caphrim007 at gmail

Anonymous on

0

Hi guys, I have a 2 hr technical round, could you guys give specifics on what to be prepared with? Could I contact any of you personally?

Anonymous on

0

Hey, just saw your post, are you done with your interview?

Anonymous on

0

Hey, I have an upcoming 2 hrs tech interview, can i consult questions you have been asked before?

Anonymous on

0

I have a operations tech interview coming up, can any of u tell me how the questions will be like?

Anonymous on

0

Hey, I have an onsite for SRE and would like to know few things, is it possible to contact you (other than the glassdoor comments ) by any chance?

Anonymous on

0

In each of the questions posed in the interactive interview, they stressed that these are "not your every day errors, nor representative of what you'd run into in your position" They are just curious to see how you go about debugging problems, what tools you use, what resources you go to, what your thinking is like. I tried to keep talking with the interviewer during the whole time so that we never got into one of those "silent room" sorts of interviews where you really start to feel pressured to perform. Keep your mouth running and you'll coast through it. They'll assist as needed in case you are not familiar with tools, but the assistance will be like "so where would you go to find that answer" not "ok here's how you use gdb". You're expected to be self-sufficient in your debug skills.

Anonymous on

0

Did they ask you only two questions during onsite?

Anonymous on

Add Answers or Comments

To comment on this, Sign In or Sign Up.