[thelist] web team leadership...

Warden, Matt mwarden at mattwarden.com
Sun Sep 16 00:01:26 CDT 2001

On Sep 15, Andre Gaulin had something to say about Re: [thelist] web team...

>1. As prospective hires about their process for doing things.  Process is
>very important.  Alot of people out there are good as "lone-gunmen"
>developers but in a team they can't really handle it.

I think you're overgeneralizing. The "lone-gunmen" type might be just what
he's looking for, if the team is like it was at my most recent job. We had
a group of 9-12 (varied with time) developers. Our project manager would
hand each of us a client project to work on and the most successful
employees were myself and one other guy. We were the type that would be
handed something to do, and we'd go and do it. We didn't collaborate much
and we didn't interact much with the project manager, other than receiving
and understanding requirements. Most of the real interaction we had with
co-workers was not work related, other than when we were helping other

Anyways, the point is that since we each had our own project to do, and
there wasn't a situation where 2-3 were working on the same project doing
the same job (coding, DBA, etc.), the most successful employees were the
ones who were able to get requirements and meet them with minimal
disturbance to other employees. We were still a team and we still bounced
ideas off of each other, but that was really it. The "team" had a role
and structure much like this list does. Each of us has our job to do, and
we only involve other people (who each have their own job to do) when we
need feedback or help with things.

Process may be very important when you've got 5 hands in the same code,
but it is significantly less important (other than managerial process,
which would be instituted by the employer anyways) in a team structure
described above.

>2. Try to ask questions that point out it the person is a "swiss-army knife"
>type developer.  Someone who knows "everything" can;t know all of it too
>well.  You want people with the specific skills for the project, not every
>skill in the book - trust me on this one.

With 2-3 people? I know what you're saying, and I do agree. However, when
you have 2-3 people, you can't really get too specific
skill-wise. Otherwise, you'll end up with bottlenecks with whomever has
the skill that involves the most work... or the skill that must be done
after other skills.

>3. To test their HTML skills the best test so far is a screen grab of a site
>and a pad of paper.  Tell them to code the screen gran on paper.  Give them
>15-20 minutes.  They only really have to code a few lines.  The trick here
>is to see how they approach their coding.  Brute force (jump right in) or
>more strategic (divides up the screen grab and comes up with a plan of
>attack).  How do they think about doing the job?

On paper? Any specific reason for that? Personally, I'd *hate* that. I've
tried to explain things to people before by writing example code
(programming, in this case) on paper, and I always scrap it and use
Notepad or something on the computer. I just don't like how I don't have
columns lining up and everything nice and orderly (plus I can't draw those
curly braces ({,}) very well). I was just curious why you said on a pad of

>4. Another good idea is to look at their portfolio beforehand and then
>devise questions about why they did certain things, or what they would
>change and why.  They will feel more comfortable talking about stuff they
>have already done, especially if they have an intimate knowledge.  


>If you
>ask tough questions (ie what does this messy javascript at the top of every
>page do?) then their answer might reveal alot about them - they can explain
>clearly why they did something or they are trying to play you.


And look at their html and see if that fits your philosophy. for instance,
are they using tables or positioned divs? Are there SPANs everywhere? do
they use font styles or font tags? etc.


More information about the thelist mailing list