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.
> 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.
How times have changed!
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.
As long as it's relatively well organized, you can worry about refactoring as you scale up.
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.
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):
https://www.phparch.com/magazine/2003-2/june/
and having discussions like this (2004):
https://www.sitepoint.com/community/t/to-hopefully-clear-up-...
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.
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
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.
Code can't use algorithms because it's written in PHP? I'm not following.
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? ;)
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.