nbm

Whoever took the screenshot has installed a browser plugin that is inserting those ads, or has some other form of malware doing so. It should be easy to test - just disable them all and they should disappear, and then turn them on one by one until the ads appear.

What position was he recruiting for, and roughly when (let's say, which quarter and year)? How likely was he a new recruiter?

I'm not sure I can express my skepticism about this enough - our security, safety, and site integrity teams are some of the most privacy-conscious people I know, and even a hint of something like this happening here would lead to very pointed questions asked at the weekly Q&A every week until it was resolved.

It could also be criminal groups that are trying to make their profiles appear less fake.

I worked with the team that fight spam, scams, and the fake accounts that distribute them when I started at Facebook, and they expend a lot of time writing code and building machine learning models to detect fake accounts. There would be no fake accounts if there wasn't a massive financial upside to it, and so they do the strangest things to try avoid the detection.

You can read a bit about what the team does at http://research.microsoft.com/en-us/projects/ldg/a10-stein.p...

What position did this Facebook employee hold at the company? In which office did they work? Is it possible they weren't really a Facebook employee? What sort of censorship are you talking about?

I ask because I've never heard anything like that, despite working with the teams that build tools to fight spam, scams, fake accounts, and to assist the User Operations team to handle reports from people who encounter harassment, bullying, and other anti-social or criminal activity.

It seems to me that "sell your personal data to advertisers" sows more confusion through its recognition than clarity. People who hear "sell your personal data to advertisers" without your background tend to believe it literally - money is given to Facebook in exchange for personal information (ie, someone's name and particular data about them).

In terms of the "Like" button and other social plugins, unfortunately there's not all that much to be done about the way the technologies in the web works. Facebook came up with this "widget" that provided way more value to people than the equivalent buttons from Digg, Delicious, and several others, many of which encourage integration that uses resources stored on a central server which could allow tracking even without clicking on them. Many of these widgets need to talk to a server anyway - to provide credibility and popularity by showing how many people have liked the content. However, the "Like" button needs to talk to a server to provide its additional value - to show you a list of your friends who have also liked this content.

I encourage you to read the Facebook Data Use Policy, especially the section about "Social plugins" under "Other websites applications", and the link through to the Help Center that gives even more information about how that data is and is not used.

What makes you say that Facebook will "sell your personal data to advertisers"?

Do you mean that advertisers pay to get information like your name, email address, street location, and other identifiable information about you, like in a huge spreadsheet?

Or do you mean that advertisers can pay money to have their adverts displayed to the sorts of people who most likely will be interested in them but receive no personal data, as explained at https://www.facebook.com/about/ads/ ?

While I get that some people like to make it sound more dramatic by saying "sell your personal data to advertisers" while understanding how it works, it's also common that people just don't understand.

I'm sorry you are having a bad experience.

It sounds like you have accepted some friend requests from some noisy/energetic people, and/or from people that you perhaps don't really care about. My experience is that unfriending people I don't actually care about (people I've only interacted with a few times a long time ago, for example), making a close friends list (people I care a lot about), and moving the 25%-ish people I care the least about to the acquaintance list has improved my experience a lot.

There are always some unusual cases - a cousin you mostly want to hear things from/about who loves all sorts of games, maybe. For those special cases, you can also control specifically that you don't want to hear from them about games.

I'm not really familiar with problems with events - I get a few event invites a month, and generally they are things I'm interested in going to. How many events are you being invited to? How many different people are involved in inviting you to them?

If you're using Windows, you could also try out the Facebook Messenger app to keep yourself on chat.

(I work at Facebook, but on infrastructure, not products.)

What about the comment history feature makes you uncomfortable?

This is a feature for groups, not for pages (the way companies generally interact with people who use Facebook). Groups are generally created by people for groups of people that already meet/know each other in person or to discuss a shared interest, not by companies (unless they're company-internal groups, I suppose).

They are for things like for a bowling team in a league or a user group or other ad-hoc group of people who want to communicate with each other - co-ordinate dates and times, send out last-minute updates. The hope, as I understand it, is that it will reduce confusion/anxiety/overcommunication over who hasn't yet read something ("Did Mike read the update that mentioned he is supposed to bring the projector? Should I send him a direct message/phone him?").

Pages already have Insights which gives them aggregate-only demographic data about the audience who has interacted with a particular post ("52/48% female/male, 80% US, ...").

(A Facebook engineer, but not involved in this feature.)

As far as I know, at Facebook we don't give pre-emptively/usually give people a book to learn PHP. Those that don't know PHP (or are rusty) can generally get the syntax/keywords right in an hour, and then there's a longer time spent getting familiar with both the standard library and our own frameworks/libraries.

There is a lot of good code to look at and learn from, and the Bootcamp program teaches a bunch of our own library and some guidance on what good and bad standard library functions are for certain cases. We also have a "newbie" group where people can ask questions about the codebase. And if you do something without knowledge of a built-in (or Facebook) function/class and make things more complex than they need to be, your code reviewer will let you know how to do it easier/more idiomatically. Every once in a while there are language tech talks, and sometimes even whole-day training sessions (we did one on exciting new C++11 features).

Besides that, I definitely spent a lot of my time with php.net/function_name open and exploring when I couldn't remember all the functions available or the parameters and order.

I have only a year and a bit of context since starting at Facebook, but here's my viewpoint.

Facebook isn't trying to move away from PHP as quickly as possible. For years, there have been PHP components (primarily web front-end rendering, aggregation/ranking of data from various sources) and C++ components (primarily high-performance back-end services) and other languages like Python (primarily non-production-path/operations back-end services) and Java (primarily Hadoop-related technologies like Hive and HBase, and services that are heavy users of such), and nothing groundbreaking has changed in this.

New hires use PHP or C++ or whatever language (and often multiple languages) necessary to work on the team and projects they choose to work on. New projects use the languages that make the most sense.

Almost all web front-end work involves PHP - the frameworks and libraries and runtime environment are well-developed, well-tested, well-documented, and well-known.

In terms of HipHop for PHP, the question to ask is: What language could have allowed quick low-barrier-to-entry web-app-centric development in the early days while still delivering the sort of runtime efficiency demanded by the environment? Languages like Python and Ruby may arguably allow the first (but remember we're talking about early 2004 here, so Ruby on Rails was not out, and neither were Django, Flask, and so forth and WSGI had just come out), but would have required a "HipHop for PHP"-style solution as well. Languages like C, C++, and Java may have the runtime efficiency, but it would be a hard argument to say they're as developer-time-efficient as PHP (especially back then).

That's a slightly different question to what one should do today if starting a new venture. And _that_ is also a different question to what Facebook should do today - HipHop for PHP exists, and is delivering performance/runtime efficiency that most languages people mention as an alternative do not. And, the PHP frameworks and libraries and runtime environment exist and allow rapid development of production code. It's actually reasonably pleasant to develop for with those in place.

The HipHop for PHP team is small, but have huge leverage - this small team of reasonably hardcore low-level C++ programmers are making a whole bunch (hundreds?) of PHP developers way more productive (since they don't have to use a relatively slower-to-develop-in language/runtime like C++), and also makes the cost of operating the site go down by making that code more efficient and reducing the number of servers needed.

My somewhat circuitous point is that the ability of a server to perform work is bound by something that runs out - CPU (no more CPU time available), disk I/O (can't handle more I/O requests to disk), network I/O (can't put or get any more packets through your network card or some upstream device/pipe), and so forth. Colloquially, whatever runs out first is what you are bound by.

You can either increase the resource (upgrading CPU, adding memory), or use the resource in a different way/trade off one resource against another. For example, compressing data before network or disk I/O might be useful if you have spare CPU. Once you've done that, you may now be bound by something else - maybe available memory. If you have spare resources (CPU, for example), you can then choose to use fewer/less powerful resources in that space if it makes economic sense.

You can also talk about response time being bound by something - disk seek time, network latency, memory latency, and so forth. That affects how fast something can respond, and while that figures into how much work a server can do (per-thread/request memory usage), it doesn't generally largely affect how many machines you have to buy or their configuration (unless you have low-latency options).

Why can't the web server do other work with the CPU and other resources at the same time that it is waiting for those network operations to happen?

I'd be interested to understand why you would classify web servers as generally I/O bound, rather than CPU (or memory) bound.

Of the 100 or so interviews I have done over the past year and a bit, only two or three have had cases where the interviewee did not need to admit they did not know. If my goal is to understand the breadth and depth of knowledge, then one can only really have a clue about that when one starts hitting the edges.

The grace/confidence in admitting they don't know, the willingness to guess and explain how they came up to it (and continuing/iterating as I give more information), and how well someone integrates something new (ie, something I have just told them) later in the interview are all major considerations in my interview feedback and hire/no-hire decision.

It is important to keep in mind that Facebook isn't just a single PHP code base, and thus one can't really make many assumptions about how well PHP is suited to solving certain problems because one doesn't necessarily know about which bits are implemented in PHP, or whether PHP is just a templating/rendering stage over work done elsewhere.

Some other languages might allow you to do certain operations in the front-end more easily, but the way to approach it when using PHP might be to delegate that to a back-end service in another language. Similarly, some languages might allow you to write both most front-end and most back-end software in the same language, where PHP might be wholly unsuitable or makes certain things harder to achieve than it is worth using it for (maybe strict memory usage control, maybe where you're looking for CPU cache wins).

The question is whether someone is saying that you can't use the PHP language/architecture to create a large and large-scale application like the Facebook front-end, or whether they mean the PHP runtime is unable to perform effectively at scale.

The Facebook front-end code is largely just the PHP language (modulo things like XHP) and follows the shared-nothing, request-based architecture that people who program in PHP expect. With the right abstractions and code organisation, it is fairly clean and understandable even at the relatively large size (even if I'm not generally a fan of the language and would almost certainly not make the decision to use it today).

It is somewhat less interesting whether the PHP runtime is as efficient as it can be. Partly because one can use an alternative runtime like HipHop for PHP if you want to. And partly because very few people have to worry quite as much about performance/efficiency that comes with a large capital/operational cost where you have hundreds of servers.

So while "But Facebook uses PHP so it must be good" is not the best argument, neither is fighting it with "But Facebook reimplemented it!".

Facebook uses a combination of primarily PHP(1) (mostly front-end, rendering, some async jobs and scripts) and C++ (mostly back-end services, other bits of high-performance infrastructure, HipHop for PHP), with some Java (especially in the Hadoop, Hive, and similar areas), Python (mostly automation, scripts, infrastructure), and so forth.

From what I understand, Yahoo! has a similar mix of technologies.

In both cases, you really can't say "are PHP".

(1) Modulo some in-house and open source extensions (like XHP) running on HipHop for PHP.

If PHP is putting you off considering working at Facebook, then it may be useful to know that there are many developers who hardly ever touch PHP at Facebook.

Most back-end services (ie, the systems that build your feed, or detect spam) are in C++. Java is used in some back-end services (including, for example, in Hadoop, Hive, HBase, and the messaging product) and for the Android app. Objective C is used for the Facebook app, Messenger, Camera, and so forth on iOS. Python is used primarily in the automation and operations space. You will also find a bunch of Ruby, Haskell, Scala, and so forth around.

I am not generally a fan of PHP and much of the ecosystem around it, but using it at Facebook is very different. I also would not say that time spent learning and using PHP is time wasted - the important things to learn typically transcend language, and learning anti-patterns / deficiencies is useful too. That is also why Facebook does not expect any particular language knowledge before you start/when you interview.

Perhaps it is best for the database team to talk about that themselves - wouldn't want to put words in their mouths. They gave a Tech Talk in December last year, which you can see at http://livestre.am/1aeeW

I would be interested to know what you mean by "real data store", and what you believe Facebook does badly at in terms of handling data and caching and how it could be improved.

(I am an engineer/developer/whatever at Facebook, and I'm always interested in hearing the perception of the company's technology from the community.)

I'd love for you to tell me the story (with or without names, anonymously or otherwise) so I can give feedback to the recruiting team (or individual) here at Facebook. Contact details in my profile.

I suspect you are misremembering either a real story about an advertiser using someone's photo without permission or rumours based on it that occasionally become popular.

An advertiser once, against the FB terms of service, used a user's profile picture in their advertising. The advertiser was banned from the platform. Here's a news story that might jog your memory on this: http://mashable.com/2009/07/17/facebook-dating-ads-2/

People aren't forced to work nights and weekends during lockdown, although some teams may up their expectations for people to do that. I haven't been on a high-priority project for a lockdown, but I imagine it is possible that some go overboard. I also imagine it is likely that the guys who have good reasons to not stay late or work weekends also teach the guys that go overboard a thing or two much of the time. Working a few nights and weekends for a known short period of time is different from a death march, making it a habit, or having a culture that expects it all the time. Much like I imagine Sheryl does a few late nights in a row and an impacted weekend every once in a while to overcome some time-sensitive hurdles to the company's success.

The message is that the company is going to make it easy to work on and focus on the particular high-priority projects you are involved in by increasing the rate and operating hours for shuttles and kitchens, and making it even more culturally acceptable (and even dutiful) to avoid distractions like meetings, lower-priority projects, and so forth. Obstacles to getting work done, whether during usual office hours (which are already not that usual) or not, are reduced or removed.

For me, the lockdown concept gave me an opportunity to consider working on more important things than the things that just happened to be in my tasks list, my appointment calendar, what people in team meetings thought was important, and so forth. Lower-value meetings started happening less frequently or being indefinitely postponed. In terms of time, I think I ended up working less at the end of lockdown than I did before it started.

I don't know about staff closer to Sheryl (ie, not in e), but there are definitely many software and other engineers working 40-45 hours a week fairly standardly, and I seemingly don't hear enough negative chatter about it for me to recall hearing any.

XHP is orthogonal to HipHop, since XHP is available as a module for Zend PHP - https://github.com/facebook/xhp.

I would disagree here - every percent CPU saved for the same workload is a 1% reduction in the number of machines needed. The number of web machines is sufficiently large that savings of even 1% are praiseworthy. Quite a bit of effort is expended to keep this going down and to the right (at least some of the time).

It is "Push karma", so generally only applies to the push process. It isn't visible to anyone but the pushers and yourself (at least, I can't see anyone else's push karma in the expected places).

It isn't a complex rating system - there are probably 97% of people at the base karma level, maybe 0.1% at one rung higher, 2.7% at one rung lower, and 0.2% at lower than that. The "Push" tech talk at https://www.facebook.com/video/video.php?v=10100259101684977 has more on it.

Mostly it is a way of letting you know that you made people's lives difficult by holding up the push process by not being available to support your changes. You know that you won't get away with that, that you need to make up for it, and you also know when you've made up for it.

(It also doesn't apply to a decent number of engineers, since they work on services and infrastructure that are not part of that process.)

There is pretty much no way 4 to 5 guys could rewrite "www" in another language in parallel to continuing development from a hundred developers, no matter how long they had. However, 4 to 5 guys could write HipHop.

What real-world problems do you see staring Facebook in the face in its continued usage of PHP? I'm no PHP fan, but many of the common PHP problems are avoided or mitigated in the code base.

We do make extensive use of Facebook messages (many people, including me, make good use of Facebook Messenger on mobile and/or desktop) and of Facebook groups.

IRC's ability to quickly create temporary groups, temporary membership (essentially muting discussion by leaving, or peeking by joining), bot frameworks, and multiple clients are potential reasons why IRC might be preferable for the sort of things it is used for, I guess.