9 ms·

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

by anonymous592053 13y ago

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

anonymous592053 13y ago
[Continuing because of HN's length restrictions] > 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.

anonymous592053 13y ago

[Continuing because of HN's length restrictions] > 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.