MLH Fellowship Insider: Week 3
--
This summer, I’m doing the Major League Hacking (MLH) Site Reliability Engineering Fellowship which is run in partnership with Meta. The MLH Fellowship is a 12 week technical program where fellows complete an educational curriculum, build open source software, and receive mentorship from professional engineers to learn more about the world of site reliability engineering. I wanted to journal my experience as I go through the program and share it to provide more insights for anyone interested in applying!
Week 3
This week, I learned about scripting as a useful tool for scheduling and automating tedious programs, monitoring the health of systems (e.g., checking memory usage and statuses of processes), creating batch jobs, and manipulating files (e.g., cleaning up temporary files). I got to write scripts in bash and python to output strings, find files, catch errors, fetch online data, parse an Apache log file and output information from it such as the number of IP addresses, and automate the steps for deploying my website from week 1 on the VPS. Bash was a new programming language for me and it was a fun challenge to use it. The syntax is very particular with things such as spacing in if-statement brackets and there are a number of shortcut commands (e.g., “wc -l” for counting lines) that can greatly simplify scripts. It took me time to get familiar with these, and I referenced resources outside of the course to help me complete the scripting exercises and explore bash’s many quirks.
On Thursday, I also did my first mock interview. As part of the fellowship, fellows do three mock interviews to build technical interview skills. The first two are facilitated by MLH and the third is done with a production engineer from Meta. My interview on Thursday was my first time doing a production engineering interview. I was asked two technical questions, an algorithms one and a systems one. The algorithms question was familiar (LeetCode style) but the systems question was a new type of question for me. For it, I was given a scenario where a company has programs that are run manually and have no error handling. I was asked how I would improve this scenario. It was an open-ended question that wanted me to use systems knowledge and experience to determine a practical solution. In my answer, I first explained the different problems with the current scenario (e.g., there was manual work prone to human error and no error handling) and then offered general solution ideas (e.g., use scripting and include error handling). The feedback that I was given on my answer was that it captured the high level ideas, and to improve, I needed to have more specifics (e.g., for the scripts that I wanted to write, what would they do in detail?). My interviewer explained that having more detailed systems knowledge/intuition can be gained from experience. He suggested that I play around with course concepts on my own–for example, I can run multiple processes on my laptop terminal and see what happens when I stop one–so that I can build concrete experience to draw from. I plan to do this and am excited to become more familiar with systems in the coming weeks!
