Facebook uses Hack. Hack is to PHP what C++ is to C, sort of. You can take PHP code and run it as Hack code, sometimes, but there are lots of reasons why PHP code might not be valid Hack code these days (Hack has diverged from upstream).
Across n languages you have m libraries that need to be maintained. As new languages are introduced or as existing ones gain market share, the maintainers of old libraries are stretched thin. You need to have n*m maintainers, and the number of concerns to keep track of continues to grow.
Perl has fallen. Fortran is legacy. Ruby isn't as hot as it once was.
At some point, new people won't want to learn an old language. This is when a language begins to wither away.
It will happen to PHP. Eventually (in the technological limit) it'll happen to everything.
It depends on what you mean by elitism. Languages are not undifferentiated, it is perfectly possible to talk about some languages being "better" than other languages, especially when you are talking about specific tasks.
The parent doesn't make any reference to PHP programmers, and doesn't appear to be looking down on any person or class of people, so this doesn't seem to be the embarrassing brand of elitism.
There are precious few good reasons to use PHP in 2021, a world of much better languages with much stronger ecosystems than the world of two decades ago when PHP was a reasonable choice.
It's hilarious and reflects incredibly bad upon author.
C has more problems than PHP, yet as with PHP, it is dominant worldwide.
Just the linux kernel alone, its scope, forks, usage makes C god.
There are always a lot of "but!" statements to this reality, but they don't change fact.
PHP, modern PHP is a different beast than a decade, 20 years ago. Imagine if C took on some of the properties of rust, but was still just called C. And used as C.
Not a PHP developer myself, but in my area most web development is still done in PHP. The modern PHP language is a lot like any other high level language now, but the main attraction of PHP are (still) the massively popular (and stable) open-source frameworks such as Symfony, Laravel, WordPress, Magento etc. A big supply of developers and high development pace of custom apps through such frameworks is why it will remain the defacto choice for a lot of webdev shops (at least in my area).
I've been to a lot of interviews and this seems like terrible advice. Besides a few behavioral questions the vast majority of interviews are algorithm and data structures questions. Memorizing a bunch of obscure, unpopular object oriented jargon seems like a waste of time. Is this a php thing?
More like a certain subset of company. I've seen this sort of "trivia/jargon" interview primarily at non-tech or non-tech adjacent companies. think like F500's far away from the tech industry.
To be fair stuff like Design Patterns, SOLID, Domain-Driven Design etc. come up in a lot of interviews for "business application development" roles in other languages as well, especially C# and Java. What's ironic is that often on your first day on the job, you'll be put to work on a codebase which violates those principles in a lot of ways.
> To be fair stuff like Design Patterns, SOLID, Domain-Driven Design etc. come up in a lot of interviews for "business application development" roles in other languages as well, especially C# and Java.
Yea. I think there are basically two style of techincal interviews. One is FAANG where they ask you university level stuff. And the other is they ask you a bunch of stuff that they want to have implemented but haven't.
I think it's also why there is a massive culture difference in say Agile in FAANG and everywhere else. FAANG has people that don't know these things as well because to get their jobs they had to learn and study univeristiy level problems.
I think a lot of FAANG devs would get blown out of the water at some mid-level companies. FAANG has the reputation but the reputation is built on a very small subset of their actual engineers.
First of all the title is wrong. Everything mentioned in the article is specific to Php. Secondly, interviews are more algorithm/system design specific rather than being asked what are the new features in latest version of a language.
I completely get that point. I have had that happen to me as well in the past. But since 6 years, whenever I have been to an interview I have never been asked questions so tightly coupled to a language as the article suggests. I have been asked a few questions related to instances where a language doesn't behave as expected. Like `typeof(null)` in js or `1+'1'`. But nothing very very specific. Mostly general questions tend to be more around protocols, design patterns and stuff.
But nothing is for sure. Maybe these questions are still very relevant and it's just that I haven't come across them in interviews recently maybe?
I've done a ton of technical interviews in my career. To be honest, I thought all of the advice in this post was pretty awful and I'm surprised it is upvoted so high.
Most of the questions in this article are of the "Are you aware of feature X or buzzword Y" type questions. In my experience there is basically zero correlation between people who can answer questions like this and how they actually do on the job. If someone is not going to hire me because I haven't heard the term "Open-Closed Principle" in 20+ years of software engineering, this is definitely not a place I want to work.
Do people out in the industry care about these designpatterns? I'm studying a software engineering course right now and part of it is knowing what things like Open close principle and dependency inversion are. It just feels like jargon to me
Care about design patterns, yes. You have two kinda of tech interviews. You have the algorithms ones and according to nearly every review I've heard of people accepting those jobs they don't do algorithms. These are normally FAANG, etc based. For those read cracking the interview or just do what you're doing at your engineering course. Because again as everyone says it's basically that level of knowledge that is required to pass them. The reason people need to study for these are they're basically exams for knowledge you don't use day-to-day but learn at uni.
Then you have ones where they care about SOLID, DDD, etc these are normally Java/PHP/Kotlin jobs and more mid-level and enterprsied based. Also project recovery agencies also use these. These care about production knowledge and what you can actually do. These require experience to pass.
In my experience the main difference between the two styles is companies that have a massive reputation and can afford to reject lots of compentent people do algorithm tests. Startups who think they're cool also do them at the start. These companies can also afford to have lots of developers who can't actually do high level work because most of their work is very basic and the hard stuff is dealt with by others.
Companies who need a large percentage engineers to come in and do hard things and deliver real value will care about your ability and knowledge to write clean code over your ability to do university level quizzes.
I would agree those terms are "jargon", but in this case a legitimate use of it. The concepts are important, and warrant the creation of such specialized vocabulary.
I have...been asked maybe one of these questions, and that when I was interviewing for an internship at a defense contractor. None of the others have ever come up. Even the place that used DDD (badly) didn't ask about it during the interview.
Now, to be fair, I -have- asked if a person is familiar with CAP. But only as a way to determine if that is a relevant communication framework for discussing distributed problems/solutions; a "I haven't" isn't a ding against them, but a place to provide some context for the upcoming questions around distributed system tradeoffs.
There's a LOT more than the tech side to a technical interview... in fact, I barely see folks fail the classically technical part, but rather because of things like jumping too early to solutions, not asking clarifying questions, can't articulate their thought process, etc. - here's a post about what else is important: https://leadership.garden/acing-the-tech-interview/
Confession time: I'm a top-level engineer in a web development company who uses PHP every day. I have two degrees. I seriously couldn't answer most of those interview questions to save myself.
I've never used Docker, Node, Nginx, or most anything else made in the last decade.
Am I a shitty developer? Am I a cheat? Am I an imposter? No. I simply don't give a shit about learning the formal way to do things when the work I do on a daily basis doesn't require it.
Let's be honest: the vast majority of PHP web development boils down to "echo", "foreach", and database access (PDO). It's essentially a bunch of CRUD operations. Architecture and system design is usually abstracted away by existing frameworks.
If you're only editing existing websites and not building modules which actually get shipped to end users, then you're really just doing the grown-up equivalent of editing a MySpace template.
If you believe that being able to recite answers to questions like this makes you a good developer... then you probably also believe that it's possible to get a University Degree in 3 Minutes.
From Episode 6, "The General":
Number Twelve: What was the Treaty of Adrianople?
Number Six: [looks a bit puzzled, but answers automatically] September... 1829.
Number Twelve: Wrong. I said "What," not "When." You need some special coaching.
30 comments
[ 5.9 ms ] story [ 89.0 ms ] threadLOL!
Facebook and Wayfair are using it among https://trio.dev/blog/companies-using-php
https://en.wikipedia.org/wiki/Hack_(programming_language)
Perl has fallen. Fortran is legacy. Ruby isn't as hot as it once was.
At some point, new people won't want to learn an old language. This is when a language begins to wither away.
It will happen to PHP. Eventually (in the technological limit) it'll happen to everything.
The parent doesn't make any reference to PHP programmers, and doesn't appear to be looking down on any person or class of people, so this doesn't seem to be the embarrassing brand of elitism.
There are precious few good reasons to use PHP in 2021, a world of much better languages with much stronger ecosystems than the world of two decades ago when PHP was a reasonable choice.
C has more problems than PHP, yet as with PHP, it is dominant worldwide.
Just the linux kernel alone, its scope, forks, usage makes C god.
There are always a lot of "but!" statements to this reality, but they don't change fact.
PHP, modern PHP is a different beast than a decade, 20 years ago. Imagine if C took on some of the properties of rust, but was still just called C. And used as C.
That's PHP, you bunch of hosers!
More like a certain subset of company. I've seen this sort of "trivia/jargon" interview primarily at non-tech or non-tech adjacent companies. think like F500's far away from the tech industry.
Yea. I think there are basically two style of techincal interviews. One is FAANG where they ask you university level stuff. And the other is they ask you a bunch of stuff that they want to have implemented but haven't.
I think it's also why there is a massive culture difference in say Agile in FAANG and everywhere else. FAANG has people that don't know these things as well because to get their jobs they had to learn and study univeristiy level problems.
I think a lot of FAANG devs would get blown out of the water at some mid-level companies. FAANG has the reputation but the reputation is built on a very small subset of their actual engineers.
For FAANG type places sure, but not everyone runs their interview process with that content.
Anecdata: I interviewed at a bank once and they wanted to know how specific library functions were implemented in a specific programming language.
But nothing is for sure. Maybe these questions are still very relevant and it's just that I haven't come across them in interviews recently maybe?
Most of the questions in this article are of the "Are you aware of feature X or buzzword Y" type questions. In my experience there is basically zero correlation between people who can answer questions like this and how they actually do on the job. If someone is not going to hire me because I haven't heard the term "Open-Closed Principle" in 20+ years of software engineering, this is definitely not a place I want to work.
Then you have ones where they care about SOLID, DDD, etc these are normally Java/PHP/Kotlin jobs and more mid-level and enterprsied based. Also project recovery agencies also use these. These care about production knowledge and what you can actually do. These require experience to pass.
In my experience the main difference between the two styles is companies that have a massive reputation and can afford to reject lots of compentent people do algorithm tests. Startups who think they're cool also do them at the start. These companies can also afford to have lots of developers who can't actually do high level work because most of their work is very basic and the hard stuff is dealt with by others.
Companies who need a large percentage engineers to come in and do hard things and deliver real value will care about your ability and knowledge to write clean code over your ability to do university level quizzes.
Now, to be fair, I -have- asked if a person is familiar with CAP. But only as a way to determine if that is a relevant communication framework for discussing distributed problems/solutions; a "I haven't" isn't a ding against them, but a place to provide some context for the upcoming questions around distributed system tradeoffs.
I've never used Docker, Node, Nginx, or most anything else made in the last decade.
Am I a shitty developer? Am I a cheat? Am I an imposter? No. I simply don't give a shit about learning the formal way to do things when the work I do on a daily basis doesn't require it.
Let's be honest: the vast majority of PHP web development boils down to "echo", "foreach", and database access (PDO). It's essentially a bunch of CRUD operations. Architecture and system design is usually abstracted away by existing frameworks.
If you're only editing existing websites and not building modules which actually get shipped to end users, then you're really just doing the grown-up equivalent of editing a MySpace template.
What is the Open-Closed Principle?
What is Liskov’s Object Replacement Principle?
What is the Interface Segregation Principle?
If you believe that being able to recite answers to questions like this makes you a good developer... then you probably also believe that it's possible to get a University Degree in 3 Minutes.
From Episode 6, "The General":
Number Twelve: What was the Treaty of Adrianople?
Number Six: [looks a bit puzzled, but answers automatically] September... 1829.
Number Twelve: Wrong. I said "What," not "When." You need some special coaching.
https://www.imdb.com/title/tt0679186/characters/nm0001526