How to test the competence of Access Developer job applicants?

[Richard Sherratt]

One of my customers is about to create several new positions for
internal Access Developers. These are not professional developers who
could sell their services on the open market, but more like advanced
user support people who can develop simple databases for their users.
I've been coaching one of these guys and have got him to the stage
where he's able to generate Word and Excel documents and then attach
them to Outlook email messages. Nothing particularly advanced, but
more than you'd expect from the average user who can develop, say, a
membership list for his local club.

The customer is not a technical guy, but he want's to be able to test
candidates and determine who can cut code and who is a user/developer.
He's thinking of a 30 minute test as part of the interview process.
He's needs an objective rating rather than a subjective assessment.
It's a govt. dept. and unsuccessful applicants can appeal if they
think they were wronged.

I was thinking of getting them to develop a simple form, but with
elements that need a moderate knowledge of VBA.

Any ideas?

--
Regards.
Richard.

[Beacher]

Involve some subforms/datagrids in the testing too... that usually
shows some signs of a bit more advanced user

[Tim Marshall]

Richard Sherratt wrote:

One of my customers is about to create several new positions for
internal Access Developers. These are not professional developers who
could sell their services on the open market, but more like advanced
user support people who can develop simple databases for their users.

Difficult, because at this level of user, there are so many different
areas with which they could be familiar or not. What might be a simple
test to you or I may indeed be simple to some of these potential
candidates, while to others it may be something they've never, ever done
before.

Further, anyone who's ever done an interview before as the interviewee
or interviewer knows that these things are stressful for the
interviewee. If your requirements are for an Armed Services or police
officer or someone who will be able to develop something within 30
minutes while under the gun, ie, be able to perform and think clearly
under extreme stress, then by all means do some kind of test, but I
wouldn't recommend it.

My recommendation would be to have the potential applicants do something
beforehand and then show you their work. When I've interviewed for
civil/electrical/mechanical engineering positions, it's this sort of
approach I prefer, because in those areas potential areas of experience
is vast. You could have the applicants show you how they put stuff
together and you could at the same time look to see how well a person
documents his/her code, if they are consistent in formatting, etc.

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[Albert D. Kallal]

The first suggestion I can give is to perhaps hire someone to do the hiring!

I know of a number of small business that in fact did that, and the results
were very good.

The other issue is how advanced and what kind of skills they need. I would
simply go for the best skills that the budgets can afford, and attract. To
actually make a position where the person is going to be developing full
time simply requires nothing less then a good developer.

The problem here is you got a situation where we want some support kind of
guy and that person is to do some developing on the side. This does not
sound like company that is committed to hiring someone to develop quality
software.

If that company wants good software developed, then the current approach
don't sound very good. All too often companies think that the software
development side is like repairing photo-copiers, or doing tech support. So,
after two years or so, you then find the software developed is not very
good, and it needs to be re-done. Have you saved any money? Perhaps in place
of the two years, you hire a good quality developer for 4 months. Now you
got something that will last the company 10, or even more years. further,
you get something that is much BETTER and will cost MUCH LESS over time.

The company could also hire a secretary, and she might have some mechanic
skills that they also could put to use in the yard to keep the equipment
going, but really, the best solution is to hire a very good secretary, and
hire good mechanics. I don't know why this whole thinking process breaks
down when it comes to software. The company does not ask employees to take a
dental course, and then start doing fillings on each employee to save on the
dental plan.

I think if they want good software, then they better hire good developers.
To do otherwise means LOTS OF money gets wasted. You have to understand that
software does NOT rust. That means the company will be stuck with that
software for YEARS AND YEARS! Even long after that employee moves one.

It is not like you are hiring someone to write a letter that in 1 or 2 weeks
from now it don't matter. Many job tasks in a company are completed in a
rather short time, and most tasks are done, or do not CONTINUE to effect the
operations of the company.

With software, you are building information systems, and you SHOULD be
looking to build things that last for years and years. Software development
is much different then support, or other tasks that are done for the day,
and tend not to have long term ramifications on the company. Software
effects operations within the company, and these decisions can effect the
company for YEARS AND YEARS!

So, software lasts a long time (or, you just throw it out..and waste money.
You might as well throw out other company equipment like tables and chairs
if you want to throw out things that last a long time, and have been paid
for).

So, I don't know the particular situation, but hiring a good developer is
the only way I would go, or you will have a company with a never ending
series of products that only last a 1 or 2 years, and then kind of fade
away.

So, hire a good developer...

Further, while the tests should include some ms-access stuff, what you
really want to do is hire someone with first rate skills.

There is some good points and thoughts in the following article:

The Guerrilla Guide to Interviewing
By Joel Spolsky
Thursday, March 23, 2000
http://www.joelonsoftware.com/articl...000000073.html
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

[David W. Fenton]

"Beacher" <be*****@gmail.com> wrote in
news:11**********************@z14g2000cwz.googlegr oups.com:

Involve some subforms/datagrids in the testing too... that usually
shows some signs of a bit more advanced user

And if they call subforms "datagrids" definitely throw them out of
the applicant pool, since that shows they ain't no Access developer.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Richard Sherratt <ri**************@NOTHINGHEREbrunsley.com.au> wrote
in news:id********************************@4ax.com:

I was thinking of getting them to develop a simple form, but with
elements that need a moderate knowledge of VBA.

One think you might be able to do is give them some problems and ask
them how they'd solve them, in words. This kind of question allows
someone to correctly answer a question they'd have to do research on
to actually implement.

What you're looking for, it seems to me, are not people who already
know everything about Access, but people who understand it well
enough to learn to do the things you'll need them to do. If you
design your interview process to find out who is a problem solver
and knows how to think, you won't need to worry about exactly which
things they already know how to do when they walk in the door.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Trevor Best]

Richard Sherratt wrote:

One of my customers is about to create several new positions for
internal Access Developers. These are not professional developers who
could sell their services on the open market, but more like advanced
user support people who can develop simple databases for their users.
I've been coaching one of these guys and have got him to the stage
where he's able to generate Word and Excel documents and then attach
them to Outlook email messages. Nothing particularly advanced, but
more than you'd expect from the average user who can develop, say, a
membership list for his local club.

The customer is not a technical guy, but he want's to be able to test
candidates and determine who can cut code and who is a user/developer.
He's thinking of a 30 minute test as part of the interview process.
He's needs an objective rating rather than a subjective assessment.
It's a govt. dept. and unsuccessful applicants can appeal if they
think they were wronged.

I was thinking of getting them to develop a simple form, but with
elements that need a moderate knowledge of VBA.

We use a questionaire in the interview, it's not perfect, but it sure as
hell gets rid of the numpties and wannabe programmers.

Our last guy we took on, it was clear he didn't know Access (and he told
us this up front) but it was also clear he was strong in VB, which was
useful to us and learning Access and SQL Server shouldn't be a big
problem for him (speak of the devil, I just saw him sign into MSN
messenger:-). Another candidate, who looked to be "the one" from was
only told about the test on the morning of the interview (agency's goof,
we're open about it) and he pulled out of the interview admitting that
he'd over-egged his CV. So the test works without having to sit it as
well :-)

--
[OO=00=OO]

[Larry Linson]

I had a colleague who eliminated almost all appicants by asking them to tell
him about "OpenArgs". Then he used some questions that had been posted to
advertise some certification training.

I once went for an interview at a recruiting firm in the Access 97 / Access
2000 era... found their "test" was for Access 2.0, but I "aced" it because
was currently working on a contract maintaining a big Access 2.0 app. It was
just about as stupid as any test could be... like asking what a particular
error code meant. I got that one, too, because I'd encountered it within the
past few days.

Larry Linson
Microsoft Access MVP

[Richard Sherratt]

On 24 Jun 2005 05:45:35 -0700, "Beacher" <be*****@gmail.com> wrote:

Involve some subforms/datagrids in the testing too... that usually
shows some signs of a bit more advanced user

How easily we forget when we were learning :-)

Thanks.

--
Regards.
Richard.

[Bas Cost Budde]

A test will always contain the danger ending up just testing whether
someone can make a test.

I think you should consider different subtests, for analysis, design,
and implementation.

Larry Linson wrote:

I had a colleague who eliminated almost all appicants by asking them to tell
him about "OpenArgs". Then he used some questions that had been posted to
advertise some certification training.

I once went for an interview at a recruiting firm in the Access 97 / Access
2000 era... found their "test" was for Access 2.0, but I "aced" it because
was currently working on a contract maintaining a big Access 2.0 app. It was
just about as stupid as any test could be... like asking what a particular
error code meant. I got that one, too, because I'd encountered it within the
past few days.

Larry Linson
Microsoft Access MVP

--
Bas Cost Budde, Holland
http://www.heuveltop.nl/BasCB/msac_index.html

[lylefair]

One problem with tests is that they often ask questions about the
basics. Basics are basics, but they are not always the best way to do
things.
Hands up, please! How many use "OpenArgs". I never do.

My suggestion to test the competence applicants: Photocopy ten of the
most recent technical posts from CDMA shortly before the interviews.
Give each applicant a copy to peruse before the interview. Ask him/her
to comment on one or more posts of interest.

[Rick Brandt]

<ly******@yahoo.ca> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

One problem with tests is that they often ask questions about the
basics. Basics are basics, but they are not always the best way to do
things.
Hands up, please! How many use "OpenArgs". I never do.

My suggestion to test the competence applicants: Photocopy ten of the
most recent technical posts from CDMA shortly before the interviews.
Give each applicant a copy to peruse before the interview. Ask him/her
to comment on one or more posts of interest.

I would not think a person incompetent who didn't use OpenArgs. I likely would
think them incompetent if they didn't know what it was.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[rkc]

Rick Brandt wrote:

I would not think a person incompetent who didn't use OpenArgs. I likely would
think them incompetent if they didn't know what it was.

I would question their competence if they knew what it was, used it
regularly, but didn't know how to pass more than one value. You see
it all the time in this ng.

[David W. Fenton]

rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:Dw*******************@twister.nyroc.rr.com:

Rick Brandt wrote:

I would not think a person incompetent who didn't use OpenArgs.
I likely would think them incompetent if they didn't know what it
was.

I would question their competence if they knew what it was, used
it regularly, but didn't know how to pass more than one value. You
see it all the time in this ng.

Ack, to me, that's exactly what's *wrong* with OpenArgs, is because
people tend to latch onto it as the only way to pass information
into a form, ignoring other possibilities, like opening the form
hidden and changing properties before revealing it, or using custom
public form properties and methods to set up the form before
revealing it, or, better than all of these, using some kind of data
storage structure outside the form to get the multiple pieces of
information to it (a custom collection, an array or a class module;
I prefer the latter).

Of course, if you ask "explain what OpenArgs is, what you consider
the pros and cons of its use to be, and what are alternatives to
using it?" then I'd think you'd asked a very good question.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[rkc]

David W. Fenton wrote:

rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:Dw*******************@twister.nyroc.rr.com:

Rick Brandt wrote:

I would not think a person incompetent who didn't use OpenArgs.
I likely would think them incompetent if they didn't know what it
was.

I would question their competence if they knew what it was, used
it regularly, but didn't know how to pass more than one value. You
see it all the time in this ng.

Ack, to me, that's exactly what's *wrong* with OpenArgs, is because
people tend to latch onto it as the only way to pass information
into a form, ignoring other possibilities, like opening the form
hidden and changing properties before revealing it, or using custom
public form properties and methods to set up the form before
revealing it, or, better than all of these, using some kind of data
storage structure outside the form to get the multiple pieces of
information to it (a custom collection, an array or a class module;
I prefer the latter).

I couldn't agree more, but code examples that treat a form as an
object are as few and far between as those that aren't completely
coded in some kind of gui event handler. If you're a copy and paste
artist that's what you end up doing.

[Richard Sherratt]

On Fri, 24 Jun 2005 11:09:34 -0230, Tim Marshall
<TI****@PurplePandaChasers.Moertherium> wrote:

Richard Sherratt wrote:

One of my customers is about to create several new positions for
internal Access Developers. These are not professional developers who
could sell their services on the open market, but more like advanced
user support people who can develop simple databases for their users.
Difficult, because at this level of user, there are so many different
areas with which they could be familiar or not. What might be a simple
test to you or I may indeed be simple to some of these potential
candidates, while to others it may be something they've never, ever done
before.

Further, anyone who's ever done an interview before as the interviewee
or interviewer knows that these things are stressful for the
interviewee. If your requirements are for an Armed Services or police
officer or someone who will be able to develop something within 30
minutes while under the gun, ie, be able to perform and think clearly
under extreme stress, then by all means do some kind of test, but I
wouldn't recommend it.

The candidates will be public servants. Some of them will be ex Armed
Forces or police officers.
My recommendation would be to have the potential applicants do something
beforehand and then show you their work. When I've interviewed for
civil/electrical/mechanical engineering positions, it's this sort of
approach I prefer, because in those areas potential areas of experience
is vast. You could have the applicants show you how they put stuff
together and you could at the same time look to see how well a person
documents his/her code, if they are consistent in formatting, etc.

The public service rules say that I cannot be involved in the actual
interview or assessment of the interview. The decision makers are
non-technical and are conscious that they could not evaluate the
technical skills of the candidates in an appeal-proof way without some
sort of go/no go or numerical scale test.

It's a tough one.

--
Regards.
Richard.

[Richard Sherratt]

On Fri, 24 Jun 2005 21:57:57 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Richard Sherratt <ri**************@NOTHINGHEREbrunsley.com.au> wrote
in news:id********************************@4ax.com:

I was thinking of getting them to develop a simple form, but with
elements that need a moderate knowledge of VBA.

One think you might be able to do is give them some problems and ask
them how they'd solve them, in words. This kind of question allows
someone to correctly answer a question they'd have to do research on
to actually implement.

What you're looking for, it seems to me, are not people who already
know everything about Access, but people who understand it well
enough to learn to do the things you'll need them to do. If you
design your interview process to find out who is a problem solver
and knows how to think, you won't need to worry about exactly which
things they already know how to do when they walk in the door.

That makes sense. Everything would be simple if I could be part of the
interview process.

--
Regards.
Richard.

[Mike Preston]

On Mon, 27 Jun 2005 07:17:07 GMT, Richard Sherratt
<ri**************@NOTHINGHEREbrunsley.com.au> wrote:

It's a tough one.

Indeed it is.

But it sounds to me like you want to use a test to filter out those
that:

1) are less knowledgeable

and

2) have bad habits.

A series of t/f questions should get you close.

Things like:

Question 1) I am familiar with the Access term "OpenArgs" and know how
to implement it when appropriate.

Question 2) I am familiar with the Access term "CloseArgs" and know
how to implement it when appropriate.

Question 63) I can pass information to a query using OpenArgs

Question 64) I can pass information to a form using OpenArgs

Question 65) I can pass information to the subroutine "basFindRecord"
using the vba command: docmd.OpenArgs (basFindRecord,"MyOpenArgs")

Question 134) Before deciding whether to use OpenArgs I would first
see if the information is already stored and available in another open
and visible form.

Question 135) Before deciding whether to use OpenArgs I would first
see if the information is already stored and available in another open
but not visible form

How long can you make this thing? I'd think something like 1,500 or
so T/F questions should get you something with statistical
significance. <g,d&r>

But I'm serious about the format. If you can't be involved I can't
see any other way to establish a ranking of candidates.

Of course, it really should be an Access program so that a particular
T/F answer branches to a specific set of questions. In this way, if
someone answers the first few wrong (or enough wrong) you can just
route them to the:

"Thank you for your participation. Your results have been forwarded."

screen.

Of course, you might have requirements that preclude variable testing
and, if so, then everybody must be given the same questions. But I
can see this being quite the interesting project.

Good luck,

mike

[David W. Fenton]

Richard Sherratt <ri**************@NOTHINGHEREbrunsley.com.au> wrote
in news:25********************************@4ax.com:

On Fri, 24 Jun 2005 21:57:57 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Richard Sherratt <ri**************@NOTHINGHEREbrunsley.com.au>
wrote in news:id********************************@4ax.com:

I was thinking of getting them to develop a simple form, but
with elements that need a moderate knowledge of VBA.

One think you might be able to do is give them some problems and
ask them how they'd solve them, in words. This kind of question
allows someone to correctly answer a question they'd have to do
research on to actually implement.

What you're looking for, it seems to me, are not people who
already know everything about Access, but people who understand it
well enough to learn to do the things you'll need them to do. If
you design your interview process to find out who is a problem
solver and knows how to think, you won't need to worry about
exactly which things they already know how to do when they walk in
the door.

That makes sense. Everything would be simple if I could be part of
the interview process.

Oops. I didn't realize there was a brain-dead HR department involved
that wasn't going to have subject specialists present at the
interviews.

Surely the final round of interviews would involve you or somebody
who has enough knowledge to ask the questions you'd ask?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Richard Sherratt <ri**************@NOTHINGHEREbrunsley.com.au> wrote
in news:if********************************@4ax.com:

The public service rules say that I cannot be involved in the
actual interview or assessment of the interview. The decision
makers are non-technical and are conscious that they could not
evaluate the technical skills of the candidates in an appeal-proof
way without some sort of go/no go or numerical scale test.

It's a tough one.

Sounds like process that's been designed on purpose to guarantee
that the most qualified applicant is not hired.

What stupid, stupid rules.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Richard Sherratt]

On Mon, 27 Jun 2005 09:13:54 GMT, mb******@pacbell.net.invalid (Mike
Preston) wrote:

On Mon, 27 Jun 2005 07:17:07 GMT, Richard Sherratt
<ri**************@NOTHINGHEREbrunsley.com.au> wrote:

It's a tough one.
Indeed it is.

But it sounds to me like you want to use a test to filter out those
that:

1) are less knowledgeable

and

2) have bad habits.

That's the idea.

<snip>
How long can you make this thing? I'd think something like 1,500 or
so T/F questions should get you something with statistical
significance. <g,d&r>
7 down. Only 1,493 to go. Easy :-)
But I'm serious about the format. If you can't be involved I can't
see any other way to establish a ranking of candidates.

It sounds like a better idea than trying to get them to develop stuff.
Thanks.

--
Regards.
Richard.

[Richard Sherratt]

On Mon, 27 Jun 2005 15:53:13 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Richard Sherratt <ri**************@NOTHINGHEREbrunsley.com.au> wrote
in news:if********************************@4ax.com:

The public service rules say that I cannot be involved in the
actual interview or assessment of the interview. The decision
makers are non-technical and are conscious that they could not
evaluate the technical skills of the candidates in an appeal-proof
way without some sort of go/no go or numerical scale test.

It's a tough one.
Sounds like process that's been designed on purpose to guarantee
that the most qualified applicant is not hired.

Not quite, but it may achieve that result.
What stupid, stupid rules.

--
Regards.
Richard.

[Richard Sherratt]

On Mon, 27 Jun 2005 15:51:33 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Richard Sherratt <ri**************@NOTHINGHEREbrunsley.com.au> wrote
in news:25********************************@4ax.com:

Everything would be simple if I could be part of
the interview process.

Oops. I didn't realize there was a brain-dead HR department involved
that wasn't going to have subject specialists present at the
interviews.

Surely the final round of interviews would involve you or somebody
who has enough knowledge to ask the questions you'd ask?

We're working on it.

--
Regards.
Richard.

[Larry Linson]

"Rick Brandt" <ri*********@hotmail.com> wrote

I would not think a person incompetent
who didn't use OpenArgs. I likely would
think them incompetent if they didn't know
what it was.

That was close to what my friend thought, except I don't think he thought
they were necessarily "incompetent", just that they didn't know Access
development issues well enough to fit his needs.

Larry

[Larry Linson]

Yep, a better question would be which of the following are valid ways to
pass information to a form that you open, and then list some valid and
invalid items.

Still, my friend eliminated a great many who did not have a clue as to what
OpenArgs meant.

Larry
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.78...

rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:Dw*******************@twister.nyroc.rr.com:

Rick Brandt wrote:

I would not think a person incompetent who didn't use OpenArgs.
I likely would think them incompetent if they didn't know what it
was.

I would question their competence if they knew what it was, used
it regularly, but didn't know how to pass more than one value. You
see it all the time in this ng.

Ack, to me, that's exactly what's *wrong* with OpenArgs, is because
people tend to latch onto it as the only way to pass information
into a form, ignoring other possibilities, like opening the form
hidden and changing properties before revealing it, or using custom
public form properties and methods to set up the form before
revealing it, or, better than all of these, using some kind of data
storage structure outside the form to get the multiple pieces of
information to it (a custom collection, an array or a class module;
I prefer the latter).

Of course, if you ask "explain what OpenArgs is, what you consider
the pros and cons of its use to be, and what are alternatives to
using it?" then I'd think you'd asked a very good question.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Tim Marshall]

Richard Sherratt wrote:

On Mon, 27 Jun 2005 15:51:33 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Oops. I didn't realize there was a brain-dead HR department involved
that wasn't going to have subject specialists present at the
interviews.

Surely the final round of interviews would involve you or somebody
who has enough knowledge to ask the questions you'd ask?

We're working on it.

Crumbs, it's amazing how some HR departments seem to do their best to
make work for themselves at the expense of other parts of an organization.

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[David W. Fenton]

"Larry Linson" <bo*****@localhost.not> wrote in
news:tN3we.3566$rE6.2832@trnddc06:

Yep, a better question would be which of the following are valid
ways to pass information to a form that you open, and then list
some valid and invalid items.

I don't think that's a better question at all, since it isn't
general enough. A general question allows someone who may not know
the specific method you're asking about (which I think is bogus to
begin with -- if you've got multiple items, something other than
OpenArgs ought to be used, in my opinion; multiple parameters in
OpenArgs is a sign of a design error, in my opinion) to convey what
they know about the topic in general.

Someone may not use a specific Access feature for particular
reasons, and knowing those reasons and having them explain the
alternatives seems to me to tell you a helluva lot more about the
person's level of knowledge and potential to learn than asking a
straight-out implementation question with only one basic answer.

Since the requirement for the job was not specific knowledge but
ability to learn, I think my kind of question gets the job done much
better.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Larry Linson]

Given that the administrator of the test, by corporate fiat, have no
knowledge of the subject, and the knowledgeable parties are not allowed to
be there, I was thinking of a multiple-answer, multiple-choice type
question. I wouldn't want to be giving essay tests to most of the programmer
candidates I've encountered lately.

I didn't like the rituals that developed over the years around the hiring
process, but the typical techie is powerless to change them in the corporate
environment.

Larry
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.90...

"Larry Linson" <bo*****@localhost.not> wrote in
news:tN3we.3566$rE6.2832@trnddc06:

Yep, a better question would be which of the following are valid
ways to pass information to a form that you open, and then list
some valid and invalid items.

I don't think that's a better question at all, since it isn't
general enough. A general question allows someone who may not know
the specific method you're asking about (which I think is bogus to
begin with -- if you've got multiple items, something other than
OpenArgs ought to be used, in my opinion; multiple parameters in
OpenArgs is a sign of a design error, in my opinion) to convey what
they know about the topic in general.

Someone may not use a specific Access feature for particular
reasons, and knowing those reasons and having them explain the
alternatives seems to me to tell you a helluva lot more about the
person's level of knowledge and potential to learn than asking a
straight-out implementation question with only one basic answer.

Since the requirement for the job was not specific knowledge but
ability to learn, I think my kind of question gets the job done much
better.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Lynne D]

There are many skills involved in developing a user friendly, robust and
function rich application.

Adhering to good programming principles and best practices during
development is VERY IMPORTANT,

HOWEVER...it is equally important to ensure your candidates have an
excellent understanding of users and their requirements, that they can
ensure the correct data is collected in the first place so that the
required information can be output as an end product (presuming the
system is to be used as a reporting tool).

To ensure the candidate has a sound knowledge of programming constructs
is only the tip of the iceberg,

how good is their procedure analysis, communication, listening skills,
understanding of data manipulation and what standard of documentation
(if any) will they be leaving to support their development?

Have you thought of references from previous clients who have used the
developer?

Or employing a contractor through a specialist agency, (a contract will
help to ensure that you end up with the standard of candidate AND system
you require).

In fairness to skilled developers, it has to be said that:-
There should also be a way for candidates to "Vet" clients, there are
many clients who do not give full support to the developer during the
development process, I have personally taken on projects in which I have
been unable to schedule meetings with users to carry out requirements
analysis etc due to them going on holiday or days off sick or just "not
having enough time"... and when it comes to testing, it is amazing how
quickly people become busy and unavaiable for all sorts of reasons, I
have had to carry out development work offsite (at home in my own time)
because the client could not find a spare work station for me to sit at,
or a reliable printer for documentation, I was once asked to build a
system to be shared over a LAN, only to find that weeks into the
development, terminal services were to be used instead, so data access
pages had to be developed...

When you find a candidate or candidates, give them the support they
require during the development.

Good luck

LynneD


*** Sent via Developersdex http://www.developersdex.com ***

[Larry Linson]

Good points, Lynne, _if_ the developer is expected to be the
jack-of-all-trades implied: business analyst collecting requirements,
software architect and designer, as well as "creator of database
applications". And, that is often the case!

Larry Linson
Microsoft Access MVP

"Lynne D" <ly*********@virgin.net> wrote in message
news:NO****************@news.uswest.net...

There are many skills involved in developing a user friendly, robust and
function rich application.

Adhering to good programming principles and best practices during
development is VERY IMPORTANT,

HOWEVER...it is equally important to ensure your candidates have an
excellent understanding of users and their requirements, that they can
ensure the correct data is collected in the first place so that the
required information can be output as an end product (presuming the
system is to be used as a reporting tool).

To ensure the candidate has a sound knowledge of programming constructs
is only the tip of the iceberg,

how good is their procedure analysis, communication, listening skills,
understanding of data manipulation and what standard of documentation
(if any) will they be leaving to support their development?

Have you thought of references from previous clients who have used the
developer?

Or employing a contractor through a specialist agency, (a contract will
help to ensure that you end up with the standard of candidate AND system
you require).

In fairness to skilled developers, it has to be said that:-
There should also be a way for candidates to "Vet" clients, there are
many clients who do not give full support to the developer during the
development process, I have personally taken on projects in which I have
been unable to schedule meetings with users to carry out requirements
analysis etc due to them going on holiday or days off sick or just "not
having enough time"... and when it comes to testing, it is amazing how
quickly people become busy and unavaiable for all sorts of reasons, I
have had to carry out development work offsite (at home in my own time)
because the client could not find a spare work station for me to sit at,
or a reliable printer for documentation, I was once asked to build a
system to be shared over a LAN, only to find that weeks into the
development, terminal services were to be used instead, so data access
pages had to be developed...

When you find a candidate or candidates, give them the support they
require during the development.

Good luck

LynneD


*** Sent via Developersdex http://www.developersdex.com ***

[Lyle Fairfield]

Lynne D <ly*********@virgin.net> wrote in news:NOixe.81$md4.10269
@news.uswest.net:

There are many skills involved in developing a user friendly, robust and
function rich application.

Adhering to good programming principles and best practices during
development is VERY IMPORTANT,

HOWEVER...it is equally important to ensure your candidates have an
excellent understanding of users and their requirements, that they can
ensure the correct data is collected in the first place so that the
required information can be output as an end product (presuming the
system is to be used as a reporting tool).

To ensure the candidate has a sound knowledge of programming constructs
is only the tip of the iceberg,

how good is their procedure analysis, communication, listening skills,
understanding of data manipulation and what standard of documentation
(if any) will they be leaving to support their development?

Sounds like a great person. Do you know any? Would he or she be an
interviewer or an interviewee? Could such a paragon of Access Development
expect three hundred (300) USD per hour, or more? Would such a person fit in
the organizations you know ... feel comfortable, challenged, rewarded and
satisfied?

Aesop & Grimm Inc? ... yes, maybe.

[Lynne D]

Try £20 ph...

Reality Check Inc

:0)

*** Sent via Developersdex http://www.developersdex.com ***