It's funny how people are so interested in the development practices of Facebook as if that's how it should be done.
It's a bit like the halo effect, where if the company does one thing right (get lucky and dominate the market by being first), then everything else they do must be right too.
If you ask me, they could take what ever approach to development, hiring, training and firing they like and they'd just be as successful.
But, none of that stuff is what made them successful. Therefore, I'm actually not that interested.
> This week marks the beginning of my 4th year at Facebook. My
> experience here has been incredibly transformative: I joined
> Facebook after dropping out of college having never faced the
> challenges that I've seen during my time here. At this point, I've
> worked through these challenges for longer than 4/5 of the people at
> the company and thought I would share some of my insights in hopes
> that other engineers who are joining might find it useful.
This marks the beginning of my 17th week of unemployment* after being
fired from Facebook after about a half a year working there. My
experience being fired has been incredibly transformative. I worked
through challenges for longer than 1/10 of the people at the company
and thought I'd write this alternative viewpoint in hopes that other
engineers who might want to join Facebook find it useful.
In what follows, I will attempt to only share true stories without any
interjection of my own opinion. Though, being fired -- after being
enticed with a high salary, accepting a large bonus to move to Silicon
Valley, and taking out a lease that you can't afford without a high
paying job -- does cause a fair bit of emotional dismay.
As a little backstory, I was asked to interview for Facebook by one of
their recruiters. I was already employed, but thought it was time to
grow professionally. I interviewed with Facebook, and did very well,
and was quickly offered a cool salary. Less than a week after
relocating interstate to my new home, I started work. After doldrums
and threats, which I will discuss briefly below, I was let go, without
notice, stuck with a six-month lease in location with a hyper-inflated
real estate economy.
> As an engineer, your job is to build things that solve
> problems. When you first join the company, you're assigned small
> tasks and you solve them.
As an employee, your job is to make the company money.
You are given a variety of disparate tasks to solve, with the
ultimate goal that after six weeks, you find the area and team you
want to join.
But don't get me wrong, you actually are pushed in the direction
Facebook would prefer you to go. There are high priority teams and low
priority teams. Unless you have a good reason, you better choose a
high pri team.
> As you grow professionally, the domain of these tasks becomes
> larger. It is a mistake to constrain the increase in domain to
> larger or more frequent diffs. Code is a tool you have for solving
> problems.
Weird. Aside from being juggled around as an employee, being given
work on front-end, back-end, low-level, and high-level tasks, I was
lectured on Facebook's rules of the road: Generate lots of diffs! Bang
out code fast! But make sure it's right first time! As I'll discuss
next, you also should minimize your interactions with engineers during
the code review process. Facebook actually prefers to treat it as a
"Code Acceptance (otherwise you're failing)" process.
> If you were gardening, you might plant flowers or pull
> weeds. Increasing your scope does not mean planting more flowers or
> pulling more weeds (though you should expect to be faster and more
> proficient at that as you become more experienced). What it really
> means is looking up from the ground at the garden in its entirety,
> considering how your section fits in, and eventually helping to
> decide the whole garden's plan.
A nice idea.
The way my manager personally handled personal growth of his
subordinates is by threatening them. Well, me, at least. If I didn't
complete some odd tasks he assigned me by a certain date, I'd be sure
not to have a place at Facebook after that date. This occurred on more
than one occasion.
Despite meeting these demands, it was fruitless, and I was told during
a meeting that my bags were packed and waiting for me in the lobby,
and to hand over my badge and laptop immediately.
> In order to do this effectively you need to have agency. Agency is
> the capacity for a person to act in the world. As a hacker, having
> agency over your world is critical to fully explore the boundaries
> of problems and find how to best leverage your solutions. I'm
> referring both to the code that you write and to the interactions
> you have within the company.
I was given these sorts of platitudes often.
I loved exploring code. But I was told to just hone in on the issue I
was supposed to solve, not worry about the bigger picture, and to just
solve the problem. In theory, the above sounds nice, but in practice,
I was told the opposite.
Regarding interactions with other people in the company: I was
ultimately told by my manager that I should reduce interactions with
other developers, and eventually, I was told I was not allowed to
speak to other developers at all, apparently to "gauge my
performance." After several weeks of complying with this rule, the
relationships I developed thus far in the company weakened and
essentially evaporated.
> In the code base that you live in, you quickly develop an
> understanding of how the components fit together. Use this
> knowledge: instead of only fixing a bug you're assigned, consider
> how you can prevent that class of bug from ever happening
> again. Instead of implementing a new feature, consider how you can
> create a common abstraction between the new and old ones and share
> 80% of the code. This might take more effort now but gives vastly
> greater results in the long run.
This is a very beneficial thing to do, but it led to ugly code
reviews. I was given a task, and solved it to satisfaction (code was
written cleanly, tests passed, etc.) but was told, in review, that the
code was not satisfactory, because it did not clean up code completely
unrelated to the task -- even if such clean up actually didn't solve
any old or new problems.
I was severely penalized for this.
> At a higher level, take ownership over the entire company. Don't let
> your coworkers be less than the best that they can be. Understand
> the trade-offs being made and the factors that led to them;
> understand temporary solutions and the priorities that necessitate
> them, but don't accept a decision that you feel is wrong without
> raising the issue and getting a better understanding. This is your
> company (your garden) and if you let people pull in the wrong
> direction the entire plan will fall into disarray. Make sure that
> you encourage changes and that you're confident that the changes
> happening are the right ones.
This sounds entirely ideal, but when someone new goes up against
someone who has been in the company for a while, the new guy is the
one who is looked down upon and usually disagreed with, with the
reason that the guy with tenure surely knows what he is talking about.
The part left unsaid is that there is no process for appeal. If you
disagree with another developer, and your manager ultimately disagrees
with you, tough luck.
I did not see democracy and debate. I saw tenure and social capital
deciding issues by default.
> It's easy to fall into the mindset that you don't know everything,
> everyone around you is smarter and more experienced, and that if you
> say something incorrect you'll be judged by your peers. This isn't the
> case. When you have an idea, share it with your team, even if you
> aren't confident it's the right idea. Wrong ideas are often stepping
> stones to right ideas, both because they help define the real
> boundaries of the problem that you're facing and because you can
> iterate on a wrong idea to reach a right one.
Saying incorrect things, in my experience, actually does have
repercussions. During "bootcamp" at Facebook, you'll go through
essentially a second set of interviews with managers and team
members. If you ask the wrong things, or make seemingly incorrect
statements, you will be judged, and as a result, they will not want
you on their team.
Aside from the questions you ask and the interest you display, the
number of questions you ask also is a form of penalty. I was
informally rejected from a team because I was told I asked too many
questions. Basically, since I asked too many questions, I allegedly
did not have the competence to solve problems that team faced on my
own. Even though it was the team I dreamed of being on, and the one I
could make the most impact on, I was told by my manager that my
reputation was irreparably befouled. Maybe if I tried again in a year.
As another anecdote, I was judged negatively for sharing my ideas
without confidence (I'm the new guy, I don't want to be
presumptuous!), and being indirect with criticism. Instead of telling
another team member that he was wrong, I shared an experiment and
results to demonstrate so, in order to minimize argumentation.
Even though I ended up being right about my assessments of the problem
at hand, I was actually told that I should have been more assertive
because of this, and my overall performance was deemed poor.
> It isn't immediately obvious how important it is to meet and
> maintain relationships with people at the company who are outside of
> your team. Find a random person with whom you haven't worked in
> months and have a quick chat with them. It can provide a fresh
> insight into problems you're facing and may even give a solution
> that another team already has that you can use. FYI groups do a good
> job of giving you a broad overview of the company, but talking to a
> ground-level engineer from a different part of the code can yield
> new ideas, new solutions, and new opportunities to combine forces.
True enough. Though, "joining forces" usually means "do something for
the company on your own time, and if the idea is good enough during a
hackathon -- also on your own time -- then it might lead to a new
opportunity". You can shoot the shit with other developers, but
there's no 20% time to take anything to the next level.
> I'm only just starting to learn some of these lessons. I hope this
> note helps to inspire you to step up, take ownership, and lead your
> team in the right direction. Enjoy your years at Facebook; I know I
> have.
Good.
Overall, I did not enjoy my time at Facebook, and I was reminded of
the value in having a good, experienced manager, and the futility of
trying to retain professional dignity in the face of an incompetent
one. It was something that could have been repaired, but there was no
avenue to do so.
My tale also underlines the way at-will employment can be exploited as
"endless probation". Food for thought for anyone seriously trying to
build a tech career.
* Actually, I am glad to say that I am now happily employed.
I can confirm the same experience as a non-engineer.
I worked in a group that was not engineering, and had the same schizophrenic experience with respect to what I was told was the culture, what was expected and what the reality was.
The culture of facebook is that of a pretentious enclave of people who think that simply their being at facebook is validation of their any actions or motivations.
While the benefits of the company are amazing, the actual actions and methods of teams is utterly broken.
I was accused of not providing information in a timely manner, even though I was simply statusing other employees and teams on their activities. After multiple escalations regarding not receiving status from said teams, I was ultimately held responsible for those that literally ignored every request for an update, inclusive of escalations to both my and their managers.
I was accused of overstepping my bounds by looking into information required for various projects and interfering in other teams responsibility even after being explicitly asked to gather this information on thie behalf. I was told by my manager that I should document all requests in email to ensure that I was not perceived as being encroaching on their area. I complied, and was praised for covering for that team, then denigrated by my very manager for overstepping into their area....
I was accused of spending too much time in the social scene at FB, while I joined a total of ~5 groups within FB and only posted a total of ~10 times between all groups.
The fact is that there is a ruthless political system within facebook that ruthlessly seeks out people who are too active and cuts them as early as possible.
When I was fired, jsut minutes before I was assured by my manager that all was good and that the person who was difficult was just someone I was supposed to get to understand.
Then, all my colleagues disappeared from our desk line and I received a call that I needed to leave the building. It was the most cowardly and disgusting company exit I have ever experienced.
Wow, quite a few similar stories. I wonder how indicative they are of fb as a whole, or just particular teams. Does anyone have any positive experiences to relay?
The thing about this story that strikes me is that it's impossible to know if this rejection was because of any objective quality that would have prevented you from being a good Facebook employee, or whether it was just politics. Even for the players themselves I don't think anyone can say for sure.
Even though Facebook has a reputation for a strong, engineer-driven culture, the fact is that at a certain size the politics are complicated. It's not a question of whether you have to play politics or not, but rather what do the politics look like? This is why I like working for startups, there just isn't any room for politics, and you can sink or swim based on highly visible contributions. Even though Facebook makes the claim that as an engineer you are responsible for the experiences of X million users, in practice that's not how it works.
Even if it's "just politics"—politics is what prevents companies from thriving. It's a sign of poor management, poor culture, and poor understanding of human psychology.
Politics are endemic to all organizations, and the larger an organization becomes, the more it loses the ability to keep politics from interfering with an employee's work and abilities to do that work. Workplace politics are a kind of professional corruption, and this corruption easily hides behind headcount.
Almost by definition, yes, I believe you're right. You need some sort of organization with large numbers of people, and politics are just the part that self-organizes.
I think the negative aspects can be controlled better than they are in most large organizations. But most large organizations don't focus on that, to their detriment.
Wow, sounds rough. You seem bitter and hurt by the whole experience still. Let me just tell you: this experience is good for you in the long run. I can tell you as someone who sits on the ASD scale, I've had some painful periods in my early life where my brain locked on and obsessed over similar rejections. And the obsession and bitterness didn't do me an ounce of good. But later on I accepted it and realized the experience itself made me a wiser, better person.
As to your experience - sounds normal to me (unfortunately). You didn't fit the culture, or at least ended up working with some anti-you people. Maybe you weren't brogrammer enough. It happens to most everyone at some point in their career. I suggest you take from it what you can - when to recognize that things are not working out as early as possible, and to never expose yourself to risk as an at-will employee (always have a money backup!).
If it was his first job out of college, he may not have had much of a choice here. Wouldn't his signing bonus have been revoked since he wasn't employed for a full year? (Not a Facebook employee, not sure on their offer details.)
Wow, that confirms a few rumors i heard about facebook. This is definitely not a first. Thank you for posting this anon. This will make mine and a few other people's decisions a lot easier.
> Instead of telling another team member that he was wrong, I shared an experiment and results to demonstrate so, in order to minimize argumentation. [...] my overall performance was deemed poor.
That's interesting, because you often hear that "code wins arguments" at FB.
>> This might take more effort now but gives vastly greater results in the long run.
I'm also surprised by this. There seems to be a lot of importance placed on moving fast. Some of FB's mantras are "DONE IS BETTER THAN PERFECT", "MOVE FAST AND BREAK THINGS", and "STAY FOCUSED AND KEEP SHIPPING".
> * Actually, I am glad to say that I am now happily employed.
Your first comment starting by saying you were unemployed. Did someone just hire you since your comment?
The reference to the asterisk you included was by that statement. I think it's clear that he was saying that for contrast, rather than because it is still true.
I was also fired from an engineering role at Facebook. However, I look at the experience very differently.
They seek candidates with strong engineering skills, and only do a little culture fit at interview time (this was my experience at least). The real culture fit test happens during bootcamp, where they try for 6 weeks to break any misfit. Now that isn't going to work for everyone, but their strategy is to go all-out and try get a strong candidate to work well in their culture.
It didn't work out for me. I constantly reflect on what made me decide to accept their offer, what I could have discovered that would have made me realise it wasn't going to work out for me. I take interviewing far more as a two-way discussion, trying to find out what a company sees in me that they like and sometimes I tell them they misread me rather than risk ending up in the same predicament.
There are a number of things not directly in my control that lead to me leaving though. I had some bad luck with many of my bootcamp tasks, e.g. task owner on vacation for a couple weeks, task owners not being responsive if I didn't get back to them with working code really fast (I was working on other tasks at the same time), etc. I was drawn in very strongly by a manager who recognised that my skills strongly matched his team's requirements. I felt uncomfortable around that team from day one and never really tried hard on their tasks, and that reflected very poorly on me. At the same time, teams I took the initiative to approach would setup an initial meeting and then I'd never hear back from them. It wanted to dig into stuff I was excited about, while my bootcamp manager wanted me to complete the boring tasks I was assigned. Other things at hackathons drew me in, and I spent too much time on those projects only to be told a week before being fired that those were not being counted in my evaluation so I had to scramble to work again with the team I didn't get along with. Soon after that, that team didn't want to give me new tasks and I was left with nothing.
If I was to go through the process again, there are a few things I'd do differently. I would avoid letting the side hackathon projects take up too much time in the early days until I was firmly settled in. I would get more clarification on tasks as early on as possible. I would focus on one or two tasks at a time, rather than trying to churn through five or six in parallel. This way turn around time with task owners would be faster making them happier to help. I would forget about looking for a team until week four at the earliest - focus on tasks instead. I wouldn't take their advice to pick any team, even if you had no experience in the area, too strongly. It's good to get a strong start, and take the other roads once you've proven yourself.
I found a new job within a month. As an H1-B holder, I needed to be quick, so I settled for what I could get. Companies reacted differently to me being fired. While I'm sure all of them take it as a negative, some seemed to sympathise. I'm now interviewing again, and depending on whether Facebook comes up I have told some companies what happened and not told others. It doesn't seem to make a huge difference, since I've proven myself at my current company, but some keep prodding to try find that fatal flaw in me that lead to the firing (which I don't believe exists). I'm considering removing Facebook entirely from my CV after my next job.
Are you suggesting they effectively treat the first six weeks of employment as little more than an "extended interview" and fire anybody who doesn't make their cultural fit in that time frame?
That seems acceptable though it's really shitty if you end up not making the cut.
FWIW most european countries allow 1-6 months probation periods (for non-temp jobs, temp jobs have either no probation or much shorter ones). During probation, either side can terminate the contract without most of the restrictive clauses applying, it's essentially a short period of "at-will" to check fit between the company and the new employee.
I think it's only acceptable if it's made very clear before you accept or decline the job offer. Otherwise it seems like it's taking advantage of people.
The main reason I view it that way is because Facebook hires a lot of fresh college graduates who don't necessarily have much (if any) money saved up. To work for Facebook, they're going to have to find a place to live in one of the most expensive areas of the United States. I think it is quite disrespectful to put young people with little money in a situation where they are signing extended leases only to be let go within six weeks.
Granted, Facebook gives out pretty good signing bonuses, so that softens the impact a bit, but still if I knew that the first six weeks were effectively a probationary period I'd make a special effort to find a housing situation where I could pay on a monthly basis rather than entering a six- or twelve-month lease.
Moreover, if I had a family, I'd definitely think twice before going into a sort of six week interview, no matter who the company was. I wouldn't want to put my family through the difficulties of moving there only for me to get let go soon after arriving.
An excellent point, I failed to notice that issue and completely agree. In EU contracts with probation periods the probation is explicitly spelled out in the contract (since labor laws allow for it but by no means mandate it), and generally discussed/mentioned during the interviews stuff.
It's one thing if it's made clear that there's a probationary period; I've worked in (non-tech) companies where that was the case, although very different than what's been portrayed above.
If it's not clear that's the case, which seems to have been the case in these anecdotes, it would be pretty unacceptable.
New federal government employees also have to serve a 1-year "probation" where they can be let go for pretty much no reason. I've seen agencies exercise that right rarely, but it does happen.
I'd suspect that in more "mature" working environments the probation period is used more as a fail-safe mechanism, as opposed to being integral to the actual hiring process (which is what it sounds like at FB).
Treating new employees in this manner is okay if everyone's up front about it.
Telling people "Welcome to Facebook," having them quit their old job, and have them relocate just so you can smoke 'em and throw out the trash might be efficient, but it sure isn't kind.
I was told that working on those projects was a privilege and that we had to perform at our jobs (minus any output from hackathons) before we could work on the stuff we wanted to. I think it's a sensible strategy. Hackathons do keep engineers on the edge and excited about work, but you want to avoid it distracting from the core focus too much.
Hackathons are bullshit, period. If you're working, producing anything of value to the company, even if that be simply "worker engagement," it better be on company time. Simple as that.
I like the way my company does it. We have periodical "hack weeks", where for the entire work week, you can work on whatever you want that's at least loosely related to company technology or objectives.
I worked at a company that had "hack weeks" - most people loved them, and they produced good prototypes. But personally, I just hated hack weeks. But then again, I hated trying to work in that office at all, and trying to work on something "fun" there just felt worse than trying to do my regular job.
I think, though, if I was running a company, I wouldn't have hack weeks or 20% time - I'd try, for as long as possible, to give people extreme latitude to work on whatever they think might be useful/fun/interesting for the company - more like the Valve model, I guess.
A whole week? That's unheard of. Sounds good, sounds like my kind of down time, but I doubt most companies would embrace that time span.
There's another way to do whatever you want at work, and that's covertly. During the times you're meant to be doing other things. Depends where your desk is I suppose, or if working remotely.
Certain companies have code freezes during large sales pushes, mainly e-commerce and the like. These are times when whole weeks could be spent on a hackathon-like deal with little impact on other plans.
So, don't accept an offer at Facebook unless you're confident you'll shine in the first months (even in unfair situations, with people working against you). I can see how it's great for the morale of those who pass the hazing, but it sounds like perhaps they need to work on their on-boarding process - that incumbent teams and engineers are guided by selfish incentives that have nothing to do with helping newbies succeed.
On the other hand, those rejected will always have hurt feelings, and at some point their failure will be sealed by the lack of confidence/patience/charity established engineers have for them.
Probably the incumbents are often failing to appreciate the body of domain (FB procedures + code) knowledge they've accumulated, and that a new initiate likely lacks. Engineers are often poor communicators in that sense.
The Facebook "bootcamp" process seems like the best way to get around the problems of "blind allocation" as well as the problems of "teams need warm bodies and thus lower standards, leading to eventual company-wide mediocrity".
That's painful to read, I think most people have had similar experiences (though I've never had one quite this bad, they told you not to speak to people? WTF?) At least it teaches you that places like this exist and to listen to your Spidey sense when interviewing for a job.
I disabled my Facebook account over a month ago. It was tough to do at first, but as time went by I felt much happier about being disconnected. I've enjoyed having less distractions and false reassurances. I no longer need to keep up with everyday posts from people I don't know that well or rarely see. In this time away from the site I've realized that real friends will still be your friends even if you don't have a Facebook account.
Facebook will be surpassed by another site sooner or later. Just like how Friendster, MySpace, and others were. It is just a matter of time.
I tend to agree, and read recently that young people feel its no longer hip but are kind of locked in [ how I felt leaving M$ dev products for open source back when ]
I use FB periodically, and recently quite a few things in the UI dont seem to function [ logical bugs as opposed to say whether I like the feature design ]
I see this as a kind of bitrot setting in, maybe its just hard for large organisations to continue to innovate. Maybe it needs to move more slowly and focus on polish/robustness now. Do people like FB feature changes? I've found them to be annoying with no added value as a user.
"Understand the trade-offs being made and the factors that led to them."
As a user of Facebook, this quote explains a lot. I run a Facebook page with 90k+ likes, and have grown to expect it to simply not load completely without refreshing it multiple times. I've long suspected we were the victim of some type of 'trade-off.' It appears my suspicion were correct.
We also spend five to seven thousand dollars a month on advertising. I wonder how much more effective our campaigns would be if our page loaded 100% every time.
The text in your post doesn't support this conclusion (which tradeoffs are causing the behavior?). Just because something isn't working right doesn't necessarily mean it is because of tradeoffs; it could just be a bug (Edit: that they aren't aware of).
Also, it seems strange that you are experiencing that problem since many pages have more likes (for example Barack Obama's page has over 35 million likes) and yet load quickly; perhaps the problem is unrelated to the number of likes?
Edit: Of course if it is a bug and Facebook is aware of it but hasn't fixed it yet then the reason for not fixing it yet may be due to tradeoffs.
I have experienced the same problem. It happens randomly to random pages and not all of them are high profile pages. I would chalk it up to it being a bug.
I am in SE Asia, its a WiMax connection. The rest of the internet works as it supposed to.
The problem I am referring to (not loading completely and sometimes loading completely but not showing all the entries of a page) doesn't happen all the time, but happens often enough to notice.
I have the same experience in the US. Seems like it might be a problem with the admin panel on a page (since other pages don't seem to have the issue).
Thanks for the post! I understand from my interview process with Facebook that every engineer screens candidates. What are some things that have impressed you the most of anyone you have recommended for a position?
I think the most impressive candidates have a mix of 3 qualities: raw ability to program, ability to map real problems into programming problems, and ability to work effectively with other people. I don't expect the ideal candidate to be an ICPC winner or red-rank TopCoder, but they should be able to manipulate code effectively and reason about their programs well. Knowing what non-technical requirements mean in technical terms (i.e. how to build what the customer wants) and what technical restrictions mean in non-technical terms (i.e. what alternatives you can propose when presented with restrictions) is core to being able to build software that solves problems. And since we're talking about hiring people to join a team of other people, obviously I need to be confident they'll succeed in that environment.
I know there are many red-ranked TopCoders and ICPC winners working on big companies like FB, in your experience does this ability translate well into "real world" programming?
I'm not really able to look at performance versus TopCoder rank (partly because I don't know my peers' TC rank because I'm not that into TC), but if I had to guess, I would think that there is no correlation. It's simply a matter of where one puts one's developmental efforts.
Given the same amount of time spent on TC, you'd definitely have the expected correlation (with the usual IQ common cause if nothing else). But I agree that once someone gets reasonably competitive in an area (esp. one w/ game-like mechanics and public recognition), they're at risk for overspecialization.
It seems that it's more of a product oriented (solve problems) culture than an engineer oriented (create something cool) one. Not necessarily a bad or good thing but it's consistent with the impression I got from Facebook in the last couple of years.
I think that's a false dichotomy. Every employed programmer is building software to solve problems. The "product" of that labor doesn't have to be something that a non-programmer uses. For example, our memcached engineers at Facebook are building a product in the sense that other engineers will consume the service that they maintain. The word "product" simply helps to frame the fact that the goal of their work is to build, maintain, and optimize this service. If the work they are doing isn't towards that, then they aren't doing their job.
So I was a memcached engineer. The memcached team barely works on memcached anymore, because there are no real returns. Being product focused means that it doesn't make much sense to really increase the perf on something when there's other stuff to be done, even if you could do it in a really glamorous way (user space network drivers spring to mind for this -- that'd be pretty cool)
Instead, they focus on superior libraries and different use cases that make the stack more efficient. (Mcdipper was my project here). In infra, you are measured by two things: 1) dollars saved and 2) features made possible (in a very global way, sometimes this means business deals). You also get points for the site continuing to work
I had the impression that Google was engineer oriented but I wonder if this is still the case with their recent refocus into a small number of key products.
With that in light, how would we (to the best of our knowledge) characterize some of the big/promitent software players? (FB, GOOG, AMZN, MSFT, NFLX, RAX, DBOX, etc.)
Are we thinking of the same Google? Google has gotten its hands on everything from niche programming languages to web browser to computer vision and neural networks. This, of course, in addition to its traditional strengths in search, distributed databases, and infrastructure.
Yes, they are still an engineering company. Watch the I/O keynote. They are deeply vested in various areas of computer science, machine learning, and distributed systems.
Yes, Google is still very engineering oriented. No questions about that. It is also one of their issues. They struggle to market products. Facebook on the other hand, is good at marketing products, and is also good at engineering (not as good as Google though). Though Im not saying Google engineers are better than Facebook's. It is the focus of management towards engineering thats different.
I intentionally left them out since imo their software serves to augment their hardware and the nature of the beast seems to be a bit different from others.
I didn't really see what's so specific in this post about Facebook? The same could be said like "it's my X year on social network Y". I expected something specific in the context of Facebook in the post, but I didn't find it there. I'm not a Facebook user though, so may be I didn't understand some implicit assumptions of the OP.
The post was written with my younger coworkers in mind but I felt like it was of general interest to all new programmers so I made it public. I don't think you need to understand anything about the Facebook product or company in order to understand my post.
The original title here was "FB engineer reflects on his job" but I guess it got changed because that phrase didn't appear in the linked page? I think the other title set context that wasn't needed on Facebook but is in this environment. Apparently an editor disagreed. (Editor, if you're reading, I'd title this "My advice for newgrads joining software companies".)
This is a good explanation (of what it is to tackle bigger problems):
"As an engineer, your job is to build things that solve problems. When you first join the company, you're assigned small tasks and you solve them. As you grow professionally, the domain of these tasks becomes larger. It is a mistake to constrain the increase in domain to larger or more frequent diffs. Code is a tool you have for solving problems. If you were gardening, you might plant flowers or pull weeds. Increasing your scope does not mean planting more flowers or pulling more weeds (though you should expect to be faster and more proficient at that as you become more experienced). What it really means is looking up from the ground at the garden in its entirety, considering how your section fits in, and eventually helping to decide the whole garden's plan."
understand temporary solutions and the priorities that necessitate them, but don't accept a decision that you feel is wrong without raising the issue and getting a better understanding. This is your company (your garden) and if you let people pull in the wrong direction the entire plan will fall into disarray.
i'm interested in hearing experiences about what happens when you actually achieve this level of control. I love my garden so much, and have been given sufficient responsibility over it, that I care very much when people pull in the wrong direction. Refusing to accept incorrect decisions -- decisions that will absolutely cause technical debt, overtime, and significant stress and a smaller bonus for us all later in the product lifecycle -- can lead to some interesting and complex social dynamic and this is the biggest thing I struggle with today. Its actually even more complicated because while I feel I am usually correct (who doesn't), there are times when I'm wrong and there are other times where I don't realize I'm wrong.
This is something I've often struggled with before I joined Facebook, and it's something I occasionally grapple with there too. Like you, I felt I was usually correct, but had come to the realisation that not only was I occasionally wrong in short-term hindsight (just after the fact), but sometimes only in longer-term hindsight (ie, after I'd learned some lessons further down the road).
Ultimately, it comes down to trust and teamwork. I had a much longer post, but:
a) Make sure you are doing what you believe to be the right thing for the company as a whole, and that you're armed with as much information as is easily obtainable about it to inform your strong opinion.
b) Then, if you are able to believe that the people around you are doing what they believe to be the right thing for the company as a whole (even if you might need to remind them that they should do that) based on the information (and you might need to help them understand what you have discovered) and experience available to them, then your life will be a lot less stressful than if you're the guy that feels they always need to steer the ship.
It's also something I've learned more and more about leadership and mentoring:
a) It's hard to learn lessons if you're not making mistakes. Telling people how to avoid mistakes in one case doesn't help them learn how and whether to try avoid them in future.
b) Choose your battles - expend your influence capital on the most important thing, and don't transform from that person that's been a great help in the past to that person who just tries to meddle in everything.
The best thing I can say is that when interacting with other people, subtle course correction early on has a big effect in the long run. When I've tried to influence other people to change practices (in my case it was building more testable code), I've found that making the right path the easiest path is the best way. There are a lot of ways to do this. Code review is an easy one if you're not doing it already. It gives everyone the power to have influence over the code before it lands in the repository [1]. Building tools that make the right thing easy is also useful. I spent about a year making development tools to enable rapid testing of some of our JS modules, as well as doing a little bit of static analysis to automatically detect and fix certain classes of errors. By doing these things, every engineer gets guided to the right path without needing to reach out to anyone and without a huge cognitive overhead (like reading an interface guideline or something like that).
I believe Steve Jobs said the reason he took on the role of CEO when he came back to Apple was so no one would be above him when it came to making decisions about the products.
My experience has been, when a company is built around a product, everyone at the company wants to think they know what is best for the product, regardless of their actual role and abilities. Installing yourself at or near the top is the only way to actually take control. If you can't get high enough up the ladder in the place you are at, and this is frustrating you, it's time to jump ship and move somewhere you can. Else you will likely become a poisonous influence on the team around you.
Good job, and I regret to hear that it seems you were given some bad advice from authority.
There's a lesson I learned at around 12 or so, good to learn sooner than later. Don't trust the experts, for the sake of being experts.
I probably have a few good burn out stories to share, but since this is a public forum and you're anonymous, let's just say that it's part of the experience. Learn, live, move on, towards something better.
Given a 4 year vesting cycle it is the end of the fourth year that is of the most interest :-) Although I've noticed things are a bit more 'shares every year' kind of thing these days to maximize retention.
If we had a minimsft type blog on the major players in tech, I suspect we'd see that they all provide roughly the same type of positive AND negative experiences.
After doing an internship at Facebook in college, I received a full-time offer for after I graduated. I never really felt like college was for me and so I asked if they could extend me an offer immediately rather than waiting until graduation.
> Does internship to employment transformation imply easier interview process overall? i.e. rather than apply to full-time position directly.
Not necessarily easier, but having 12 weeks of experience working with me gives the company much more context on my software engineering skills than 4 hours of interviews does.
> Another concern - does this also imply the offer with a below average compensation?
I don't think so. Anecdotally, I've heard that recruiters have pretty fixed packages for newgrads and that I was given a newgrad package.
Say what you want, but I left my entire, close-knit family behind in Ohio when I moved to San Francisco for better opportunities on better engineering teams. Nothing in my life keeps me connected with them the way Facebook does. Nothing else draws together an audience as broad. From my teenage age cousins who use FB their way, to my Baby Boomer parents, to my Greatest Generation grandparents. They're all there in one place.
Also, they've faced enormous engineering challenges. Yes, Facebook style problems have great fanout results. You can almost accuse it of being easy in that way. But at their size and with their growth rate, nothing is easy.
I'm not a big facebook user. I didn't touch it until i moved away and my family over time started using it. But your slur here is absurd. Facebook has given a lot of great engineering back to the community. Thrift. Cassandra. Open Source networking hardware, etc.
Yes the Facebook product has some utility. And they do have big engineering challenges, and have contributed to open-source.
These are not unique to Facebook, and if these are the criteria for working there, I can think of a lot of other places to work at that:
a) Have products that my friends and family would enjoy/use.
b) Have interesting engineering challenges that a new employee can work on.
c) Allow employees to contribute back to open-source and maintain their open-source projects on company time, with significant engineering resources.
The OpenCompute project is pretty unique to only Facebook, so if hacking on data center hardware is your thing, Facebook is pretty unique in that regard. Would be curious to know how many people are in that group though... I imagine it's pretty small compared to their general software engineering workforce. You can do similar work at Google, but they don't let you release your work Open Source. :-) Trade secrets and such...
Your job must be so miserable that you feel the need to make a comment like this. I'm so sorry about that, but some people have exciting, amazing jobs, and that's no reason to get jealous.
Having a miserable job and thinking that Facebook is largely a waste of great engineering talent are orthogonal things. I think a lot of good knowledge on the scaling front comes out of it, but I wouldn't say that it's the most efficient societal use of our best engineers by a long shot. I think it's everyone's right to choose how they spend their time, even if it squanders their potential impact, but we generally shouldn't feel proud when we squander it.
Why not? Without FB, I wouldn't be able to connect as much with all the people I've met in multiple places around the world. All people that I care about.
I've also met a ton of new people that I otherwise wouldn't have met (e.g. from groups). I connect with the CS community at my school through FB. I connect with people in my class through FB. A lot of discussion happens on FB that I'd otherwise miss or not have the chance to participate in (everyone is extremely busy)
I think the result is probably a larger number of shallower friendships than you'd have otherwise, or at least that's the pattern I've noticed, and I don't think that's necessarily better. The rest of most people's time on there is generally spent idly browsing the trivia of other peoples' lives. I just don't think it's a very effective use of users' or engineers' time.
I used to use FB a lot, especially in college, but aside from being great for organizing parties, I've found that I like the old ways a lot better. For actually communicating and having conversations with people, IM and email are actually more robust/effective/universal, and aren't engineered and A/B tested to hell to suck up attention as effectively as possible.
Doesn't matter if you think they're shallow. I care about these people. I want to know more about them and I want to stay connected with them in hopes that we cross paths again some day (for those that I don't live near).
It's a bit like the halo effect, where if the company does one thing right (get lucky and dominate the market by being first), then everything else they do must be right too.
If you ask me, they could take what ever approach to development, hiring, training and firing they like and they'd just be as successful.
But, none of that stuff is what made them successful. Therefore, I'm actually not that interested.