>>Good point.
>>But we really need to hire a VFP programmer.
>
>After having hired a BS artist once, the next time I hired someone, I went through a few scenarios. I was astounded at how little the applicants knew. One scenario was that you are give a table which has duplicate records, you have last,first,address,phone,employeeno, etc. in this table. What steps would you take to produce a table that has only one record per employee? One guy said he'd have to get back with me and left. I got a letter from him a week later saying he thought I had been very unfair because I didn't let him go look up the answer and get back with me. Go figure! Of course, I'm just getting into being a '90's kind of guy. My wife says I'm probably up to 1894 or so!!!

In my interviews for developers, I always used a very simple question to filter out how people are accustomed to work with data. It shows a tiny diagram like:

+ Jones
|   +--- Smith
|   +--- Williams
+ Herbert
    +--- McDonald
    |      +--- Kramer
    |      +--- James
    +--- Stevens

It is quite like a typical organigram that tells you who reports to who.
I just ask about what the person consider the most effective structure for a table to hold this hierarchy.

Sounds lame?

In most cases, the time to answer this demonstrated a clear tendency about the skills of that person as a developer. Indeed, I got tired of seeing stupid responses, multitable relationships, one field for each person, and many that even passed!

Of course this is one in a bunch of questions (some very VFP related, some about DB theory, some about common sense). But this one is a classic.

True is that the best people I have working in my team today just answered it naturally and without too much thinking.

Just my 2 pesos.