TL;DR I worked with Facebook, London as Production Engineering Intern in Summer’17. This write up is to share information about the procedure with current and future aspirants.


I have received a lot of queries in recent days about this role. So I finally decided to pen down the information here instead of repeatedly writing to multiple chats. ?

Randomly picked Facebook London Office Image, for those who get bore reading text-only articles.

What is Production Engineering?

The buzzword in the CS community nowadays is to get Software Engineering Internship. While other roles generally don’t catch everyones’ eyes. Some of these roles (from FB context) are Production Engineering and Data Engineering Internships.

Let’s talk about Production Engineering role and see what Facebook’s career page has to say about it:

Production Engineers at Facebook are hybrid software/systems engineers who ensure that Facebook’s services run smoothly and have the capacity for future growth.

You might be confused and thinking of it as a regular Site Reliability Engineer (SRE) role, but it’s much more than it. I can recollect a good comparison by Shopify over the same here. Regarding knowledge set, you are supposed to know how to code, fundamentals of networks, UNIX, deployment and preferably other infrastructure services like load balancing, caching, CDNs etc. If you read RFCs like you eat food, that is a plus. ?

What is different about the’process?

The information about Software Engineering internships and their procedure are pretty much same in all of the organisations and known to people. However, the Production Engineering Intern interview process isn’t to judge based on how well you do competitive programming or retain algorithms in mind. BUT to assess you on your knowledge beyond coding to Linux internals and thinking process in this direction. NOTE: This is much different than Google SRE Internship interview process which is kinda similar to Google SE interviews.

The interview process consists of the following three rounds:

  1. MCQs on your day to day Linux knowledge
  2. Coding/Programming Round
  3. Linux/SysAdmin Round

What all you need to’know?

Depends on how lucky you are. But as per my understanding of the process following topics are good to know before hitting the interview process. (obviously not just the example question listed, but in as depth as possible)

  1. Linux File Systems / Structure, etc What is /proc directory? Difference between soft/hard links?
  2. System Calls Which system calls can list all files in current directory?
  3. Signals in Linux Which signals can be catch? What is signal number 9?
  4. OSI Layer Difference between switch and router?
  5. Application Layer Concepts (DNS, HTTP/HTTPS, Ports, etc) How a URL resolve? What is 22 generally used for?
  6. Fancy Stuff’ Sticky Bit? Which files have that set?

For some of networking related stuff, I had prepared quick cheat sheet previous year and can be accessed here.

#1 MCQs’Round

This round consists of approximately 20 Linux MCQs, which is taken either by some portal or telephonically by the recruiter. Most of the questions should take a few seconds each. It serves as a quick check on above topics as well as to know your familiarity with Linux commands.

#2 Coding’Round

This round is different then programming rounds you would have heard from people or taken yourself. The focus isn’t on how well you know competitive programming and can solve a graph or DP problem. BUT to check if you can write fairly sophisticated code involving pipes, threading, etc.

Once you have written the code, you can expect open-ended questions on how to optimise it either for file IO, pipes, memory, network throttling and other such systems-related stuff. And not just, improving complexity from O(n’) to O(nlogn)?’?although better to write as optimised you can. ?

You should take care of linux system limits, and other stuff while writing your code. Say, you write a code to serve each client by fork(), do you think you can serve 1M people like this? What to do? Limit number of fork()?

Good projects to code by which you can learn might be?’?these examples are probably harder then what you will get in interview question:

#3 SysAdmin’Round

This round is the best thing about the whole process. You are typically not expected to write any code in this round. BUT are given an open-ended problem to solve. You need to talk aloud your strategy, debugging ideas, solutions and so on.

One random example will be: You are not able to serve files present in /var/www/htmlvia httpdprocess. What mistakes can you think of? How will you solve them?

You can think starting from file permissions, checking httpd config, iptables rules, and so on. There is no right answer but surely better answers when different candidates are compared.

How to’prepare?

Well! I would like not to answer this. Google is your friend. ?

Rest, this is a good question paper which I along with fellow IIIT-H sysadmins once prepared. You are welcome to skim through it, to test your knowledge.’’

Disclaimer: The sample questions shared above in blog post aren’t one which were asked from me. But are fictionally generated and closer to original, in terms of difficulty and knowledge set required?’?probably easier than actual ones ?.

All the best in applying, getting interviews and unlocking internship for upcoming summer!

[xpost, original posted on Medium by me here]