Re: Interview
Ken T. wrote:
I had an interview today. It didn't go as well as I would have liked.
It didn't go badly but I wasn't familiar with everything my potential
employer did.
When did it become necessary for a developer to not only know the
language used inside out, but also the APIs used, the third party tools
used, and basically to have done the same job for the last five years.
When the hirer has an immediate, short-term need to get
something done with that specific combination of goodies. If
the task at hand is "Omigosh, the one person in the company
who maintained the Brueghel Flugel application has just been
drowned in a butt of Malmsey, and a million-splonder contract
hinges on our being able to extend it to handle Strudel Noodles
as well! We need a Strudel Flugel Noodle Brueghel expert, and
we need one yesterday!"
IMHO, it's short-sighted to take on a permanent employee
on such a basis, because the need for a Brueghel Noodle Strudel
Flugel expert will pass in three months, and then you find out
you've got someone who's unable or unwilling to learn about the
Allegash Calabash Succotash API's you'll need for the project
that'll start in January. For urgent short-term needs, hire an
expert consultant, pay him his exorbitant rate, and bid him good-
bye when he's done what you need. But for permanent positions,
the hirer should be thinking not just about today's crises, but
about whether the candidate is the sort of person who'll be
helpful with the crises that aren't even imagined yet. For short-
term needs seek specific experience and skill sets; don't ignore
them for long-term hires, but pay attention to intangibles like
"native ability."
(There's a similar tension in elections: The candidates are
always talking about their positions on the issues that make
headline news today, but the one you elect will still be in
office when today's headlines are yesterday's news and matters
not yet thought of have come to the fore.)
I thought that the whole point of a good computer science education was
that you could apply what you learned to any language or API.
Dunno; I never had a "good computer science education." (I've
taught programming courses to undergraduates -- for credit! -- but
took only a couple such courses, years later.)
"Any language or API" seems to me an awfully ambitious goal,
though. Even the simplest languages and API's can contain (and
often *do* contain) subtle traps of various kinds -- just look at
all those cross-site scripting bugs that systems get pwn'ed by
every day. (Confess: How many weeks of your CS curriculum were
spent studying cross-site scripting bugs? Were you taught how
to detect them, how to avoid creating new ones? Were they even
*mentioned* in the lectures or homework? Would you say that a
Web developer knowing only as much about cross-site scripting as
you were taught is well-qualified to develop Web applications?)
And some of the gotchas are language-specific, which means
you won't learn about them from a "fundamental truths" kind of
curriculum, but only from familiarity with the language in
question. Education (and experience) may equip you with the
tools to discover and learn to deal with the idiosyncrasies of
the Bebop API's in the Sumatra language, but I don't think they
can qualify you as a Sumatra/Bebop practitioner from Day One.
BTW, this was for a Java position with a focus on Swing. I'm an expert
Java developer and a damn good swing developer. There are just parts of
the API swing API that I have yet to have needed and those I'm unfamiliar
with (many having to do with look and feel).
You may be up against the dichotomy of "We need help on
Project X" versus "We need another good person." That's a
toughie -- but don't be too uncharitable to the hiring manager,
because he may have had to use "We need Project X help" as a
justification to get the personnel requisition funded ... Keep
looking, and try to pitch your long-term value, try to shift at
least some of the focus off the Project X work that must be done
by year's end and toward the "What happens in 2010,11,12,..."
question. If he needs help on Project X you'll have to show at
least some ability to help with it, but make sure he realizes
that Project X is not Forever, and get him to start thinking
about what happens after X is over, and how valuable you'd be
for the as-yet-undreamed-of Project Y. Good luck!
--
Eric Sosman
esosman@ieee-dot-org.invalid