I'd like to collect some opinions about the following things. I am
referring to some of the recent posts on linked-in, about recruitment
and the lack of "great programmers".
A bit of history in my (possible distorted) view:
When
OO appeared there were debates on the fact that has certain
disadvantages over procedural like speed and being more verbose (over
the advantages of allowing abstraction and allegedly being better for
organizing huge code).
Then, in Perl's world, there were voices
saying that one should not bother to learn OO perl because it is not a
real OO, it is more a set of cumbersome conventions than a proper OO
implementation.
Finally Moose appeared and practically defined a sub-language, a lot of "sugar" to overcome the base language OO limitations.
Now
everybody jumped happily in Moose's boat and no-one talks about
procedural Perl and, more important, they don't accept anymore
procedural at interviews.
Like OO Perl is more than just another way to structure Perl code.
I call "There Is More Than One Way To Do It" in my support. True, I read somewhere: "Because TIMTOWTDI, don't assume that you can do it any way you want" but I tend to disagree for most of the situations.
In
my opinion, the main purpose of any application is to meet the specs
and also to be done in the allocated time. If you think of the
application as a black box, and you managed to make it work as expected
and tested it thoroughly from any angle, I really don't understand why
would anyone would care *how* it is inside the black box. Is like, you
can hit a nail with a hammer or with a pair of pliers and to a certain
extent the outcome will be the same, depending of the wood's resistance.
Of
course, when it is about interacting in a team and if there is a
defined programming style, the applicant should converge to it, to
respect the house rules. Still, it doesn't mean that procedural Perl
should be a reason to reject a candidate at technical interview time.
It
seems that only few companies are still willing to allow time for
learning and they all ask for guys that can "hit the ground running"
(again, mind you, we talk about a style not about core programming
skills). But no one can know everything needed at the new job already.
If (s)he knows everything, there is a chance (s)he might be tempted to
look somewhere else for a challenge.
I think that's
why a lot of recruiters/companies complain about the fact there are not
many "great" programmers on the market. (BTW: Define "great". How? By
compiling a list of technical questions that all "great" programmers
should know? This might be a wrong approach. See http://it-quirks.blogspot.com/2012/10/modern-perl-recruitment-contd.html).
I
bet there are lots of good Perl programmers but they get rejected (and
possibly going to other languages) because they were considered as not
fitting the target company's programming style. The companies are
incredible picky these days about the style, and the middle layer
(agents) is escalating this much more by not knowing what's really
about.
And then the advertised job stays on the market
for 6 months or more and the agents and companies, at unison, lament
about the fact that "great" perl guys are a scarce resource. Maybe
giving a chance to any Perl programmer that can do the application no
matter the style, would be more beneficial for the company. Put in
balance the 6 month fishing for the "great" programmer versus few month a
"regular" guy can learn the new environment's specifics, style, etc.
Maybe it is time to admit that we're not so many out there, therefore you need to be more flexible. Otherwise, wait.
I'm
not trying to diminish the importance and role of OO Perl or Moose. I
would just love that the recruitment wouldn't be so exclusive about it
nowadays, because things can be still done very well and fast, the
procedural way. Besides I don't think that it'd take more than few weeks
for someone to adjust from procedural to OO style of the company. Not
to mention that OO design sometime is a separate job in many companies,
and in the end the programmer ends up writing code inside the same
class, not needing to know the big OO picture.
So, how hard you think it is for an "regular" perl programmer to switch from procedural programming to Moose?
Monday, 15 October 2012
Sunday, 14 October 2012
Modern Perl recruitment - cont'd
This is in response to some recent posts on linked-in, some of them leading to http://www.modernperlbooks.com/mt/2011/01/how-to-identify-a-good-perl-programmer.html
I think compiling a list of questions for the recruiters to ask for when filtering candidates is wrong and irrelevant for few reasons:
First of all, the weight of each question in the list should be judged in the context of the particular job requirements. No-one knows everything about Perl (maybe with few exceptions, see below the "top N").
Then, the weights of two questions could appear comparable to the recruiter and the candidate could get rejected based on wrong assumptions. Take these 2 examples from the list:
"What's the difference between == and eq?"
-- versus --
"Where do tests go in a standard CPAN distribution?"
One one side, if a programmer doesn't know the difference between == and eq, then we might have a problem (still debatable if the guy is coming from lots of years experience in PHP for example).
On the other side even an experienced programmer might have never been in the situation to care about the tests in the cpan distributions: if everything installs correctly and never created a CPAN module, why should one bother?
You can find more pairs of "extremes" in the list to prove this point.
The list also proved its limitations as a lot of people on linked-in already started to ask for clarifications. Assuming that someone really fixes the list's "bugs" as feedback is received, discussed and changes agreed on, probably endless iterations will be needed.
As for the relevance of asking somebody these questions, as the present list's answers can be found in only one book (Modern Perl), if anyone really wants to fool the examiner can do it by just reading this quite small book. Even easier, any perl wannabe can find now the list on the internet and can prepare the answers for potential future interviews.
Finally, knowing everything about perl is quite impossible: everyone has strong areas and weak areas and the capacity (or lack of) to improve in the weak ones if the job requires it.
Not everybody is Larry, Damian or Randal (and the list might continue to a top N). On the other hand not every company would need (or afford) any names from this shortlist. Bothering one of the top N programmers to write scripts for a company that sells ladies bras, briefs and stocks would seem a bit out of proportion, much like using a hammer to kill a mosquito.
I think compiling a list of questions for the recruiters to ask for when filtering candidates is wrong and irrelevant for few reasons:
First of all, the weight of each question in the list should be judged in the context of the particular job requirements. No-one knows everything about Perl (maybe with few exceptions, see below the "top N").
Then, the weights of two questions could appear comparable to the recruiter and the candidate could get rejected based on wrong assumptions. Take these 2 examples from the list:
"What's the difference between == and eq?"
-- versus --
"Where do tests go in a standard CPAN distribution?"
One one side, if a programmer doesn't know the difference between == and eq, then we might have a problem (still debatable if the guy is coming from lots of years experience in PHP for example).
On the other side even an experienced programmer might have never been in the situation to care about the tests in the cpan distributions: if everything installs correctly and never created a CPAN module, why should one bother?
You can find more pairs of "extremes" in the list to prove this point.
The list also proved its limitations as a lot of people on linked-in already started to ask for clarifications. Assuming that someone really fixes the list's "bugs" as feedback is received, discussed and changes agreed on, probably endless iterations will be needed.
As for the relevance of asking somebody these questions, as the present list's answers can be found in only one book (Modern Perl), if anyone really wants to fool the examiner can do it by just reading this quite small book. Even easier, any perl wannabe can find now the list on the internet and can prepare the answers for potential future interviews.
Finally, knowing everything about perl is quite impossible: everyone has strong areas and weak areas and the capacity (or lack of) to improve in the weak ones if the job requires it.
Not everybody is Larry, Damian or Randal (and the list might continue to a top N). On the other hand not every company would need (or afford) any names from this shortlist. Bothering one of the top N programmers to write scripts for a company that sells ladies bras, briefs and stocks would seem a bit out of proportion, much like using a hammer to kill a mosquito.
Wednesday, 10 October 2012
Modern Perl recruitment
I am currently looking for a job using good old Perl and things seem more annoying than ever before. The frustration came back gradually, and most of it comes from the middle layer: the recruitment agents.
Let me start by clearly stating that not all the agents are the same and not all of them are "bad". However, unfortunately, many fit the description below.
This special breed of people, the perfect salesmen (in their views), is interposing between me and my "happiness" in annoying ways. Here are some things they, and only they, know how to do best:
Unfortunately there are so many companies that act the same through their HR department.
I have a real example, one that is these days on the jobs.perl.org: Heart Internet, UK. They think is ok to cut all communication with me, *after* I spent few good hours on their programming test. I don't care if my solution was dumb or not to their liking, I just consider I am entitled to an answer, at least as a sign of courtesy after wasting my time.
This job based in Nottingham is present on jobsite.co.uk also cloaked by an agent: Simon Harris, Applause IT (see above about cloaking).
Same communication skills from this guy too. I sent them together about 10 emails until now asking for feedback, no reply.
Say, what about a database with agent names and star rating/feedback? Something similar to yelp.com but focused on recruitment agents/companies.
Also, it could be extended for any job recruitment agent, not only for Perl.Anyone?
Let me start by clearly stating that not all the agents are the same and not all of them are "bad". However, unfortunately, many fit the description below.
This special breed of people, the perfect salesmen (in their views), is interposing between me and my "happiness" in annoying ways. Here are some things they, and only they, know how to do best:
- They understand 50% (if...) of what you can really do, but they have the audacity to decide your professional life by not putting you forward to the decision maker, the one that would really understand (as he needs and asked for you skills).
Sometimes you don't check a skill and, even they don't know what's the real relevance of it or how easy it is to learn it; they just feel that skill sounds impressive. If you don't have it, you're a looser.
Some other times they don't like you, you'll never know why. - They publish their own, "cloaked" version of a job that's already published directly by the hiring company. They leave the same keywords inside 'cause they're unable to reformulate the skill set.
- They publish non-existent jobs, probably just to motivate their existence to their bosses by pretending they have activity. Moreover, they fish for leads by asking you to provide info about any other interviews you had, motivating that they don't wanna overlap with other agents on the same positions.
I am sure (!) they don't contact an employer if they know that some other agent is already there :) They do have an exaggerated common sense. - They treat us as like... cattle by adding quantities to the job titles, like: "50 perl developers for a big company[...]", "Calling for all perl developers [...]".
We should just moo-in by sending all resumes to them. It's kinda depersonalizing, you know? What about having a regular posting for the job and selecting how many people you needed, afterward? - All the companies they're recruiting for are presented as they are the latest shit on the market, next to Oracle or Microsoft or whatever you consider it's a big shit these days (pun intended :)
Buzzwords include: "thriving environment", "exciting", "world leading", "voted as number one expanding", "global footprint", etc.
Have you thought that I just might prefer a regular sized company that would have obviously many advantages over the corporate, impersonal ones?
- You need to be psychologically abnormally addicted to work to please them. I mean, why would anyone choose to "dream in LAMP", "eat and breathe Perl", have an "Unquenchable thirst to automate mundane tasks" or be a "Perl junkie" instead of being a regular work-life balanced individual?
Unfortunately there are so many companies that act the same through their HR department.
I have a real example, one that is these days on the jobs.perl.org: Heart Internet, UK. They think is ok to cut all communication with me, *after* I spent few good hours on their programming test. I don't care if my solution was dumb or not to their liking, I just consider I am entitled to an answer, at least as a sign of courtesy after wasting my time.
This job based in Nottingham is present on jobsite.co.uk also cloaked by an agent: Simon Harris, Applause IT (see above about cloaking).
Same communication skills from this guy too. I sent them together about 10 emails until now asking for feedback, no reply.
Say, what about a database with agent names and star rating/feedback? Something similar to yelp.com but focused on recruitment agents/companies.
Also, it could be extended for any job recruitment agent, not only for Perl.Anyone?
Subscribe to:
Posts (Atom)