[Israel.pm] Shortage (or Perceived Shortage) of P-Languages Programmers in Israel (and Elsewhere)

[Shlomi Fish]

Hi guy and everybody!

I'm sorry for the late response and possibly breaking this thread. It's just 
that a bootload of networking problems conspired above me, and I ended up 
having to import this message from the mbox.

On Monday 26 June 2006 02:10, guy keren wrote:
> 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.
>

Sure. But obviously some more companies can in-fact hire people in order to 
train them in a different technology.

> > > 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"[1]), 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.

True.

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

I realise that. I've been at an interview in a Java shop where I passed the 
technical interview writing some not-so-correct Java code. I rejected the job 
offer eventually, because of the fact they told me that they work extremely 
overtime on tight schedules, while I thought it wouldn't help much in getting 
more things done.

While I'm trying to learn technologies which I find interesting, heard good 
things about or are important historically, I tend to avoid most 
hyped "Enterprise" technologies, unless I want to hack on an open-source 
project that uses them. Usually I find that learning them is not very hard:

http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

<<<
I have never met anyone who can do Scheme, Haskell, and C pointers who can't 
pick up Java in two days, and create better Java code than people with five 
years of experience in Java, but try explaining that to the average HR drone.
>>>

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

Yes, you're right.

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

Yes, but this is a well-known chicken-and-egg problem. If I didn't work for a 
few years in a company with technology X, many companies will not hire me to 
work with it. Some recruiters will even ignore or even be appaled from 
long-term open-source experience with this particular technology. (Albeit 
usually, I wouldn't want to work for such places, to begin with.)

A problem with me is that I tend to perform small amounts of work on various 
FOSS projects, and then go on to something else. (Like a child with a short  
attention span). Sometimes I return to projects I worked on before, and 
contribute other stuff (either minor or relatively large-scale.), but not 
always. Often, I just scratches some itches (either mine or other people's) 
and then disappear.

>
> > > 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 ;)

Of course not. :-) That's not what I meant.

>
> > > 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)
> >
> > then:
> >
> > <<<
> > Linux is becoming the development platform of choice; for example, it is
> > expected that more developers will be developing on Linux than Windows by
> > 2004;
>
> words are very easy. i can say "by 2007 there will be more linux users
> then windows users". it won't make this true.

Right. But this is a survey based on statistics. Don't know if this prediction 
came true or not, but it makes a lot of sense.

>
> you also forget that we're in israel, not in some other part of the world.
>

Yes. But as I realised, Israel may not be too much different as far as 
Info-Tech is concerned. For example, I talked with a certain Norwegian and he 
told me most sites in Norway work only in MSIE. It may have become better now 
that Firefox and other alternative browsers have become more popular in 
Europe and elsewhere. I also talked with an American high school student from 
Mississippi and he said most American local sites also in MSIE exclusively.

Obviously the situation becomes worse in Israel which is a small and 
relatively isolated country. But it still exists elsewhere.

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

OK.

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

Heh, right. Of course "shrink-wrap" programs and "in house" programs are two 
words with a lot of things in between. Is web-site code that was is served on 
the Internet, but is not distributed for re-use by the public (as a CMS, 
etc.) considered in-house? Or is it shrink-wrap?

Are embedded programs shrinkwrap or in-house? Hard to tell. Joel Spolsky in 
the article distinguishes between five worlds: shrinkwrap (commercial, 
open-source, consultingware, freeware, shareware, etc.), embedded, in-house, 
commercial games and throwaway (like scripts one writes on the command line). 
While this is a generally good division, there's a lot of border areas, etc. 
Most people sub-division jobs in Information Technology to many more aspects.

BTW, some companies don't use out-sourcing companies for everything and 
instead employ in-house programmers. It has its benefits. And some in-house 
programs are very interesting. (Albeit they tend to be much less than 
open-source or a lot of commercial software). A lot of in-house software also 
requires much less discpline and effort than the equivalent shrinkwrap 
program. (As I and others can testify)

> > > 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[2], 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.
>

Right.

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

<nod />

> 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++.
> >
> > Right.
> >
> > > 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) ;)
> >
> > Hmmm...
> >
> > > 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 impression.
>
> there is no problem with that, as long as you eventually get the right
> answer ;)
>
> and realize that if you have to admit not knowing the answer for too many
> questions - you'll not pass.

Yes, I know. This is acceptable. In one interview I had they asked me to try 
and design an Intrusion-detection system with them, and since I did not have 
much experience with them, and was not (and probably still am not) an expert 
in protocols, exploits, etc. I found it hard to find good ways, and kept 
saying "I don't know.".

I didn't get the job, and I don't blame them. Perhaps they were looking for 
people with some knowledge in security and networking. 

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

I guess. Of course, some people just have bad luck. And the more time you are 
without a job, the larger the gap and the more recuiters will get suspicious.

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

OK. I know one can prepare in advance for such questions as most of them are 
common to many interviewers.

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

Yes. Of course, if I'm getting asked "Do you like Java?" I'd rather not 
say "Sure! I love it." but rather "I don't know. It might be OK. Tends to be 
verbose and stuff and used to be over-hyped. I prefer Perl for most of my 
work." I'd rather admit it in the interview, then have to lie and also get 
caught in inconsistencies.

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

OK. I once had a preliminary phone interview where they said they were working 
with C++ in "pure object oriented mode". Now this smelled wrong to me, and 
while I didn't say I'm interested to work there, I may have sub-consciously 
caused them to prefer me not to work there.

As much as I like OOP, I think it's much better and easier done in Perl and 
other high-level languages (usually dynamically-typed) than in C++. OOP in 
C++ is much more painful than in Perl. (Although possibly doable). When job 
ads say OOP/D experience they usually mean experience with C++, Java or .NET 
not with Perl, Python, Ruby, Lisp, or Smalltalk. 

I'm not saying you shouldn't write code in C++. Sometimes it is a good idea. 
(I think I prefer ANSI C for most stuff, though[1]).

>
> > > 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
> expensive software).
>

Right. When I had an interview for an embedded company I was asked to design 
the internals of an API for a design queue in C. I told them that the 
simplest way to do it would be by using a linked list, but that a priority 
queue would be more efficient. So he told me that I should do it using a 
linked list, because it was simpler to do and so less error-prone. So he left 
and I started to code it (on a laptop running Windows 98 machine with a 
slightly quirky keyboard using notepad. ) I didn't get everything right later 
on, but I think I made a good impression.

I didn't get the job later, but I felt good about the interview. It was 
interesting.

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

True. If the mountain doesn't come to Muhhamad, Muhhamad should go to the 
mountain.

> > Otherwise, he'll probably never find a candidate that's "perfect". We are
> > all human.
>
> 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.

Right. <nod />

Regards,

	Shlomi Fish

[1] - http://www.shlomifish.org/philosophy/computers/when-c-is-best/, also see 
some discussion in http://osnews.com/comment.php?news_id=12189 (even though I 
think I received the most interesting comments by private email).

Also:

http://www.shlomifish.org/Vipe/lecture/Freecell-Solver/slides/why_not_cpp.html

As guy has noted in the original presentation when I covered this slide, the 
2nd edition of the K&R C book is pretty thin, while the latest edition of the 
Stroudstroup C++ book is very thick. (and many examples from there won't work 
in most compilers).

---------------------------------------------------------------------
Shlomi Fish      shlomif at iglu.org.il
Homepage:        http://www.shlomifish.org/

95% of the programmers consider 95% of the code they did not write, in the
bottom 5%.