[thelist] CF: Advanced? How do you know? [unnecessarily long]

[Steve Lewis]

Short answer to the original question:
I don't believe you can really get a feel for how 'advanced' a person is
without some sort of testing... best through a combination of verbal and
written responses from the applicant.

I personally think that testing should be done at a console too, not on
paper.  Developers don't work on paper and it is unlikely to give you an
accurate gague of how well the person works.  If you really want to
snoop, do so through VNC or something because developers rarely work
best when someone is standing behind him/her.  Afterword you can talk
about the process and experience to get more feedback, and point out
what the applicant missed.  Sometimes what the app misses tell you more
about what they do know than the app's catches.

Hmm, that answer wasn't so short was it?

> don't have either then I'm a bit curious. Code portfolio doesn't mean they
> should show you a bunch of code - they should be able to show you different
> apps they have worked on/ created and be able to explain what it does, what
> language(s) they used to create it and why and hopefully other things.

Coders often don't have legal rights to show you a portfolio of the real
interesting things they have done (which are frequently going to be
password-protected intranet/backend apps for businesses which are not
yours).

When they do exist, these demo/portfolio apps are frequently going to be
little more than toy projects, and little proof of knowledge.  I don't
know if you can aford to pass up a good coder in preference to a
dishonest but well prepared applicant who has simply liberated someone
else's work.  I believe a portfolio provides little insight and is
easily forged.

Furthermore, any coder who uses his backdoors or old logins to show me a
backend for a system that is clearly meant to contain privledged
information I should not have access to, esp for a system he is no
longer paid to develop, receives a notable minus in an interview.  If
the coder doesn't treat former/current employers systems with respect,
how can I expect different from her/him?

Bah!  I'm down on everything this week.
So what do I recommend than?

If you think you want an 'advanced' cold fusion developer, first look
for developers who (when discussing the work history, and the challenges
of those applications) can talk about the technology using the language
you use and thus is more likely to do things the way you do.  From what
I have seen, compatibility AND aptitude is really more likely what you
are looking for because most likely this person will write code that
either interoperates with someone else's work or this person will write
code that someone else will maintain down the line.  Style really does
matter in that case.

So how do you know when you have this?  It probably means that a number
of folks (manager types, developers, project babysitters, etc.) get a
chance to sit in one-on-one interviews with the applicant.  Give the
applicant a 15 minute break and huddle, or sent her/him home and huddle.
  If you think you have a potential match than bring the app back for a
2nd interview, or for round two; however you want to phrase it.

Why do it this way?
It is far easier to test for compatibility first.  If the person is a
raging ass and a true CF wizard, you would rather know about the raging
part first so you can terminate the interview before you find out about
the wizard part.  Don't tempt yourself by testing aptitude before
combatibility!

Once you find someone with a high liklihood of stylistic/methodological
compatibility develop some 'tests' or challenges to have them solve,
preferably something that is relevant to something your current
developers have done recently...locating typos and fleshing out common
algorithms or data structures seem to be good candidates.  Avoid code
that is dominated by your variable names themselves, because familiarity
with these can't be expected and will slow the applicant's understanding
of the challenge.

Fortunately you have a decent code versioning system -like CVS! :)- in
place so you can present actual broken code that has since been fixed,
for the test (that way you have a copy of the fix on your clipboard to
compare against).  The feedback on these sort of tests have proven in my
experience to be better indicators of how the developer will interact
with your real systems, and of course makes it easier to develop the tests.

--Steve