On Sat, 04 Aug 2012 23:26:15 +0200, clipka wrote:

> Nonsense. The #1 reason for failing at an interview is not wanting to be
> hired in the first place. The #2 reason (and often related) is having
> thrown out applications indiscriminately like spam: Most won't reach a
> suitable target. Be more selective, and you can cut down on the number
> by orders of magnitude without any disadvantage.

Yes and no on #2 - volume can help, but you're right that just spamming 
for every position isn't good.

Finding the right balance between selectivity and volume is tricky.  I've 
been highly selective in who I'll apply to - but I've also been generally 
in a position where I could afford to be picky.

I was laid off about 14 months ago.  In that time, I've interviewed with 
maybe 5 or 6 companies, gone to one in-person interview, and in the end 
I'm still doing contract work.

I could be pushing for volume and applying for every possible fit, but my 
wife and I have a plan to move out of Utah, so I'm looking for jobs that 
are in Portland, OR (where we want to move to - though we wouldn't say no 
to the right opportunity in the UK, either, but that's now our second 
choice rather than our first) or that will let me work remotely.  I have 
a skill set that can appear to be overbroad - which makes selling my 
abilities to a prospective employer very difficult.  

I'm very good at learning new technologies, and also at applying 
technology to solve business problems.  For example, the company I'm 
currently on contract to, I'd done some work for at the start of the year 
on a 6-week contract.  I was brought in to fill in for a doc writer who 
was going on medical leave.  At week 5, the lead engineer said that they 
felt that any contractor they brought in wouldn't be productive until 
week 5, but I was productive on about day 3, because I learned the highly 
complex technology in a couple of days.

And that wasn't a fluke, either - the prior contract was with a company 
doing kernel-level Linux stuff for managing CPU, memory, network, I/O 
channel, etc resources.  Very highly technical stuff; the engineer 
working on the network bandwidth stuff explained the technology to me in 
about 15 minutes, and I understood it.  He said that he'd spent hours 
explaining it to others, and they still didn't understand it.  But I 
picked it up so quickly that I was able to (a) explain it back to him in 
my own words, and (b) to ask intelligent questions about why they chose 
specific implementation details rather than others that I specified - ie 
"why did you do 'x' instead of 'y'?" type questions, and 'y' was 
something that actually would have made sense.

In about 25 years of work experience, I've been a programmer, writer, 
program manager, project manager, salesperson, and IT professional.  I've 
managed training programs and testing (exams) programs, have studied and 
applied what I've learned about adult education and learning.  I've 
worked with about 30 different programming languages, including assembly 
and machine code - debugged kernel-level code, and learned highly complex 
technologies.

And the result is that if I put all my skills on my CV, very few people 
believe that I could have possibly done all of that and achieved any 
level of expertise in it.

But I tend to take what I learn and learn as much as I possibly can about 
it.  The end result is that I can talk to Linux kernel developers about 
cgroups and managing block device I/O bandwidth, and I can also talk to 
people who have spent a lifetime in adult education and technical 
training about how education is truly changing for the first time since 
the 12th century because of technologies that connect people together 
outside the classroom.

Jim

Post a reply to this message