[thelist] Offering contracts: Opinions on Etiquette?

jeff jeff at members.evolt.org
Fri Nov 3 23:58:20 CST 2000


frank,

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: From: Behalf Of Frank
:
: I've recently had the opportunity to meet a CF
: developer, with the intent of evaluating his skills
: in relation to my company's goals.  Before we
: met, I asked if he would be willing to bring some
: code that he had written so that I could take a look
: at it, to benchmark his skill level.
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

this is a very reasonable request to make.  my initial response to his
reaction is that he's not capable of coding cold fusion and simply didn't
want you to find out he wasn't what he said he was.  i could be wrong, but i
don't think so in this case.

if i wasn't already working for a good company i'd expect that any future
employer would want to see some examples of my work.  expecting me to
produce quality code while under test conditions away from my usual working
environment (and the tools i'm used to) isn't going to allow me to produce
the kind of code i'm used to producing.  however, matching up code to a site
you can see the workings of and compare the code to your business needs in a
developer is what will give you an idea of how those skills (or lack
thereof) will fit.

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: Here's the question: Is asking to look at, without making
: copies (example: reading it off a floppy disk) of previous
: work at the source level out of line?
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

no, absolutely not.  if anything it's a test of trust.  if the developer
doesn't trust that you won't do anything with his code, then you're likely
to have issues with that developer not trusting you on other things.  it's
understandable to be alittle uneasy about it if you're the developer, but
completely cold to it.

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: For those of you who are hiring developers: Any
: hiring tips?
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

since i'm right in the middle of hiring people, i have some ideas you can
probably use, that i'm using with good results:

ask for examples of code.  ask to not only see a list of sites they've
built/worked on, but also some details with each one explaining what their
responsibilities are with each.  also ask to see some source code examples
for one or two of the sites they produced.

if you're looking for someone with cold fusion skills then they should be
able to show proficiency, at the bare minimum, with html, css, javascript,
and cold fusion.  at the very least they should be able to demonstrate an
understanding of the principles of programming languages  - variables (local
& global), scoping, functions, arrays (index & associative), loops
(for/next, for/in, do/while, do/until, etc.), etc.

they should have some basic understanding of at least one of the major
database packages (sybase, ms sql, oracle) and some experience with it.
they should demonstrate an understanding and appreciation of referential
integrity, database architecture, and sql.  they should know how to create,
alter, and drop tables via sql.  they should know what triggers are and how
to create them via sql.

they should have some sort of definable architecture to their coding style.
flat-file structure doesn't cut it in dynamic application design.  it's an
organizational nightmare.

they should be able to demonstrate in their code an understanding of code
re-use.  without that they're re-inventing the wheel every time.  while code
re-use is important they should also not rely on third party components that
tie you into a single platform (nt, linux, sun, etc.).

they should be able to demonstrate good research skills.  even more
importantly, they should be able to show that they have a network of help
available to them (like this list is to alot of people).  it's harder to get
answers if you don't have people you know you can turn to.

ask for references.

they should be able to provide, at a minimum, references from past employers
(or clients if they've never done anything but freelance), past co-workers
(if applicable), mentor(s), member(s) of the developer community,
non-developer, etc.

i know this seems like a lot of info, but you can never be too careful with
potential employees.  after all, you're going to be trusting them with
company secrets, passwords, client information, etc.  you should be very
certain that the person you're hiring is really who they say they are.

oh, and *call* their references.

i know that some of the ideas i have are kind of difficult or uncomfortable
for some people to be able to meet, but it's not impossible or unreasonable.
get as much as you can.

good luck,

.jeff

name://jeff.howden
game://web.development
http://www.evolt.org/
mailto:jeff at members.evolt.org





More information about the thelist mailing list