[AccessD] Access skills testing

That's a moving target if ever I've seen one. Consider 2003 v. 2007-10.
However, it's true that at least some of the knowledge of old commands is
portable. But I sense another problem here, and that would be that this
question is asked in the absence of app-requirements, which I don't think
is fair either to the applicants or to the client.

Instead I might suggest that a description of the app-requirements might
first be formulated, and then the questions to ask might just "fall out" of
the requirements. For example, is the BE to be SQL Server or MDB or Accdb?
That question alone matters hugely, and influences all subsequent
questions, on that path at least. Then there would be the issue of
user-quantity: 100 users is significantly different than 10. Another
consideration is the quantity of locations: if it's only one, things become
much simpler. If it's several, then other skills are required, such as the
ability to set up a Terminal Services server and establish the connections
to same. After that I would want to know the demands involve Office
Automation, such as populating Excel spreadsheets or Word documents from
data inhaled from the database, and whether such documents require
translation to Acrobat files to be automatically emailed to Outlook
recipients or perhaps some other email client.

IMO, without answers to these questions, I could not begin to devise a set
of test questions to determine whether candidate A or B or C would be a
good fit.

And there are several more questions, having more to do with the client's
environment that the actual skill set. Does everyone wear ties, or shorts
and tees? Are there rigid restrictions on start-and-stop time, or is the
developer free to work her own hours? Are time zones involved (which might
happen if the client does business in Asia)? How much technology-transfer
is considered part of the gig (which means, do I not only have to write the
app but also provide sufficient instruction for the in-house people to be
able to perform maintenance)?

I can probably come up with a few dozen more questions, but the bottom line
is, before we can proceed we need to understand the client's opinion about
what defines a successful hire, and that means that we need to know the
requirements of the app itself. Without this information, you and I and the
client are in the dark, asking abstract questions such as "Do you know how
to open the same form thrice?" or perhaps, "Can you write a class that
abstracts the details of an argument to the OpenForm method", which
questions, I daresay, do not begin to approach the immediate problems at
hand. If there is no possibility in the given app to be written that a user
will ever open the same form twice, why ask the question? On the other
hand, if a given report must be able to accept a date-scope and/or a client
scope, then that question is definitely worth asking: "How would you
suggest that we accomplish this, and secondly, will your solution be
portable from app to app?" In this case, that's how I would phrase the
question.

There's one more thing that I feel that I should toss into this discussion:
although I started out in dBASE-II and then Fox and then Access and then
Oracle and then SQL Server, one thing I learned way back when is that the
user should NEVER NEVER NEVER have access to the native tables. No No No!
(If I'm sounding like Adele, I can live with that!) Nobody but God, which
means the DBA, should be able to access a table, and if you have not
accepted that fundamental truth, then go back to school and learn why. I
learned from Dr. E.F. Cood and Fabian Pascal and Michale Stonebreaker, and
also a few set-theory mathematicians, and after them, a few of the NoSQL
people. Life goes on, and so does exploration of where this is going to get
us, in the big picture. I admit that considering these giant brains, I am a
follower, not a leader, But I also say that I walk into these arguments
without baggage. I am looking for two things: correctness and speed. That's
all I have to say about my decisions in this respect: at any given moment,
I could be wrong and chosen the wrong horse. I accept that. But I have no
favourite horses in this particular Kentucky Derby. I might have a
favourite and might bet an unhealthy amount of loot on that gorgeous horse,
but that doesn't mean that if another horse wins, I shall call the raced
fixed. That's not where I go with this stuff. I have my emotional
favourites -- of course I do! But that doesn't mean that I reject Evidence.
Above all, I try to be objective in these matters, and if the evidence
turns against me, I shall most happy to declare that I was mistaken. I am
not out to win arguments, in the face of evidence. I am most willing to be
proved incorrect. That is my nature.

On Tue, Sep 4, 2012 at 2:11 PM, Martin Reid <mwp.reid at qub.ac.uk> wrote:

> They have a Colby, why do they need anything else?
>
> Martin
>
> Sent from my Windows Phone
> ________________________________
> From: jwcolby
> Sent: 04/09/2012 18:54
> To: Access Developers discussion and problem solving
> Subject: [AccessD] Access skills testing
>
> Does anyone have anything on testing MS Access skills?
>
> One of my clients wants to see what his applicants know.
>
> --
> John W. Colby
> Colby Consulting
>
> Reality is what refuses to go away
> when you do not believe in it
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>



-- 
Arthur
Cell: 647.710.1314

Prediction is difficult, especially of the future.
  -- Niels Bohr