> 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.