Stuart McLachlan
stuart at lexacorp.com.pg
Tue Sep 4 15:40:30 CDT 2012
"testing Access skills" <> "a job interview". JC didn't ask for the latter. SQL Server, Terminal Services, dress sense, working hours etc are not Access skills and I'd expect the hirer to determine what questions are relevant in these areas. JC, how about giving the applicants a copy of your framework and asking them to describe what various components do :-) -- Stuart On 4 Sep 2012 at 15:39, Arthur Fuller wrote: > 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 > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com >