Skip to main content

My Facebook interview experience, from start to rejection

Over the last couple of months I had the opportunity to interview for one of the most revered companies for any software developer in the world which is Facebook as you have guessed from the title.

It was a really unique experience and surprisingly I learned a lot about myself too. It turns out that after all these years building small and maybe some smaller medium sized applications, I have become quite passionate about those kinds of applications. Building these kind of applications allow me to have fun using things that I love the most: object oriented programming, designing functionalities and splitting them into components and using various interesting programming principles or software design principles.

It turns out I am very passionate about algorithmic stuff and high performance stuff. I mean I do enjoy them from time to time, but they don't really seem that creative to me. With object oriented programming and various software design principles, you can come up with any crazy and unique ideas that you can think of. Which turns out is quite fun for me.

I noticed these during the interviews. I was a bit disappointed because I never got a chance to play with these things during the interviews. Honestly I like more how to name and organized your code into various components with interesting ways of interacting between them than writing standard procedural code.

When you build very large systems like the ones at Facebook you are not concerned with the things I mentioned above as much. At that scale, performance counts a lot. That's why they ask algorithmic questions that check if you can come up with fast solutions to problems. Coming up with those solutions require this algorithmic thinking.

But also they require to understand how something scales regarding the input size. It's why they ask the notorious Big O notation. It's a test to see if you can determine how well something scales, to identity bottlenecks and the speed of operations related to the size of the input. The same principles and mentality used to figure out the Big O solution can be also used for compute how well a service or functionality can scale when it is used by thousands of users.

Now on to the interview parts. I can't say some specific things about the interview because I signed an NDA.

It started with an email from a recruiter inviting me for an "informal" talk about some available positions with Facebook. Honestly, it was a bit of an interview too disguised as an informal talk. I got some questions about common algorithms and the Big O complexity. I got all the questions right. I liked the fact that the interviewer was straight to the point and asked me my salary expectations from the beginning. He wanted to make sure so that he doesn't waste me and his time. Usually a lot of recruiters avoid "hard" talks like this but he was serious about this. I think this was really professional on his behalf.

Also he seemed to know quite a bit of programming himself too. I wouldn't be surprised if eventually he started a proper programming job. He really knew how to answer some of my questions just like a programmer would and not someone who just memorized everything. He actually could think in programming terms. I was also impressed by how professional structured and organized everything was. Everything seemed much more formal from the very beginning. The interviewer actually had a calendar application for setting appointments probably developed by Facebook. I made some mistakes here. The interviewer actually suggested using appointments for settings up calls. But I didn't use that which caused us to miss some calls. Back here in Romania everything is a lot more informal. The interviewing culture is completely different.

After that I got to do a phone interview. During this interview I was really relaxed. I got something that you can find for sure on the internet or at least something similar. I actually did pretty well on this one. It might seem like the coding problem to solve is simple but the interviewer is also interested in how you name you variables, how you structure your code using methods, functions and so on. Maybe even if you got a working program if it's not written properly you might fail the phone interview.  I think the proper approach to those kind of coding problems is to write down as many possible relevant examples and then see what they have in common. And then trying naively try to produce the desired results from those examples.

I really liked the guy which interviewed me for the phone interview. I studied his blog a bit and it seemed a lot like mine.

Now that I think about it, I think what caught the recruiters and the people's attention from Facebook was some of the things I wrote on this blog. I am not too sure about this, but I wrote some time ago about an open source project that I worked on from a series of related open source projects. I also wrote about the people that I meet there, some of whom worked at very prestigious companies. I think this is what sparked their interest in me. They had some kind of reference and stamp of approval from that experience. Also I wrote about a program, Blender 3D which some of the people working there may have been familiar.

After that I had to go to the onsite interviews. But getting there was quite a roller coaster of a ride. I made again some mistakes. I wasn't really clear when confirming some things and the people there misunderstood me. I should have been really clear about everything and I should have double or triple read everything. Even though I sent an email confirming the flight choices I wasn't 100% clear about them. Because of that I never properly confirmed my flights. I should have insisted a bit more. But fortunately I got decent flights two days before the interviews. I don't know if it was a test or something but the first series of flights was almost impossible. I mean I had one hour to swap airplanes in Heathrow, in one of the biggest and the most circulated airports in the world. I would have never managed to reach the other flight.

Fortunately I noticed this and requested proper flights. Which I got. I also got to fill in a lot of forms to complete the entire process. Everything is very well thought of and streamlined.

After that, I finally got to fly to the onsite interviews. And I got to stay at a five star hotel. I never stayed in a 5 star hotel in my life. It was really luxurious. Facebook sure knows how to treat it's candidates. I even had heated floor in the bathroom fully decorated with marble. But I got to sleep on the same incredibly thick beds with very thick mattresses which was actually a bad thing. I am used to sleeping in crappy beds. I actually sleep better in crappy, small, solid and low level beds.

Now on to the onsite interviews part. I can't tell too many details but they were very well thought of. I like the fact that they didn't just ask the same algorithmic questions. They wanted to know how you think, your thought process and if you can think together with them as a team I guess. They also asked other interesting things related to the positions I was interviewing for. There were quite a few interviews.

The building was pretty amazing. Better furnished than all the homes that I have lived so far. They had mini kitchens 100 meters away at most from any computer so that people can get some snacks or something light to eat really fast. They had a big interior atrium with trees and plants. The building had a unique shape actually designed by a famous architect which designed all the Facebook buildings.

I noticed that one of the interviewers was really good at getting people excited to hang along him and listen to him. This must have been one the specific skills that was required for his job at Facebook. And most of the interviewers could dig information out of you pretty well. If you could not explain some things clearly or didn't say some things with enough details, they could fill in the blanks pretty well with a been there, seen that attitude. You could tell that they have been through such situations a lot and they were very familiar with them. Nothing really surprised them. I also noticed that they could dig deeper than the usual interviewers with whom I interacted with. When I explained some things to them, they noticed what the actual underlying problem really was instead of just doing a superficial analysis that I see all too often. And most of them seemed really down to earth people. They didn't really brag about anything. Except maybe the first interviewer. That kind of turned me off a bit.

Honestly, the onsite interviews weren't that bad or horror how some people seem to think of. The questions were actually some fundamental things used pretty often but no one actually remembers how they actually work. I should have paid more attention to them. When I prepared for the interviews I spent just too much time on some obscure details instead of learning all the major important things. I skipped some things. I remember them during the interviews but I wasted a bit too much time coming up with them. Still I was a bit disappointed that they didn't care about how I named my variables. They had really good names lol. I think they should pay more attention to this. With the standard whiteboard interviews, people aren't interested if you name a variable "i" or some proper name like "beginningOfSequence".

And I also made another mistake when I prepared for the interviews. I didn't foresaw the fact that I would need to explain the things I am doing to the interviewer. That also costs some time and because of that I didn't alocate my time properly during the interviews. Honestly, looking back I should have done at least 3-4 mock interviews with someone more experienced. I would have noticed this. I should have practiced explaining things more. I think this is my biggest flaw. I am not good enough at explaining things. But recently I kind of figured out how to improve this.

Another thing was that I was coming from a different background than the rest of the guys there. There was some knowledge mismatch and gap between me and them. They use other technologies, programming languages and jargon in general. Actually it's a completely different culture from what I am used too. I mostly program in C# while they develop in hack, javascript and so on.

I was also too nervous during the onsite interviews. I was tired I think. I had some really stressful days before that. I shouldn't have stressed so much about some stupid crap before the interviews. Guys, prioritize your life and what you want. Don't be like me.

In the end I didn't pass the interviews. Honestly I was expecting this around 90%. I don't really have too much experience interviewing. And I was interviewing for the mother of all software companies. It's not really a surprise here. Also I feel much more comfortable at home. Maybe I should have chosen to do the interviews through video conference from my home. I would have done a lot more better. But it was a really nice experience.

Compared to interviews back here in Romania, everything is a lot more formal, structured and streamlined. Back here in Romania I had an interview in a pub lol. And each interviewer could take the interview in any direction they wanted. On the other hand, the Facebook interview were much more specialized and strict. Back there in Romania they place a lot of accent on what technologies you know whereas the guys at Facebook were interested in your thinking ability too. They use very customized stuff anyway which aren't that used at normal companies so no use for them to look for people which know those things. Everything at these big companies is heavily customized to their needs. And most roles are much more specialized than back here in Romania. In Romania you get to do a little bit of everything and more varied. But you won't get into depth with them. Well at companies such as Facebook you will probably do less things but really push everything to the edge. So get used to be in a very specialized role. They must be really good at splitting their software into so small and refined pieces.

Still one thing is bugging me. Usually when I have an interview I kind of know from the first 15 minutes or so if I will pass the interview, if I will want to work there on the long run or if I will get along with the people there. The thing when I have an interview I need to have a sense of being home like I belong in that place. I didn't quite get this feeling when I was there. I felt kind of out-of-place for some reason. Usually this can be caused by a lot of things but in general I think it's more related to the actual connection that I have with the people there. Or lack of connection. That is still an issue too. It is influenced by everything including how well you get with the interviewer and how well you really understand each other including both technical and non-technical things. Usually when I have a really good interview then I usually get lost in the discussion about the problem at hand and forget I am in an interview. That's the biggest sign something is going well. I never really got that absorbed into the discussion. I guess I am not that passionate about some of the things people mentioned there. I never really got to show my edge or really get passionate about anything. I probably have skills or abilities that they don't really need there. This is the feeling that I got. I like how software is made back here in Romania. I think I would probably fit in a small or medium sized company with at most 100 people with a chill atmosphere and probably a product company that owns their own software.

I don't really have any regrets. I mean I am an adult person, I shouldn't get upset and fuss over nothing. I noticed in other people's posts and experiences that they get so upset, disappointed and really personal a bit like some spoiled brats. Not me, I am pretty calm honestly and content in the results. Maybe I wasn't quite a good fit for them. The things I am interested in are a bit different right now. But who knows, maybe some time in the future I might become passionate and interested in more things that they are looking for.

Until then, I with them good luck, and I thank them for the experience. It was really nice, they were nice and really smart people and I can't blame them for anything. It's my responsibility for this 100%.

Comments

Post a Comment

Popular posts from this blog

Some software development common sense ideas

 I haven't really written here in a long time so it's time to write some new things. These are just some random common sense things that seemed to short to write about individually but seem really interesting and useful to me or other people 1. There is nothing fixed in software development, all things vary by circumstances and time Remember the documentation that didn't seem that important when you started the project, well after a couple of years one the application has grown and become really complicated, no one actually knows everything about the application anymore. So now you really need that documentation. What happens if you suddenly need much more people to develop the application because of some explosive growth? Without documentation, new developers will just look at the application like they look at a painting. This actually happened to me. Maybe in the beginning of a project, a technology really helped you a lot but as the project grew, it started making things

My thoughts as an experienced developer in this field.

To be honest, I would have never guessed that      I would end up saying these these things, especially jn the beginning of my career. As you become more experienced, you kind of get to see everything and you become less impressed by new things. Honestly there is some sort of repetitiveness in this field and we kind of like to reinvent the wheel quite often, because well, we become a bit too easily bored. Take for example how the web looks now, a lot of it has been borrowed from other places, mostly desktop development, especially the parts about making custom reusable components.  Or from older frameworks, like state management in the UI which actually was first properly implemented in Asp .Net Webforms, as far as I know, something like 20 years ago, where you used to have the dreaded view state.  But most likely something similar existed before that too. I was not that surprised when React adopted initially this idea. Or even less surprised when hooks where introduced that seemed a b

Some things which are often blindly applied and followed by developers which are not always good

This is probably one of the most controversial things that I have written so far but I am just tired of hearing about these things and discussing these things. Other developers that I know share part of my feelings. I would rather hear more about how people built things, overcame challenges or what new interesting ideas and concepts they implemented. Those things are really interesting and innovative, not hearing about the same theoretical things over and over again. I can just read and learn those things from 100 sources on the internet. Firstly, one of the most discussed and promoted things is agile/scrum development. I think I have been through 5-8 workshops about agile development methodology. And each time, some things differed. There is no 100% standard approach to this. Everyone uses their own version of this development methodology and seem to argue a lot that their approach is right and everyone else is doing it wrong. You go to an interview, this will be one of the first 10 t