Since I decided to visit the site based on your comment, I figure you might want to look at optimizing the image on the front page - it's a ~670k PNG that took 12 seconds to download...
1,053 karma · joined December 6, 2010
South African temporarily in the Bay Area 2011-2015, Seattle 2016-.
Formerly tech lead and first employees at startups Yola (2007-2010) and KnowledgeTree (2004-2006).
Contacting/following me:
fb.me/nbm @nxsy on twitter Email: HN username at nxsy dot org
Anecdotally, I consider myself lucky to have been convinced to see a psychiatrist (after considering it frequently over the previous decade). After a few months on medication, a few talks with some friends and colleagues about what was going on (and discovering that some of them have had similar experiences), I started to get a degree of perspective I hadn't felt before about my relationship to work. Not terribly much longer I started doing side projects for fun, after years of declining interest in pretty much everything I used to enjoy.
Finding a job you enjoy can be hard and take some time, even if not considering a career change. I would caution against wholesale avoiding using your existing skills - they may be useful as a way into a new job that will afford you an opportunity to try get closer to something you are interested in trying out. Also, trying a totally different type of organisation, if available, is also something to try, even if using the same set of skills, since often people enjoy doing things more with the right people, or with the right mission or feeling of doing good in the world. (So, maybe a charity/non-profit, or a family concern instead of a "company".)
Try not to be too afraid of taking incrementally-closer-to-what-you-want jobs as you find them (ie, always be looking and talking to companies), even if it means only spending a few months at one or two companies on the way (assuming your previous career shows a stability future employers might want to find).
(I'm happy to speak to you offline if you like - my contact details are in my profile.)
There generally aren't a lot of status meetings, team meetings, project meetings, and so forth at Facebook, but you might want to turn down a request to present at another team's meeting, or turn down those requests to interview - they can wait, or another person can be found.
People tend to make progress on lower-priority work items in between higher-priority work items - things like migrating onto a new library or version of a service, or maybe migrating from one set of machines to another if you aren't using one of the high-level service management systems. This is necessary to prevent these things from becoming interrupt items down the line, but during a lockdown period, it's okay to let these slide for a bit.
If the whole team does this, then suddenly you're spending a lot more time together. Instead of potentially working on different parts of the software like you usually do, you can all focus on a particular class of problem - in this case, performance and parity. That means everyone has that context loaded up, and you can have better discussions and quicker code reviews.
"Coloured" refers to (and is used self-descriptively by) a subset of people of mixed race of generally one or more of usually British and Dutch ancestry on the "White" side, and generally one or more of various Bantu groups (mostly Xhosa, Zulu, some Ndebele, &c.) or Khoisan ancestry, and sometimes also of Malaysian or other South-East Asian ancestry (from ex-Dutch colonies).
I'd like to help you and dr find you a good match - FB has been a great opportunity for me, but I stumbled a bit so I know how important finding the right thing to work on is. I can also offer you my frank impression of the performance review system here, which I've been through a few times as an IC and as a manager.
Jumping to Facebook's current architecture and taking on the trade-offs taken there (assuming you even have a problem where those trade-offs make sense at massive scale) is probably not the right thing to do when you are much smaller (in terms of requests/traffic/load, servers, and employees).
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.
You can also use a custom audience selector to do things like specify a friends list (or more) to share with, not to share with friends of those tagged, and so forth.
Here is a link to the help page on privacy basics that starts with setting/modifying audience for posts: https://www.facebook.com/help/325807937506242/
If somebody likes that photo, that like will only be visible to those that can already see that photo. It does not give anybody the ability to see the photo that did not already.
In many cases, you can see the audience selected for posts your friends make by looking for the same icons from the audience selector next to the date and other metadata in your news feed, their timeline, or the picture page. If it is public, there'll be a little globe. If friends, then it'll be two people standing next to each other. If friends-of-friends, three people standing there. Obviously, you can't tell if it was shared with only them (since you wouldn't see it). In some cases (the person chose a custom audience), a gear icon will appear.
If after you investigate based on the information above you really think the privacy model expanded who could see the photo because of the like, please report a privacy bug: https://www.facebook.com/help/contact/?id=308229232560802
(In case it wasn't obvious, I work at Facebook. But I don't work on privacy specifically.)
Recruiters know that an employee referral is more likely to yield a hire, so it makes sense they might use that to prioritise those people in terms of scheduling interviews.
It would probably only rarely affect the end result (and if so, only on really edge-case candidates), but it would affect the speed to getting to on-site.
It is also a bit heavier, and is not tapered (which I find aesthetically appealing).
When a particular function or class is found to be a problem (or when it is known to be a problem in advance), it is (re)named something like "foo_POTENTIAL_XSS_HOLE" or "FooMapNonStlCompliant" throughout the code base (using pfff or similar tool), and then the potentially long process of removing the problem can go forward with some confidence nobody will add to the problem while you're working on it.
You can find more details in http://research.microsoft.com/en-us/projects/ldg/a10-stein.p...
If the same group of companies attend as last time, it would be a no-brainer to attend if you're interested in a job at one of them. In many ways, I found the questions asked by the candidates about the companies to be a lot closer to what I think people generally want to know, and it was great to watch two companies both trying hard in front of each other to impress the candidates.
But that's the thing - it's a bad question. It should be asked as "what does this do?" or "how do you do this?", like:
"What does this code do: foo(1, 2, kw)?"
Or:
"How do you import all exported names from a module into your module's namespace?"
These show your code reading and code writing skills.
The original question is based on unreliable use of memory. Memory is great at slightly-fuzzy-key lookups. It is usually terrible for table scans applying a pattern filter.
Think of the challenge "Provide 5 common Unix command line utilities start with t"?
Most people who actually know 15 or so of them and regularly use 7 or so of them would have trouble providing all 5. Some will just blank for a minute (because there are just no pathways to work from), most will find 2 or 3. People who studied a Unix text book the night before would also know 2 or 3. A few might just totally blank and become affected by the fact they can't even remember something so easy that they will be unable to answer that question, and may affect their interview performance after that.
So it just is not in your interest to ask those types of questions.
Similarly, self-deselection is something you want to avoid - ie, you need to prove yourself to them a lot more. Making sure people you are interested in see the sorts of information they might need to consider working for you is important - maybe it's talking about your product/opportunity, your development/product/management/business philosophy, or even just mentioning who works with you and what they've done (although focusing on the VC team, or just saying "A bunch of former employees at Google, Apple, Microsoft, Facebook, Dropbox, ..." is probably not enough).
One thing I've found is that certain people are better at asking certain types of questions. I love "exploring" conversational-style interviews that are highly interactive and where not knowing something is an opportunity for the candidate to figure it out themselves or to learn a new thing. One colleague does an awesome debugging scenario that I sometimes think could continue for hours if he wanted to. I assume that certain candidates like particular interview styles - finding some way to match those two together would be great. (A recent Facebook start and I spent an additional half-hour during his interview because we both enjoyed the subject we were discussing. Making each interview that enjoyable...)
I'm not entirely sure what you mean by challenge problems - is this a technical phone interview with a specific set of broader topics/challenges, or is this something that gets sent to the candidate and they get some time to return a result?
I prefer the term "phone interview" when a non-recruiter/sourcer is evaluating the quality of the response to some question or challenge, and "phone screen" for the initial recruiting discussions where wholly unsuitable candidates are weeded out due to skill or experience mismatch to the role based more on treating commentary provided by the candidate as fact (although it does go a lot further than that).
Taking some time to understand what people do, the challenges they face, the work they head off without you seeing any of it, and that they're as interested in getting things done, and getting better at what they do, as you are is well worth the investment.
I've also been on the receiving side of delightful trivia questions like "What are all the ways the character '*' is used in Python?" and puzzle questions that test "creativity"/"ingenuity", whose value are totally alien to me. (I've also done online quizzes/tests, including personality ones(!))
I would like to think there's a broad middle ground in between, but that there isn't a single process that is going to be effective for all companies or for all candidates.
In the past, I've used "homework" as a final step in a hiring process, which worked for some (it certainly washed out a few candidates who got passed less strenuous interviewers), but which others weren't interested in doing - including two that we hired anyway and who ended up being great coworkers.
I imagine I would feel a bit put out if a startup wanted me to spend 2-4 hours on something before they allowed me the opportunity to get to understand the position and the company (especially since I would hope the startup would look at my open source contributions in lieu of the homework). New grads might have a bunch of opportunities, and they might decide on skipping something with that sort of requirement.
It sounds like it could be a fairly unreliable indicator. I'm not sure what the interview-to-hire rate is, but there are only a pretty small number of people that are offered positions - and even then sometimes you don't win against a competing offer, or a sudden realisation that they want to stay geographically where they are. So even for the top few percent of interviewers who interview ~100 a year, you might only have 2-6 hires, which isn't really a large enough population to evaluate.
In an interview, the best you can do is try probe talents, skills, and knowledge, but you'll also get a point-in-time view into their current attitudes and beliefs, as well as the possibility for swagger and misdirection (even self-misdirection).
We do look carefully at situations where one or sometimes two people get strongly negative or positive signals while the remainder get strongly in the other direction, in case there is a problem. Most times it has turned out to be valid concerns, and it also helps us give feedback to interviewers on how to write better feedback, how strongly to weight certain traits ("not knowing the name of a particular useful function/method under pressure is reasonable, so let them just use it even if they got the name wrong"), or how to evaluate a particular type of candidate (newly graduated candidates, for example).
I wonder how they deal with understanding/measuring performance with these short engagements.
(Facebook has a "hackamonth" program which people who have been at the company for 18 months are encouraged to do - work on a new team for a month, and then decide to return, stay, or join a third team.)
As a candidate, I found the Facebook and Google interviews to be fairly daunting by description, but even with 10 hour timezone difference in jet lag, I did not feel I was being overworked, that the interviews overlapped dramatically in their content, or that I was being asked anything unnecessary (well, there was one interviewer...). In both cases, I felt I had an opportunity to show off some depth in a number of areas, and that I may have been less likely to succeed if my best interview was discounted. That said, I had a decade of experience before going through those gauntlets, and I am well aware that my experience of these things will differ to others.
As an interviewer and candidate evaluator, sometimes it is fairly clear from just a subset of interviews that a candidate is one we should make an offer to. But sometimes there are one or two interviewers who just did not get enough signal to be comfortable to hire, but the remainder made up for that. Improving that situation is something I am trying (in my own, admittedly limited, way), so any insight would be appreciated.
Observing the process sourcers and recruiters go through to improve their quality has been very interesting to me. It takes time for them to calibrate to the role (just like interviewers), and while my Silicon Valley experience amounts to one company, my general impression is that many engineers at other companies just don't appreciate the effort they go through to calibrate to the role, and many engineering departments don't put in the effort to help them get to being great.
While there are occasional dips in quality as sourcers and recruiters try new strategies (maybe going deep on release engineering talent in the games industry in Alabama), I'm willing to accept this because I understand that they're trying to get better at what they're doing - it's just like they don't (seem to) get angry with me when I fail to get good signal on whether a candidate is good or not, possibly because I was trying out a new question.
Assuming that the problem was a lack of quality AND that this is the recruiting team's fault sounds unjustified - I assume that Google takes recruiting seriously and puts at least as much effort into calibrating their recruiting team as they do on calibrating their engineers for interviewing.
Basically all software engineers (including some whose titles aren't Software Engineer, and including managers) go through this six week process - first four weeks is mostly getting people up to speed through two or so presentations a week and doing real tasks (which may mean meeting up with some other engineers to understand enough context on how to proceed) that go through the same review and push process as everyone else, and the last two weeks is mostly learning about specific teams and a bit of a sell exercise through a set of presentations.
All through this, you share a software engineer mentor with two other bootcampers who helps you navigate the code repos and also the company.
At the end, the bootcamper decides what team to work on, with some background information like company priorities and maybe with some teams specifically reaching out to them.
That's a fairly huge investment, so I'd love to know which other companies offer this sort of program.
I consistently do two-ish phone interviews or on-site interviews a week. I'd say 2 hours is a little on the high side for average time per candidate (probably around 1.5 hours), but it does happen. I am sometimes called in to do tiebreaker interviews (before or even after on-site interviews), or requested for particular candidates. I occasionally help other groups (capacity engineering, software engineering, operations engineering) with their interviews on top of my usual load. I've flown overseas for people who can't easily get US visitor visas. I'm in the top 5 interviewers by quantity for the role (which isn't too hard, admittedly), and in the top few percent of the company (I even got some ice cream as thanks!).
In addition to interviews, I also spend an hour a week in a recruiting meeting trying to improve our recruiting process (including giving feedback to our interviewers on how to improve their interviewing and feedback). And I've done non-interview recruiting at universities (manning booths at career fairs, mentoring at hackathons) and conferences (at Velocity, SCALE, Surge, PyCon just in the last year).
My feeling about spending 4-6 hours a week on interviewing and recruiting activities is that it is some of the most valuable work I can be doing. Avoiding a false positive - ensuring we maintain a consistent high bar - is going to save people in my group (and others in the company) potentially hundreds of hours. Making a great hire is going to add thousands of hours of productivity to my group and the company.
And we're a small enough group (and even a small enough company for the non-PE hires I've helped with) that I can easily keep track of the people I've helped hire and it is supremely fulfilling.
In my experience, the top-tier developers enjoy challenges and solving problems, and languages are just tools they use to defeat those challenges and solve those problems. Sometimes it's a language they really enjoy using. Sometimes it's a situation where that language isn't a suitable one.
The PHP development environment at Facebook is unlike that found at any other company I'm aware of, and common PHP pitfalls and legacy code are actively "linted" out of the system (as an automated part of the code review process). It still wouldn't be my choice of language to use outside of Facebook, but I have no issue working on the PHP code base here (although I rarely venture into it).
Over time, much logic and processing has been offloaded to backend services, with PHP increasingly playing a (largely parallelised) dispatch, post-process, and render role. That will likely continue.
With all that said, it is questionable whether it would be an investment to move off of it - which language/environment would you think a good target would be, and why?
As to whether it would have been possible to get better performance on HPHPc, I'll let people with more knowledge answer.
The benefit of having a single runtime for development and production (and production-like staging environments) is huge, though. There may also be benefits in the push process, which while fast when compared to most other companies, which will continue to deliver benefits for increased speed.
It looks like the search matches on job title/position, and not content. That does seem a bit unexpected.
In general, Facebook does not place much emphasis on programming languages that people know before they start at the job, and part of the Bootcamp process includes the expectation that people will be learning at least one language they don't know (unless they already know C++, Java, PHP, and Python at a production-code-writing-ability, and then they'll have to learn our libraries anyway).
We obviously discuss the languages we use and what we use them for during the hiring process so that people know what they're getting themselves into - people might be looking for something familiar to ease themselves into it, or they might be looking to explore a new language when they start.
(Yes, we use Python for a bunch of stuff. And I know we had a few people working on talk abstracts for PyCon to try meet the deadline that explore a few ways we use it.)