[nycbug-talk] MSNBC on the decline of technology jobs

[alex at pilosoft.com]

On Wed, 22 Jun 2005, Francisco Reyes wrote:

> On Tue, 21 Jun 2005 alex at pilosoft.com wrote:
> 
> > That happens. However, the clued people will get a new job fairly
> > quickly, and XYZ-certified won't, if they get axed.
> 
> Define "clued people". Someone that rides whatever latest technology is
> "hot"?
Hell no. Someone who *understands* what they are doing. Not just passed 
the latest course, but understands what goes on underneath.

> I really don't know how it works on the networking/telco world, but in
> software development I don't think it's so clear cut.. Specially when
> you have LOTS many more people available than jobs.
I've spent 10 years consulting. It may not be clear-cut, but you can still 
tell a difference between someone who 'gets it' and who doesn't. If you 
can learn a new language by just working with it for a week, you get it. 
If you learn it by having your $job send you to class for two months, you 
don't. It *helps* to have some theoretical underpinning (having taken CS 
classes in school and picking up useful things from them), but it isn't 
strictly required.

If you want me to give examples in software development, my favorite
interview question is "c=0; c=c++;" what is the value of c?  The right
answer is 'undefined', it can be 0, 1, or 500. Now, its all about how
someone thinks about resolving this: Break the statement into operations,
and try to figure whether assignment or post-increment will happen first.  
It shows whether you know what expression is, what rvalue/lvalue is, what
the code is going to be *compiled* to, etc.

C has a lot of "gotchas" - if you don't know them and can't recognize
them, you'll fail my interview. I like to give examples that'd make a
difference between signed int/unsigned int, proper casting, why you
shouldn't use strcpy, why you shouldn't cast a pointer into an int. (Note:  
just merely knowing that you *shouldnt* doesn't give you any points on
this test, you need to know why). Those questions I consider 
'intermediate'. Certainly, if you don't know the answer, I consider that 
you "don't get it".

For database people, I have boatloads of questions, more theoretical, as 
it is very easy to write bad sql. As in, why do you use stored procedures, 
why should you try to do things in sql vs stored programming language 
(set-a-time vs row-at-a-time), proper schema design (3bnf), indexes and 
how they operate, how optimizer operates and how to help it pick the right 
path, why are sql statements compiled on the backend and pitfalls (cache 
of the execution path), proper use of permissions on tables/stored 
procedures, etc.

> Also someone's technical abilities have nothing to do with someone's
> ability to search for jobs. Heck I have met great tech people that were
> awfull at interviews.
Absolutely. I used to suck at the management interviews (you know, 
answering questions "so, tell me about yourself" and "what are your 
greatest weaknesses"). But fortunately, those questions have 'right 
answers' and once you learn the right answer, you'll breeze through the 
management interview. ;)