4 ms·

I think it's a bit odd thinking of programming languages as a career option. I work at what's one of the biggest if not the biggest single employer of Perl prog

by avar 12y ago

I think it's a bit odd thinking of programming languages as a career option. I work at what's one of the biggest if not the biggest single employer of Perl programmers (Booking.com), and we don't specifically hire people with prior Perl experience. We hire people with relevant programming experience and bring them up to speed on Perl. Anecdotally we've hired people who've had years of Perl experience who haven't done all that well, and people who've had no prior Perl experience who've just picked it up on the job and been very productive contributors within days or weeks. The unstated assumption with articles like these is that you'd be losing out if you don't get experience with the "winning" platform, but in my opinion a much better way to become a good programmer is to get experience with a wide selection of toolsets and programming languages. Even if none of those toolsets are widely used commercially. Having said that if you're interested in Perl as a career choice we're always hiring :)

fennecfoxen 12y ago
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
- avar 12y ago
  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_up_with_bookingcom/ccaemqk 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.
  - fennecfoxen 12y ago
    > 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. :)
  - borkur 12y ago
    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.
BugBrother 12y ago
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.
- avar 12y ago
  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.
  - BugBrother 12y ago
    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.
collyw 12y ago
>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.
- saidajigumi 12y ago
  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".
cyorir 12y ago
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.
peterwwillis 12y ago
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.
- thaumaturgy 12y ago
  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.
  - peterwwillis 12y ago
    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.

by avar 12y ago

fennecfoxen 12y ago

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

avar 12y ago
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_up_with_bookingcom/ccaemqk 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.
- fennecfoxen 12y ago
  > 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. :)
- borkur 12y ago
  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.

BugBrother 12y ago

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.

avar 12y ago
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.
- BugBrother 12y ago
  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.

collyw 12y ago

>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.

saidajigumi 12y ago
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".

cyorir 12y ago

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.

peterwwillis 12y ago

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.

thaumaturgy 12y ago
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.
- peterwwillis 12y ago
  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.