[clue-talk] Assessing technical skills?

Collins Richey crichey at gmail.com
Fri Jul 21 17:52:56 MDT 2006


On 7/21/06, David L. Willson <DLWillson at thegeek.nu> wrote:
> My very brief opinion on this is that companies wait too long, and then hire too
> quickly.  With some forethought, it might be simple:
>

[Jeff Cann from an earlier post]

< We have operators, but my team is really engineering.  We work with
< development teams to architect and specify their system requirements.
< After the apps go into production, then we are the 'back-line' support.

< We also do scripting, and actual development for low-value web sites
< [like internal documentation, wikis, etc.

I like David's suggestion, combining this with what you have said,
here's what I would recommend. Unfortunately  this couldl be a long
term project.

1. Develop a really good job description that meshes with the type of
work  your group does. Not the usual 3+ years experience with ... but
proven ability to do ... (be specific). You can build on this as
candidates come and go. If you keep good records of the interview
process, you can sharpen up the job description if someone does not
work out.

2. Develop some known test scenarios from work your team has
accomplished in the past, and as David suggested, put the interviewees
through the ropes on some actual work cases. If a candidate is not
comfortable with the process, that person is obviously not a good
choice.

3. As others have suggested, you may need better documentation
standards to control what is expected of your team by the developers
and what you expect from the developers as output. That may be the
very toughest nut to crack.

4. Conspicuous by its absence, and a I really hope it's just an
omission, is any mention of a test process to temper the type of
problems you get stuck with on the 'back-end'!!! If this is a process
consisting of dump the specs over the wall to developers who dump the
product over the wall to production, then $DEITY help you!

5. Another aspect that appears to be missing and that really should be
included in the interview process is the type of teamwork needed for
your team. Is it really "team" work, ie small groups interact to
accomplish a task, or is work parcelled out to individuals to be
accomplished "geek" style and presented as a completed package? That
could drastically alter the job description and the type of
individuals you want to attract. There are individuals who thrive in
the one environement, but who would be a disastrous choice in the
other environment.

In summary, the better you can quantify the details of what you need
in the way of team members the better your ability will be to screen
the candidates. The old adage "First know thyself" comes to mind.

Enjoy,

-- 
Collins Richey
     If you fill your heart with regrets of yesterday and the worries
     of tomorrow, you have no today to be thankful for.



More information about the clue-talk mailing list