Why, exactly? PHP, node, Ruby, Java, .NET, and Python are all capable tools with mature webapp frameworks. In terms of capabilities, the differences between them only matter for a small and rare set of projects.
They could have decided on one of these platforms by rolling a die and it would have little direct impact on their success or potential.
Presumably, the actual criteria was likely familiarity and fluency for their tech founder or early developers. This familiarity and fluency matters 1000x more to success than the differences between these frameworks.
Given that all the tools are mature and capable, having a team work with tools they know is a lot more valuable than handing them tools that they'll be learning how to use as they go.
> Presumably, the actual criteria was likely familiarity and fluency for their tech founder or early developers.
That would be a completely valid answer to the question. The fact that they didn't answer the question at all is the problem here, not that they chose PHP.
In this metaphor the colour of the wall is equivalent to the product. The code is equivalent to whether the painters used brushes, pads or rollers or whether they used ladders or scaffolding - the customers do not care.
By asking why choose php you are asking why use rollers to paint.
If that's the case, asking about the choice of implementation language sounds like asking about the spec.
The end user does not care about the programming language.
Then... why is it so hard for people to just answer like that? It's a perfectly acceptable reason, but often (like the GP in this subthread) I find people won't actually answer like that. They'll try to come up with weird justifications re: technical merit vs competing tech, and I've found their specific examples might be demonstrably wrong or are just fancier ways of saying "this was a personal preference".
What's been lost in all this discussion... the state of the code. I'd much prefer a stack in XYZ with some tests, sample data, repeatable steps, etc. vs a stack in ABC without any of the above.
Did you think to ask why they were using windows instead of macs? Or why leather seats?
What were you hoping to get out of your question? Did you want to show the interviewer how hype you were? Were you hoping that you could educate them why using a javascript would be better? This was at an interview correct (not over beers with friends)? Curious how did your next interview go? Have you found work in the field? Are you working with a js framework.
Even if they weren't the person that made the choice, them knowing the reasoning behind the choice tells you a lot about the team. I usually expect new members of teams to ask questions about why the application was written the way it was. This shows a general curiosity among team members and it shows that the team can transfer knowledge to each other.
Knowing why they made decisions I might not agree with helps me decide how the team makes decisions in general. Is there one manager that decides things without input? Does the whole team give input and decide democratically? Are they saddled with technical debt from the co-founders last failed startup that's 10 years older?
Most places would say because it's faster or why would you use anything else? Not give you any company history.
Ask who makes technical decisions. Or what debt structure they have. Not why they choose aws over azure.
And you clearly misunderstood what they meant by technical debt.
This place uses php. It's in the job description (either that or the parent had no knowledge of what the company did before the interview) so the discovery should have happened earlier in the process.
By asking that question in that way the parent poster is signaling that he is modern but at the same time saying the company isn't modern by phrasing it that way. Wanting to understand how a company makes decisions is valid. Making judgement statements through questions is not valid.
And yes misunderstood company for technical debt reference.
Am I being irrational?
I just want somebody to make a decision, and if it is wrong, we learn, and try something else.