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.goo glegroups.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************ **@NOTHINGHEREb runsley.com.au> wrote
in news:id******** *************** *********@4ax.c om:

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