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.
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.
That's super cool, do you know if any of those results / methodology were every publicly published? I've been trying to find prior art in interview analytics and data driven hiring in general to try to improve things at my current workplace.
There was a point in time (roughly 2015-2016 timeframe when dynamic programming interview questions were really in vogue. Every interview loop from smallish startup to leviathan corporation felt like it had at least one.
This sounds very counter-intuitive! Did you hear this from someone working at Facebook or did you read it online? If it's the latter it'd be great if you could share a link!
> It also has a very interesting property as an adjective, and that is it's impossible to use the word dynamic in a pejorative sense. Try thinking of some combination that will possibly give it a pejorative meaning. It's impossible.
I don't exactly understand why this is getting downvoted, I'm genuinely curious if companies have published anything on that.
Also for me, it _is_ counter-intuitive, since DP was one of the hardest things for me when I started with programming, and I'd at least expect a non-trivial correlation between being good at DP and job performance, that's why I was asking about where I can read more about this.
I used to know PHP, and this code is very indicative of the imperative style that was popular during that era. I believe the PHP crowd has mostly gone deeply into OOP. With that said, Facebook mostly worked remarkably well. My bank, on the other hand has their web presence written in Java. And it works about 80% of the time. Sometimes one just has to try twice. So, "good code", "bad code" will always take a back seat to "working code". (Not that I'd want to maintain this beast)
I guess what's really at play is whether or not the code is sloppy because the developers are making a conscious decision to not refactor yet, or it's sloppy because they don't know what they're doing.
I've found lots of great developers write huge, sloppy, 300 line methods, if it gets the job done. I love clean code, but too much abstraction is a liability unless there's a good reason to introduce it. Part of expertise is knowing when it's okay to break the rules.
But, no, that's not at all what I'm saying. I'm saying, one language is extremely well thought out, and offers great guard-rails for doing OOP very well. And yet, the code is broken enough that sometimes I just have to give up on getting my account balance. Yet, Facebook from that era typically "just worked"... except when it didn't, and everyone would lose their minds. My point was, code that works, even if ugly, is what the customer cares about.
I'm still on the fence if I'd recommend anyone use PHP... Swoole performs very well. Laravel has a great community. It's not my cup of tea but, I try to keep an eye on it.
It is 12 years old - these were just before the first versions that had any kind of serious OO capability, however most apps were already built in the "Imperative" style that this is.
The hate for PHP on that gist is strong - admittedly back in the early noughties it wasn't fantastic but it was the shortest route to getting a functional website put up. PHP was simple and had a very low barrier to entry.
Latest versions are much better - The speed is one of its biggest draws, since version 7 it has taken the crown as fastest interpreted language, I believe version 8 will improve on this even more
> It is 12 years old - these were just before the first versions that had any kind of serious OO capability
PHP5 is the release where most of the OO improvements happened (but even PHP 4.3 had a bunch) and PHP 5.0 was released 3+ years before this code snippet leaked.
I wrote a heavily OO based version of Yahoo! Address Book using PHP 5.1 in 2005-2006, so it was definitely doable and fairly common to do so by that time.
It uses global variables all over the place and includes other files and variables can start stepping over the others. PHP had class support since 2004 (code seems to be from 2007) and they just write function names in global space with bad naming like "redirect" where you can't tell which part of the system it's from.
The whole code is written top to bottom without breaking them up into functions for clarity. You can't even tell which variable is for local use and which is meant to carry some state further down the lines.
Comments are joke too when you read words like "holy shit", "cool stuff", "FIXME?" and "retarded", you can guess the programmer isn't really a focused person and comments read like a personal note instead of trying to give clues to others.
A good code is a code that you feel like maintaining on first sight and this apparently is far from it.
Well ... this 'joke' code created a multi billion dollar business and sowed the seed for a platform that is shaping our world in ways unimaginable (in more harmful ways than good, but that is beside the point) ... you can't complain!
"relatively well organized" is the problem. It's written in a fairly unstructured imperative style that's perfectly suitable for short scripts, but even these relatively small pieces of code are outgrowing it. The extensive use of global variables is an obvious thing that I would expect to become a problem soon. It's much less of a problem in php than in most other web frameworks due to the design of handling each HTTP request in a fresh process (so things like the use of $user in both index.php and search.php can't conflict), but it's still quite fragile.
By the standards of 2007 PHP this is good code, and today there's probably lots of worse PHP being written (even if the community as a whole has moved on quite a bit).
By the standards of early 2004 (when Facebook was originally written) this is still mediocre PHP. People who cared about writing good PHP were reading magazines like this (2003):
They knew global variables and hundreds of lines of top-level code were bad PHP, they just didn't know yet that trying to ape Java wasn't good PHP. If I remember correctly, DHH came out of this period: he got so sick of enterprisey PHP that he jumped ship to Ruby and wrote Rails. That was 2005.
Fair enough that Facebook hadn't done a major rewrite by 2007, but still: not good code.
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.
Your post seems to indicate that "working on PHP" and "algorithms" are disjoint. Why? If you're writing code with many users, then algorithmic knowledge helps, regardless of language.
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.
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? ;)
The way that technical learning works... if they aren't stubborn (and probably fired because of it) then they've likely adapted. Developers grow in knowledge over time as they hone their craft and every senior dev can easily call up some terrible crap they wrote when just getting started.
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.
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.