In all of my experience, which is a long time indeed, this rule remains unchanged. Your mileage may vary. (Put me into whatever category you please. I don't mind...)

Some languages are fundamentally different in their approach; Prolog is an obvious example. But the vast majority of languages in common use today do implement exactly the same solution to a problem and exactly the same methodology for solving it ... with only superficial variations. Obviously this statement is intended to use a h-u-g-e broad brush, because those “superficial variations” are quite numerous. Taking a garden-variety Perl program and implementing the same algorithm in PHP or Ruby would not be extraordinarily difficult. (Not pleasant, I grant you, but not difficult.) It's going to turn out to be a comparable, procedural, program. Likewise, “implementing a substantial project,” say an ordinary web-site, is once again going to be a comparable task... after the usual learning-curve nonsense is over-and-out.

Lurking beneath all of these languages, and the brief challenge of becoming sufficiently-conversant in any or all of them, is ... the experience of knowing what to do with them and how.

You can spend years “working,” and never find that you are “working well.” You can find that you are not really growing. You can spend years in a company where no one around you really knows how to manage a project, so you might come away thinking that 60 or 70 hour weeks are quite-the-norm. You can do this, getting paid but getting nowhere, and throughout all this (and perhaps in spite of it) you are easily able to “ace a technical interview!”

When I'm interviewing, I want to hear you talk. Not about this-or-that language... I want to hear you think.