On 3/28/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >>>>>>>>>>>
> BTW, if you are a university student trying to impress potential
> employers over a long period of time before graduating, would you not
> want to work live?
>
> And wouldn't companies have an incentive to watch these broadcasts to
> identify talented people? For example, software companies would
> probably get a better picture of how a programmer will work on a daily
> basis by watching them code on an open source project for long periods
> of time.
> >>>>>>>>>>>>
>
> Let me speak as a software professional.  I'm working on a Ph.D in
> computer science, am employed by Motorola, and was a developer of Google
> Talk.
>
> Watching a coder's screen is really not an effective way of getting a feel
> for a coder's talent.  There are a few reasons.  The first is that, if a
> coder puts in an 8 hour day, it's going to take at least 2 hours to watch
> it.  This is massively wasted labor hours for the reviewer.  The second is
> that the minutae of the coding process is irrelevant; the final product
> and total hours spent is.  Thus, an employer could learn just as much
> about the recruit simply by reading about the project on the recruit's
> resume and reading the source code of the final project.  The third is
> that watching a coder's screen will tell you nothing about the skills in
> short supply among coders- social talents.  Those are so important, I have
> been at interviews where my programming skill was never discussed...the
> interviewers just wanted to make sure they liked me enough to talk to me
> every day.  Finally, employers have their own internal methodologies which
> will be different from how a coder works, and that learning curve will
> exist universally.
>

What I propose gives you an additional source of information that you
can use to select people.  It's not a replacement for resumes,
interviews, etc.

Watching someone code live gives you some information that might be
hard to pick up otherwise:

* how quickly does this person think?
* how error-prone is this person?
* how does the software design emerge?
* how does this person debug?

Technical interviews do try to get into people's heads as they solve puzzles.

What I propose allows you to get into people's heads as they write
non-trivial code over long periods of time.  It also gives you an
insight into what they would do on a daily basis.

Amir

> --
> Rhett.
>
> ---------------------------------------------
> This message was sent using Endymion MailMan.
> http://www.endymion.com/products/mailman/
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/videoblogging/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply via email to