Amazing that they initially wrote this code and now to join FB you need to answer questions based on backtracking and dynamic programming. :) I wonder if they could do the questions themselves back then.
What do those things have to do with each other? Code can't use algorithms because it's written in PHP? I'm not following.
Facebook PHP Source Code from August 2007
21–30 of 99 posts
Re: Facebook PHP Source Code from August 2007
#22Amazing that they initially wrote this code and now to join FB you need to answer questions based on backtracking and dynamic programming. :) I wonder if they could do the questions themselves back then.
Good point. Is there anybody from 2007 still working at Facebook desperately scared they'll be found out for not being good at algorithms or are these people all in management now? ;)
It's also likely that even at the time the devs working on this wanted to start refactoring more - it's one thing to recognize bad code, having the muscle within a company to allocate resources to fixing that code is a different matter.
Re: Facebook PHP Source Code from August 2007
#23Can someone explain to a newbie why this code is so bad? Reading through it it seemed to generally make sense and not be too complicated.
Lots of global variables that can clobber each other (if one bit of code, even in one of the includes, redefines $user, everything explodes), no classes, no code autoloader...
Re: Facebook PHP Source Code from August 2007
#24Earlier quoted context omitted.
What do those things have to do with each other? Code can't use algorithms because it's written in PHP? I'm not following.
Because most of the time you don't get hired at FB for a specific team, you might end up working on PHP sure, but the interview process for SWE is general and they test you on algorithms regardless.
Although I will say I think dynamic programming is not a good interview topic. I think it's basically proxy for "got a CS degree from certain schools". But algorithms in general are valid to ask about.
I would almost say you need to understand algorithms better while programming in PHP because the language obscures certain things. Ditto for programming in JS -- for example to encode certain algorithms in JS you will run into the fact that it has only has floats, no ints.
People used to think you couldn't write algorithms in JS either. Now there are LALR(1) parser generators in JS, etc.
Re: Facebook PHP Source Code from August 2007
#25> Worth preserving as part of Internet history. Can't Facebook just issue a takedown request and have these files removed?
what for? It's not like it would be particularly dangerous to see code which is 13 year old.
Not sure how applicable that would be to Facebook’s codebase over this much time. But worth noting.
Re: Facebook PHP Source Code from August 2007
#26Amazing that they initially wrote this code and now to join FB you need to answer questions based on backtracking and dynamic programming. :) I wonder if they could do the questions themselves back then.
Dynamic programming questions are explicitly not used in current Facebook interviews. From time to time, Facebook and other companies study the effectiveness of their hiring process by comparing employee performance and interview performance. I believe dynamic programming questions were removed because there was not a strong link between success in this question and future performance.
Re: Facebook PHP Source Code from August 2007
#27Earlier quoted context omitted.
what for? It's not like it would be particularly dangerous to see code which is 13 year old.
It’s worth noting that Windows occasionally is inflicted by discovered vulnerabilities that are over twenty years old. Not sure how applicable that would be to Facebook’s codebase over this much time. But worth noting.
Re: Facebook PHP Source Code from August 2007
#28Can someone explain to a newbie why this code is so bad? Reading through it it seemed to generally make sense and not be too complicated.
Additionally I'd love to see that file split up into smaller chunks simply to lower the scope of thought.
It looks like nearly all of those function calls are modifying variables passed by reference instead of resolving the value out via `return` this isn't bad and is indistinguishable at a technical level in terms of functionality, but it's a kind of horrible approach from expressability.
They're doing things with datetime that are unsafe and wrong (like assuming 246060 is the number of seconds in a day) but people getting datetime logic wrong is as old as... well time.
Oh, and you've got some pretty bizarre looking function signatures - I'm sure there is a reason for this but I'd want to ask some questions about this one...
$permissions = privacy_get_reduced_network_permissions($user, $user);
It's possible to go through this and nitpick a bunch of stuff, it looks like it's mostly just an older style though. The big problems aren't here though... I'm not seeing any reads into $_POST (and `param_get_slashed` looks like a nice function for sanitizing input) - additionally, I'm not seeing a single line of SQL nor am I seeing any memcached calls, so the data access layer may already be well isolated architecturally.Re: Facebook PHP Source Code from August 2007
#29> Worth preserving as part of Internet history. Can't Facebook just issue a takedown request and have these files removed?
what for? It's not like it would be particularly dangerous to see code which is 13 year old.
Re: Facebook PHP Source Code from August 2007
#30Good job. And perhaps that's the culprit. Everybody assumed it was a plain syntax error, but I don't think it's possible. Rather, it seems me that:
if ($user 0 && ...