Summer Internship with Facebook in USA – the seven lessons learnt

 About Author: Sujeet Gholap is a final year B.Tech student in the Computer Science and Engineering branch at IIT Madras. He interned with Facebook in the Software Engineering field in Unites States of America. Read on to find what all he discovered during his internship stay.

Compared to many other tech companies, Facebook’s procedure for offering full-time jobs to interns is quite different. There are no additional interviews, no extra tests to be written and no puzzles to solve. You are solely judged by your performance during the internship on your project.(note the emphasis, I will come back to it later)

This is the story of a boy with ego bigger than the universe and how it got severely hurt, with ambitions taller than the Everest and how they were shattered. Story of a certain Mr. Sujeet Gholap and the events and circumstances which led to eventual disappointment and disillusionment.

In the beginning of my last week of Facebook, my manager Chris scheduled a meeting with me. He started off with “You certainly have what it takes to be a good engineer.” That one sentence gave me enough indication of what course the conversation was heading to. Eventually the words came ” but unfortunately we won’t be able to extend an offer to you.” He kept asking me whether I have got anything to say, any questions to ask and all I kept asking was the specific reasons behind the decision. As expected, stuff like “it’s not about you, understand that you are pitted against world’s best programmers here…” was told to me. With a lump in throat and voice already choking, I told him that I didn’t want any more information and I haven’t got anything else to talk about. I left.

The next few paragraphs can be skipped without losing much context as they are more of a sentimental nature than of an informative one.

Emotional fallout:

You know what hurts more than rejection? Not knowing the ‘why’! I came straight back home and drafted an elaborate mail asking for the details regarding the decision. The mail had a list of straightforward questions, which, if answered, would help a lot clearing the mystery. I pleaded him to answer each one to as great an extent as possible. I really don’t know what people have got against having a honest, open and in depth conversation. Instead of addressing any particular points, he just gave a vague and overall answer. So frustrating! Could he not read the mail and address particular points? How difficult can it be after all? It was only me trying to have a conversation and it made me feel like he was trying to shrug me off. Why did he have to be so vague?

 During the course of the internship, I had grown to like Facebook as a company with a mission, a vision (and solid monetization :P). I almost became a Facebook evangelist. I suggested to friends that Gmail is thing of past, let’s get on to Facebook messages. I enthusiastically welcomed friends who just joined Facebook. I was inspired by the grand connected-open-honest world picture Mark created. I was motivated by the ‘move fast, keep shipping’  motto deep ingrained in the very fabric of the company. I took pride in the campus which boasts about itself as ‘the hacker company’. Having a sense of belonging, I felt attached to the codebase and the site as such. On the face of all this, it was a huge sense of disappointment and worthlessness which filled my mind when the bad news hit me like a tsunami. The company which I adored so much, did not find me worth it! I wasn’t good enough! I wondered whether that is how a lovelorn, heartbroken person feels…

Earlier in the afternoon, I had ordered some Facebook tee shirts, buttons, stickers and a hoodie from the employee-only Facebook goodies store. But in the night, I suddenly found myself alienated from Facebook, I could no longer identify myself with Facebook, a sesse of betrayal and bitterness grew over me and I canceled the order, despite my friend and roommate Arijit telling me again and again to calm down and giving it a thought before doing anything. Now, whenever I see Arijit, Gunaa and Nitin sporting the trademark hoodie, I regret the impulsive cancellation of my order, for which I did not even have to pay!

Ironically what helped me to get my mind off this was to code for the same company, which I despised just the night before! Back to work next day, hands on keyboard and eyes on emacs, the sense of loss just got numbed down by several orders of magnitude! I was now ready to talk about it pretty coolly and objectively without chocking. And that’s what I did in a meeting with Chris the following day. I just decided to ask him everything again and not give up until he told me something substantial, something which will help me improve, help me avoid such failures in future.

After talking to him, many things became clear to me. I realized many of my mistakes and so did he!

So, having already spent around 850 words on nothing substantial, let me present to you, an account of my internship, the project I worked on, where I erred, what I should have done differently and most importantly, what to do to be worthy of Facebook.

I was in the feed team, which manages the newsfeed, the ticker and a bunch of other things. My project was a two part one. First part was to build a feature, which both Chris and I thought was really cool, useful and something which we wished for personally. I will provide more details as soon as it is launched. The second part was to build a recommendation service for the above feature. Part-I excited me a lot because I was sure that if implemented, there are really high chances of it actually being shipped  and becoming quite a big hit too! The second part, on the other hand, had some technical limitations like the back-end code still being in experimental stage. Compound that with the fact that it wasn’t really on the priority list anytime soon to make that back-end code production ready. That will lead to the recommendation service ending up just being an internal employee-only feature for god-knows-how-much time.

Lesson one: Don’t think too smart of yourself. It is always better to ask a peer how a particular part of code works at a higher level than to try to figure out on your own.

You will, surely be able to figure out, and no doubt it gives a certain joy of accomplishment but it is not worth the time spent. Not, especially at a company with a ‘move fast’ culture. I should have understood and followed this first time around when Chris told me; but it took me several indications to finally let go of ego and pester colleagues with even the silliest of doubts if I get stuck on something for more than ten minutes.

Lesson two:  When they tell you to submit your code in small patches. Each one with a small but well defined goal, they really do mean it!

In order to build that feature, I needed to change some underlying infrastructural code. Having done that, I thought “It is now just a few more lines of code and I will be able to get a basic skeletal version of the feature up and running.” I went ahead and did that. Again, I thought “I got this working in newsfeed, a slight modification, and I can get it working on timeline as well!” Well, a wrong chain of thought Mr. Sujeet! So finally I ended up submitting a patch which actually should have been 3 separate patches. One built on top of other, taking feedback on each one before going ahead with the next.

Lesson three: Be proactive and assertive. Don’t take your mentor’s word as something sacrosanct, however small, there is a possibility of him saying / suggesting something wrong.

After wasting time on breaking down the big patch etc, Chris suggested some improvements and additional small small features before we could get the patch into the codebase, I kept on adding them to the same patch and he kept on suggesting. I should have made him realize that we are bloating the patch more and more, precisely the thing which we did not want initially! End result? A lot of time into the project and still no code submitted into the codebase.

Lesson four: It’s your project. You should find out as much information about it as possible. Talk to different teams, different interns.

Almost midway through the internship, we found out that an intern, Andrew, from the photos team was working on an almost identical project. (The first half of my project). Ideally, either Andrew or I should have surveyed the company and made sure that we won’t be just duplicating the efforts. Looking at the approach the photos team took and that taken by my team, finally we decided to scrap whatever I did till then and let Andrew go ahead. I was to hop onto the next part of my project.

As I mentioned earlier, this was a part I wasn’t optimistic about, wasn’t passionate about.

Lesson five: Realize that there is no point in working on something which you don’t care much about, be honest, tell it upfront and ask for something else.

Not that I did not try, it was just that I should have been more direct, upfront and confident. I started giving Chris subtle indications about how I was more excited about the first part, how I don’t like the fact that the second part would just be experimental for a long time and how I find things-not-readily-shippable boring. I should have just said, “please take me off this project and let’s work on some other more interesting project for the rest half of my internship.”

Lesson six: Your project is your project. That’s all that matters. Anything else you do, does not count at all. I learnt this really really hard way.

After I started on the second half of my project, I started to ask Chris for more and more tasks and bugfixes outside of my project. Throughout my internship, I was very passionate about making Facebook into a better site. I kept on filing bug reports, actively pursuing them and offering help wherever I could.

Once a friend of mine, Devesh, who was interning at Google, asked me about how he could unsubscribe from a comment thread for a photo album on Facebook. Apparently he was very irritated with all the comment notifications he was getting. All along, till then, I kept on uploading photos to a single public album on Facebook which soon got bloated. Having commented on it once, Devesh started getting mails for each new comment made on the album. Intuitively, for the batches of photos I uploaded later, he should not be getting notifications for comments because his comment was about the initial bunch of photos uploaded. There was no obvious way of ‘unsubscribing’ from it. This gave me two things to work on :

1. Implement ‘unsubscribe’ option for album stories.
2. Separate my Facebook internship photos album into smaller, more specific ones.

Although I wasn’t on the photos team, I implemented the first one and yey! It’s there on the site now! Like a fool, I manually did the second one. While doing that I realized how cumbersome it is to transfer a photo between albums. It takes 5 clicks per photo! After wasting hours transferring photos manually, I finally got irritated enough that I decided to fix the annoyance. Why not implement drag and drop? Drag photo from one album and drop it onto another to transfer! So, during one of the hackathons, I hacked up a prototype (hacky, dirty, but fully functional code) for the same. I still feel thrilled and touched when I look back at the applause and cheers I received after presenting my hack to an overflowing hall full of brilliant and innovative minds in tech (I mean other Facebook engineers and interns :P).

Once Saheel, another friend of mine, had brought to my notice one link which I had shared. It was not re-sharable. I verified it and filed a bug report. But it turned out that the conditions to reproduce the bug were pretty rare. Also the way I had shared the link, was a very minor use case. So, the bug was put on the ‘wishlist’ (it is the lowest priority a bug can get.) Desperately wanting to see the problem fixed, I took it upon myself to fix it. After spending two days with code I had never seen before in a language not so familiar, I finally gave up realizing that it was becoming too much of a time sink.

One day, on my Facebook timeline, I saw that it read ‘worked at Facebook’ instead of ‘works at Facebook’. There, I had spotted another bug. I went ahead, took initiative, worked with the timeline team and fixed it.

These and many more such detours kept on making me disinterested in whatever remained of my project. While praising and encouraging me for my enthusiasm and the if-no-one-wants-to-fix-it-I-will-because-I-care-for-it attitude,  Chris kept on giving me subtle and sometimes not so subtle indications that I was falling behind on my project. Partly due to the praise and encouragement and partly due to the sheer joy I derived out of it, I kept on working on these side projects and tasks, not devoting enough time to my project. Not knowing that all these others things don’t count towards my evaluation, I comforted myself thinking my lack of interested and initiative in my project would somehow magically be compensated my these other tasks. Oh so so wrong was I! As Chris told me later “spending 10% of your time on these is awesomeness, spending 80% is foolishness”

Lesson seven: Realize that all employees are equal and don’t let seniority and experience come in your way when it comes to voicing our opinion loud and clear.

To build the recommendation service, I needed to use a framework which Chris had no experience with. When I built the service, I was on my own to get it reviewed and approved by the services team which was in-charge of the underlying framework. Chris had made it clear that this was just in prototype stage and  the priority was to get a basic, rudimentary service up and running as soon as possible. I submitted the patch to Fan and Eric, the dynamic duo on the services team. Not having a clear idea of why I want the service to be approved, they kept on suggesting changes about performance, about the backend which we were using and a lot of other things which Chris and I did not care about. Here, my timidity and shyness got me. I got confused thinking “these guys know the framework better than Chris, so maybe I should follow what they are saying. After all, they are much more experienced.” At the same time, instead of being strong and justifying the apparent holes in the code, I just kept waiting for Chris to intervene and explain to them how those changes were irrelevant and my patch should not be blocked because of those. Which, sadly, never happened. And when I mustered courage and decided to charge ahead with what I thought was right, it was already too late and an impression of me as someone who lacks effective communication skills, someone who can not define and aggressively defend his own goals was formed!

On the way, I learnt a funny fact too! Just because some code already exists in the code base, it does not mean it is ‘clean and neat’. (don’t want to make this into the 8th lesson because I like the all-powerful number 7 :P) In one of my tasks, I heavily borrowed code from some internal tools, and lo behold! My reviewer found a dozen of nits in it! What’s more, all the nits were in copy-pasted code, not the one which I wrote. In the hindsight, I think I should have at least brought to their notice the fact that the code was just one piece ‘put together’ by me, not one written by me. Again, too bad, bad impression was already made.

As I learnt later from various people, some quantitative metrics used for evaluation are :

• Number of  times changes are requested by the reviewer on your patch before it gets accepted. (diff churn)
• How promptly the requested changes are made and patch resubmitted.
• How independent and clear you are about the coding policy and your own goals.

Having done poorly on almost all the above fronts, having had misplaced initiative, efforts, enthusiasm, time, and resources, it is now pretty clear to me and hardly a surprise that an offer was not made to me. It was really nice of Chris to put up with my pestering and finally giving me the feedback I needed. Hope this helps someone, because such a thing would surely have helped me :)