Not to mention that premature optimization may be bad, but even when you need it, it's better to just write a few algorithms and test them against real data.
Not to mention that premature optimization may be bad, but even when you need it, it's better to just write a few algorithms and test them against real data.
For example, if posed with the question presented here, if you realize it will not be as fast as you might hope, maybe you can make the choice to build a data structure with much less depth- maybe you can fit it all in a hash table?- and achieve huge performance wins without once touching assembler. (With a 27-deep tree, you need to make 27 reads from memory to find your data; reducing the depth reduces the required reads)
(I am not a computer scientist, and I am not an expert in algorithms, but hopefully I'm not too far off here.)
The others are correct.
The entire point of coding in a language like PHP is that you don't think about the low level stuff. And even if you did take the time to truly understand the source of PHP and made some fabulous optimization, they could change implementation details in a future release and break what you did.
Bottom line is that your interview question has almost no correlation with whether someone would be a good PHP developer. You might as well ask what the capital of Macedonia is as that is just as good of a screen for potential applicants.