[Israel.pm] Shortage (or Perceived Shortage) of P-Languages Programmers in Israel (and Elsewhere)
choo at actcom.co.il
Sun Jun 25 16:10:15 PDT 2006
On Sun, 25 Jun 2006, Shlomi Fish wrote:
> > in the second case - most companies look for "language experts", for one
> > reason or another.
> True. Either "language experts" or they expect professional (for some value
> of "professional") programmers to learn the language while working there, and
> then become "language experts".
no, no. when i say "look for language experts" i mean "look for people
with significant prior experience with the said language". not "smart
people who will become experts in 1-2 years". you underestimate the
emphasis companies put on "experience" here. note that i did not state
whether i think this is justified or not - i'm just describing what
companies claim to want.
> > when a technology is not in wide-spread use, you'll see two things.
> > jobs - will be scarce, because not many companies use this technology, and
> > lets face it - most jobs are normally not vacant (if you have 100 jobs,
> > you'll most likely not have more then 5-10 new openings each year,
> > depending on how long it takes employees to leave you or get fired).
> > people - people preffer learning how to use the more wide-spread
> > technologies, which will mean they have a more flexible job market.
> Depends on which people. If you're talking about the "average" programmer who
> just wants to make a living, or has been hyped into IT because of the large
> salaries, then yes. If you're talking about a programming enthusiast (the
> so-called "hackers"), then they may not necessarily want to learn it
> unless perhaps they want to work on a project that is written in such a
> language. I didn't give any time to thoroughly learn Java or .NET, even
> though they are popular, because I don't need to write any code for projects
> written for them. (except for very minor things, where my rusty knowledge of
> JDK 1.0.2 is adequate).
i'm talking about most people. there are very good programmers who don't
put such a high value on learning many new languages or many new
technologies. the fact is that people try to learn what is in demand, in
order to make it easier for them to find a job. hackers are the minority.
companies need many programmers, and most of these are not hackers.
the fact that you refuse to learn a language that could make your life
easier when looking for a job (i.e. instead of showing them you
know java, you need to explain why you'll learn it fast) shows that you
don't try to solve the problem of "making your life easier with regards to
finding a new job".
If you want to make finding a new job easier, you should accept the fact
that companies will want you to program in a given technology, and require
1-2-3-4 years of programming experience in the given technology. Failure
to do so will mean having a harder job-hunting life.
> > as a result, there is lack of good job, as well as lack of technology
> > experts.
> > conclusion 1: make sure you have good knwoledge in some wide-spread
> > technologies, so you'll have a fall-back.
> Good idea. Hopefully, as far as a hacker is concerned, it will be a technology
> that hackers love to use, rather than one of the so-called "Enterprise
> Technologies" that are parodied on http://thedailywtf.com/ , (and especially
> those that hackers hate - some enterprise technologies may be pretty good).
> Learning all the hyped enterprise technologies or all the hyped open-source
> technologies is a waste of time.
i didn't say "learn all technologies". i said learn some.
also, learning is not enough - companies look for real experience in these
technologies. saying "i read the book and wrote the exercises" is quite
different then saying "i worked for two years on a project in company X,
which used this technology". When it comes to an interview, the first
looks amateurish. the 2nd looks more professional (and it doesn't matter
that sometimes this is the other way around - the fact is, that this is
how these things are percieved by interviewers).
> > conclusion 2: if you become an expert in a technology that is not so
> > widely-used, expect having a harder time when looking for jobs.
> Yes, unless you also know a popular technology. And some technologies which I
> really like (for what's their good for), are already popular, and I'd
> recommend everyone to usethem.
NOT DURING AN INTERVIEW. please don't mix the two issues - you can't be
both a consultant and an interview-ee at the same time - unless you are
interviewing to be a consultant ;)
> > linux is still less (much less) used then windows, for example.
> True, as far as the home users are concerned. However, according to the
> article reference at:
> http://xrl.us/np5i (points to the old Joel-on-Software forum, with some
> discussion there)
> Linux is becoming the development platform of choice; for example, it is
> expected that more developers will be developing on Linux than Windows by
words are very easy. i can say "by 2007 there will be more linux users
then windows users". it won't make this true.
you also forget that we're in israel, not in some other part of the world.
> And we're already in 2006. The problem I outline there is that most software
> is not "shrinkwrap" that is intended to run on home users' machine (for which
> you probably have to develop for Windows, if you want a market large enough),
> but rather different kinds of software. (See:
> http://www.joelonsoftware.com/articles/FiveWorlds.html ).
it does not matter what the product is going to serve eventually. the fact
is that most open programming positions are sitll around the iwndows
platform then around the linux platform. and no, i did not make a proper
survey - this is just my subjective perception of the job market.
i also think you'd preffer working for the "shrink-wrapped" market, then
to the "in house" market, because the "in house" market is (as much as i
can see) pre-dominated by the outsourcing companies (such as ness, matrix,
One computing, etc.). working for them is not so fun. and i don't imagine
you'll want to work for a bank - they don't want hackers...
> > C, C++, java and dot net are probably the most used langauges in the
> > israeli market - so it'll be easier finding jobs where they are required,
> > then finding jobs where other languages are required.
> Right, but as you say (or I'm saying now) there are also more programmers who
> know them than Perl or (much more so) Python or (much much much more so) Ruby
> or (infinitely more so) Lisp programmers, simply because they are or have
> already become popular. Even most people I'm talking to did not hear about
> Perl yet. So, although there is a smaller demand for them, there is also a
> smaller number of programmers to fill this demand.
i see you failed to see my point. when you have less jobs and less
potential experts for these jobs - then your job-hunting flexibility is
smaller. you need the market to grow over some minimal size before you
find it is easy to switch jobs. you sohuld remember that while there are
many C++ programmers, there are not so many very good C++ programmers.
there is also a different angle - the technology is not just the language
used, but also the environment in which the software is developed (windows
Vs. linux Vs. Mainframe Vs. embedded systems). there is also the
architecture used (stand-alone Vs. client+server Vs. distributed...) which
req uire a different set of skills. There is GUI Vs. servers, there is
database programming, device-drivers programming, etc. develope a
combination of required skills, and your life will be easier.
There is also one market in the center area, Vs. a different market in the
north or in the south.
> > the web-development market, btw, is distinct, because it uses a setof
> > application-specific technologies (be that php, ASP, server-side java
> > technologies, etc.). it is not easy to switch between the web-development
> > market, and the systems development market - because they use quite
> > different "language sets". it is possible to do the switch by finding
> > partial-pverlaps. for example, if you did web development in a company
> > that used java server pages - it'll be easier to switch to the systems
> > development market by going to company that uses java, ratherthen a
> > company that uses C++.
> > the two ways to get over the "pickiness" of employers are:
> > 1. gain more (relevant) experience. don't gain too much experience, or
> > else you'll be dismissed as "being too old" (or too expensive) ;)
> > 2. learn how to pass interviews better. just like you can learn
> > programming, you can learn how to get interviewed. i found that being
> > an interviewer helps in this. makes you think "what do they want, and
> > how do i help them see that i got this?". most bad interview-es (people
> > that are being interviewed) don't see this - so they come up with
> > hand-waving excuses (i'm a fast learner... i knew how to do that, i
> > just forgot but i'll remember quickly.. i'll learn this when i need
> > it...), rather then with susbtance (oh i know this - you do this and
> > that.... here is the code..... the answer is 1, 2, 3, but there's
> > also another option, but it'll make the code harder to maintain).
> I heard of a few consultants for preparation for passing interviews as well. I
> usually don't hand-wave. Either I admit I don't know the answer, (which
> doesn't happen often, but happened to me at least once), or answer the best
> way I can. Sometimes I tryto develop the answer along with the interviewer
> step-by-step if I don't know it right away, which AFAICT should make a good
there is no problem with that, as long as you eventually get the right
and realize that if you have to admit not knowing the answer for too many
questions - you'll not pass.
> However, despite all that some interviews where I answered all questions
> correctly, turned out to be dead-ends. And some companies I've been too also
> find the fact, that I've been out of jobs for so long, a bad sign, so it was
> a vicious circle.
indeed, this is a problem. i know that when i interview someone that has a
gap in their resume for the last X month or so, i get suspicious, because
_usually_ people don't do this out of their own accord. If they went for a
trip abroad for a year, i'll ask myself how long before they leave me for
another trip. If they left the job market during the down time
(2001/2002), i'll ask myself whether they were fired and why they didn't
manage to find a job until now. it is not my job to make it easy for
people to find a job - it is my job to find people that will work well for
the company i work in. and it is a matter of supply and demand - i see how
i have problems getting the best candidates, because they have demand from
other companies too, that might appeal more to them (yes, it happens
sometimes, and it is frustrating, just like it is frustrating when you
don't get a job because someone else got it, that was perceived as being
> ( Now that I think of it, it is possible I resorted to hand-waving
> or "gimgumim" when the employers asked me some personal questions. I hate
> most of those. ("Name three of your faults.", etc.))
then try to think why you hate them, and learn to cope with them. not all
companies ask these questions, but i guess some do (especially when the
interviewer is a manager, whose task is to see if you have more then basic
technical skills - e.g. the ability to criticise yourself, the ability to
know when someone else has a better idea then you do and accept it, the
ability to work even when the going gets tough...). you should try to see
why they are asking what they are asking, and learn not to hate it.
> > 3. don't insist on using technologies that companies don't want. if you
> > interview for a job that asks for experience in technology A, and you
> > got to the interview, don't tell them that using technology B is
> > better. it works very rarely - but normally it will back-fire.
> That I know. Of course, I think it may be a sincere thing to admit that you
> prefer technology B, or that you don't like technology A too much. Hiding it
> will only bite you later.
admitting this during an interview is a bad policy, unless you know that
you do not agree to work with technology A at all. it is better to give it
a thought _after_ the interview, when you're not under pressure, and
you're trying to compare two different job offers that you got. otherwise,
what's the point?
when i had an interview and i found in the middle they work under windows,
i told them there must be a mistake since i do not look for a windows job.
but that was because i knew, 100%, that i preffer (some) unemployment
period then working on windows. However, if i only preffer working in a
different technology - what is the point of saying that during the
interview? if i know i'll still do a good job working with the
less-preffered technology, there is no point in frightening the
interviewer for nothing. there is also no need to tell them you have more
experience in technology B then in A - they already saw that in your
resume, or asked you about it. if they did not - either they don't care
about it, or they made a mistake (but it is not your job to tell them why
they shouldn't take you).
> > 4. become an excellent programmer - and learn how to prove that during
> > interviews. if not excellent - at least very good.
> Well, I don't know if I'm an excellent programmer, butI'd like to think I'm
> pretty good, and that I'm getting better in time. I've seen some bad code in
> various places. (Including some of my old code that I became unhappy with,
> and had to refactor, etc.). To paraphrase what I said on Hackers-IL once, I
> think that sometimes when a programmer writes code, he writes it
> quick-and-dirty, rather than in perfect modular condition.
there is no need to explain this to me (or to the list). explain this to
the interviewers - and not by telling stories. rather, by solving their
questions properly. and for heven's sake, i hope you don't write
quick-and-dirty code during interviews. even if the company writes a lot
of bad code - they'll still preffer the candidates that are able to write
clear code. on the other hand, don't write complex code either. if they
ask you to design something, use a simple design, or else you'll not be
able to show them that you're a good programmer, because you'll start
getting confused when they ask you to write the code that implements your
design. you may, after telling about the simple design, show some weak
points of the design and how you could have tackled them if the need
arises, and sating when the need will arise (by this you'll also show them
that you don't optimize unless there is a real need. companies don't like
people who over-engineer their code, because it tends to lead to more
> > finally, there is no way to overcome the pickiness of employers - they are
> > picky because they were burnt. you can't make them not be picky, because
> > you'll need to resort to hand-waving - and that is exactly what they were
> > burnt by.
> I realise that. What I'm trying to say is perhaps an employer should realise
> that if a candidate did everything all-right except for one or two things
> where he was unhappy with him, he should still consider hiring him.
why? so they'll have to fire him after 2-3 month?
instead of trying to think what the employer should do (because this will
not help you in your job hunting), think how you could adapt to their
malformed methods of interviewing people.
> Otherwise, he'll probably never find a candidate that's "perfect". We are all
eventually, either they manage to find the right person, or they
sub-conciously (or conciously) reduce their requirements. however, they
would rarely do that before trying the first method for a while (when "a
while" changes for different companies). rememebr that the job of
recruiting people is to help themselves - not to help you. whether they do
a good job at it or not does not matter - what matters is what you can do
to make it easier for them to say they want you.
"For world domination - press 1,
or dial 0, and please hold, for the creator." -- nob o. dy
More information about the Perl