Hacker News Reader

I completely agree with this. In some cases focusing on a single language or set of languages can be a good idea - especially when it is a language in high demand and it means you know the ins and outs of a lot of different frameworks a la javascript. However, there is no downside to studying a lot of different languages because it gives you general experiences that you can apply to other languages, it helps you pick up new languages and toolsets, etc. The most basic example is that a programmer who only works with imperative languages should dabble in at least one functional language, because that can change the way you view algorithms, data structures, and overall program layout.

>I think it's a bit odd thinking of programming languages as a career option. Look at 99% of the jobs ads out there and they are looking for specific languages.

Agreed, but reading between the lines of these ads, there's a world of difference between an ad which is "we're looking for a great developer who will use <language X> to do [...]" and "we're looking for a <language X> Developer".

In my experience, the latter presentation tends to actively drive away the best candidates, and communicates a lack of understanding of the job to be done. This is not an absolute; sometimes you really do need a specific skillset. For example, one great company I worked at almost universally hired solid developers regardless of particular checkbox skills. We knew that the good ones would come up to speed, and we'd often benefit greatly from cross-pollination from differing backgrounds. However, there were definite instances where we needed a true specialist, e.g. in a specific, deep platform UI framework. Then we sought and found solid developers who were also top of their game in the needed skills.

In the latter ad copy above, a "<language X> Developer" often has the connotation not of a targeted specialist hire, e.g. "expert in <language X>". Instead it comes across as lazy recruiting: "warm body who checks off this box".

It seems to me that doing something as a career, you're expected to be really good at it. There's no way anyone can just pick up Perl and write good Perl code without a dozen best practice errors. Hiring someone who doesn't know Perl very well basically guarantees a high rate of bugs in your codebase.

Most of the traits that make good Perl code are the same traits that make good anything code: concise but readable, sensible naming conventions, useful comments, sensible logical structure that's not too complicated.

There are certainly a lot of things about Perl that are unique, but some time with the camel book and a few weeks of practice should sort that out for anybody with several years of production experience in another language.

There's nothing obvious about how to use persistent nested variables, or how to assign key/value pairs to a blessed file handle typeglob, or the difference between calling a package subroutine as either a method or a function. The more complicated your data structure gets, the more convoluted ways you can reference it. The subtle yet different ways to do the same thing (or almost do the same thing), like int@_ vs $#_ . Does the camel book explain the magic of $VERSION? Sure it's documented, but you'd have to read every perl doc to finally get to what it is and how it works, and then somehow remember its quirks amongst the pages and pages of docs you just read.

Evaluating true and false, or just simple comparisons, can be a mystery. Heck, just figuring out what's going to be a syntax error or not depending on if a variable was declared, defined, interpolated. Or referencing a nested data structure when one of the elements doesn't exist. Even just general conventions and best practices fills its own O'Reilly book. We haven't even begun talking about regular expressions.... Then there's the autoloader, and constants, namespaces, scalar/list context, signal handling, ....

Part of the difficulty of Perl is that you can write code that works perfectly until the clearly-obvious hole you left is triggered and a fatal error occurs, and then you get to learn about the debugger. It takes years to use all the parts of Perl that have weird magic or complex, non-obvious functionality tied to them. Saying you could use it all without problems after only a few weeks is really misleading.

The fact that there is a "strict" mode at all speaks to how difficult it can be to get the language right.

It has honestly been well over a decade since I last touched Perl (not that I'd mind going back to it), so I can't say much to most of your specific criticisms.

But, evaluating true and false in expressions is tricky in a lot of languages now. PHP is notorious for it. That's why you shouldn't mix data types. Regular expressions are no longer the sole domain of the Perl hacker, they're a regular staple of JavaScript and PHP and the commandline and other utilities.

Look, here's the thing: the response to avar has pretty much been, "you guys are doing it wrong", which is a seriously uncool armchair quarterback thing to say to someone else, especially someone that's a part of something as big as booking.com. If in fact their hiring process was as unutterably broken as you seem to believe it is, wouldn't you've expected their business to collapse in a pile of inscrutable bugs by now?

I'll readily agree that there's a vast difference between a coder in any particular language, and an expert in that language. That's why the experts get to define the language conventions used by a business, and the coders get to follow them. That's why there's testing and debugging and staging.

I try to assume least level of incompetence in other people on HN. Maybe instead of declaring things about their code base that you have no actual knowledge of ("There's no way anyone can just pick up Perl and write good Perl code without a dozen best practice errors. Hiring someone who doesn't know Perl very well basically guarantees a high rate of bugs in your codebase."), you could instead ask, "How do you guys handle training the guys that aren't very familiar with Perl quirks like int@_ vs $#_?"

I've worked at lots of places with really lame hiring and people just get stuff done. They also get stuff done with lots of bugs, which costs the company time and thus money. So inefficient hiring process does not mean your business folds, but it does mean your business may suffer.

And i'm not assuming any level of anything. If you learned spanish in Spain, you can't just go to Mexico or Venezuela or Argentina and pick up the local dialects, because there's different grammar and vocabulary and pronunciation you won't know until you run into it. Trying to write a paper in those countries after only using their dialect for a few weeks will land you with mistakes. I don't think this is a controversial thing to say. (And this is assuming you're picking up a very similar language; trying to go from Spanish to Portuguese would be nearly impossible in just a few weeks)

Grumble, don't talk about e.g. JavaScript regexps. :-(

>>which is a seriously uncool armchair quarterback thing to say

Imho, you read too much into the discussion. Everyone knows that Booking.com must be doing a lot of things right for their particular problem set and situation. It is a high profile place that attract good talent. (I am hardly alone in assuming they aren't too stupid to listen to Ovid et al.) Their situation is unusual and the resulting specific differences in methods will be questioned, because of their high profile.

You're "always hiring", but your interviews are remarkably short on actually writing any code and if someone asks too much about your approach to maintaining software quality (in light of your cowboy-coder reputation) you'll question whether they're "pragmatic" enough to work there and lose interest. Which I guess was probably things working out for the best, but Amsterdam was a fun city. Perhaps I'll find another employer there someday. Looking at London and Berlin in the meantime. :P

I quizzed my interviewers for about an hour on how Booking did things and why when I had my interview, and I still got hired. Besides, like everyone if we don't hire someone we don't tell them why due to liability reasons.

So if you had an interview and got rejected maybe it was for some completely different reason, I've certainly never heard about someone getting rejected because they asked too many questions.

You might get rejected because you don't seem like a good fit though. I commented on this a bit more specifically in a Reddit discussion a while ago: http://www.reddit.com/r/perl/comments/1mkdl4/what_exactly_is...

Anyway, it's unclear from your post whether you tried and failed at an interview with Booking, or whether you used to work there. If it's the former I'd be happy to help you with another try.

Like any employer we'd rather not hire one right person than hire ten people we shouldn't have hired, so statistically we reject some candidates that would have been good fits.

> If it's the former I'd be happy to help you with another try.

thanks, 'sgood. have an offer in Berlin, will be weighing it against a potential offer from London over the next few days. :)

I went through an interview process at booking two years ago. After the phone interview, they asked me to come to Amsterdam for a face to face interview. To arrange travel details, they asked me to send passport details (scan of passport info page).

Seven days after I sent them the passport scan I got an email explaining "While we impressed with your background and experience, we have concluded that other candidates' qualifications more closely match the requirements for this position.".

I guess my age wasn't a good fit.

Booking.com is a big place where newbies will be sitting with lots of experienced people they can ask and discuss with over lunch/coffee.

I doubt that smaller places will see so fast ramp up that they don't bother to hire people that know the language environment. The language in itself is quite irrelevant, but building a taste and learning the standard libs (here -- CPAN) takes time. That goes for every environment.

Edit: It would be interesting to hear the experience on this at other big shops? Maybe material for an academic article, someone?

Edit 2: I might add -- the differences between the scripting languages seems a bit overblown in the article. The languages (Perl, Ruby et al) aren't that different. Here I argued about the environment and standard libraries, which takes many, many hours for at least Python and Perl. And for taste -- to not have anonymous functions in Python needs changes in how you code. And so on.

Almost all the libraries you deal with are in-house. Which is part of what I'm pointing out, most of getting up to speed in any company is learning about their domain-specific codebase, not the language they happen to be using.

You're certainly at an advantage if you know some of those things already, that goes without saying. I'm just pointing out that many people seem to overestimate the impact of the programming language on the overall stack. Knowing DB workflows, distributed programming etc. is much more important than knowing language trivia which you can mostly trivially look up.

I don't disagree.

My point was, to take a simple example, at places like Booking.com [new] people will typically find out about the used CPAN Date classes from the code or their table neighbour. Not by rolling their own or crawling all of the CPAN before finding DateTime.

But sure, the internal code will be a bigger issue.