I’ve just been called on to come up with questions for an interview tomorrow morning. The job would primarily be building small Access and Excel apps for our users. For instance, a click-button app that will import pre-existing data from several sources (Access, Excel, or CSV), do some data-crunching, then output a report. That kind of thing, generally single-user apps.
The only relevant experience she shows is that she’s done some data analysis with unspecified software. (Don’t ask why we’re even interviewing her, it’s a long, sad story.)
I know enough to be able to tell if she’s BSing answers, I just need some good ideas for questions. Basic coding questions, questions to see if she actually has any concept of how databases work, etc.
Our company specializes in database applications. This might be a little too hard core for your purposes, but one of the questions I ask all interviewees is, “Can you think of a reason why you might want to denormalize a database?” This tells me a couple of things: 1) Do they even know the concept of normalization?, and 2) Do they have enough real-world experience to know when you might want to break the rules? (“Normalize until it hurts, then denomalize until it works”).
There’s also specific Access questions you can ask to verify that they actually know what they claim. I can give you a few of these if you’d like. I’m always amazed at the number of people who claim skills they don’t have. It would be like me claiming to be fluent in French. Don’t they know they’ll be busted?
Specific questions would be great! Like I said, I know enough to figure out if she’s bluffing the answers, but I don’t normally hire so I’m at a loss for the best things to ask.
I know I’ve seen some simple coding tests (to see if they understand looping concepts, e.g.) but I haven’t been able to find anything. We’re not doing anything hardcore, but they will need to do some VBA work to accomplish the tasks.
I kinda like your denormalization question. It would at least give me a benchmark on the level of db knowledge. I was also trying to think of how to ask something similar on a lower level - see if she’s got any idea of how to structure a db. (Some of the user-built dbs I’ve had to redo - oy!)
I’m really not sure about her skillset - apparently the answer to every question so far has been “Yeah, I can do that, no problem.” But the app / resume have almost no relevant skills/experience listed.
I guess they just figure if they can bluff their way in, then they’ll pick it up as they go. Or something. I don’t know, seems stupid to me.
Redtail, doesn’t sound like you’re hiring a programmer – sounds like you’re looking for a general Excel/Access guru who can build usable forms in Access. The tasks you describe in your OP can be performed with zero (or at worst, very minimal) Visual Basic knowledge. Similarly, knowing a little SQL can help create niftier Access queries, but is not necessary.
I can come up with some good questions to ask later on – questions related to designing forms in Access are a must.
One super-simple Excel question you can ask:
Q. How can one create a macro in Excel without using Visual Basic?
A. *Use the Record New Macro function by clicking on Tools/Macros/Record New Macro * .
If your candidate were unfamiliar with this feature, I’d summarily pass her over. If it were me.
bordelond, yeah, not a programmer but an access/excel guru is exactly right.
However IME with these apps, that requires at least a little bit of VBA, hence wanting to check that they’re at least familiar with coding concepts.
Forms-related questions would be a great help, as that’s my weakest area.
Basic usage questions - great idea, hadn’t thought of that! I was concentrating on the less common stuff, but there’s no point in going there if they don’t know they basics.
Ask her how she would import data from an Access database into an Excel spreadsheet. (Find out if she knows about configuring OLEDB or ODBC data sources )
Can you actually set her a practical test, or only a verbal interview? If you can set her a practical, have her write an Excel macro that takes a customer ID as input, looks at the Northwind sample database in Access, and lists that customers purchases in rows on the spreadsheet. This would show evidence that she understands at least basic macro programming and simple SQL.
Some general Access questions off the top of my head. I’d say they’re pretty much Beginning to Intermediate level.
[ul]
[li]What are the different field sizes for a Number data type?[/li][li]What are the advantages and disadvantages of using a Memo data type?[/li][li]How do you format a field so that a null (or empty) entry reads as “Unknown” or “None”?[/li][li]How do you change date formats?[/li][li]How do you change the placeholder for an Input Mask?[/li][li]You want to check whether a text box has been filled before the user can close a form. On what event and what object might you write the code?[/li][li]How do you insert today’s date in a report header?[/li][li]Why might you want to use an unbound control?[/li][li]What are the different types of queries (Select, Update, etc.).[/li][li]How do you create a parameter query?[/li][li]What are the different wild cards in Access?[/li][li]Why is it a good idea to split a database file?[/li][li]How do you prevent orphan records?[/li][li]Why might you want to use a DSUM function?[/li][li]What is the difference between a Right Outer Join and a Left Outer Join?[/li][li]What is the structure of a Select Case statement?[/li][li]What is the difference between a Function and a Procedure?[/li][/ul]
Yes, I was trying to think of a question to see if she knew datasources, that’s a good one.
I don’t think I can do a real practical test, but I am thinking of doing a couple of semi-practicals.
The fizzbuzz is good; I’m no programming god, but I did that in just a couple minutes the first time I saw it. Not language-specific, just the looping logic.
I was also thinking of presenting a basic dataset and output request and having her give me a generic database structure. Something like “You’ve got a list of employees by employee group, department, and division, including pay amounts. You need to report payroll totals for the organization, each division by department, each department by employee group, and a detail list for each employee group. How would you do this?” Not expecting a detailed, perfect solution, just a demonstration that she’s got a working understanding of normalization and how data relates to output.
The other one I’d thought of was asking how she’d copy a file from one location to another using Access or Excel, to see if she’s got a clue about the VBA objects.
If you want to really test her ability to write queries, try this:
You have a database with three tables. The first is STUDENTS with fields studentID and type, where type can be either graduate or undergraduate. The second is CLASSES with fields classID and name. The third is enrollment, which describes the many-to-many relationship between STUDENTS and CLASSES (i.e., the fields are studentID and classID, and this table describes which students are enrolled in each class). Write a query that will give the names of all classes in which no undergraduate students are enrolled.
It’s a pretty tough question, so think carefully before springing this one on her.
Those are really good, especially the ones I don’t know the answers to. :eek:
OK, I give on these. I think they’re all form/report related, which is where I’m sadly lacking.
[quote]
[li]Why is it a good idea to split a database file?[/li][/quote]
Are you talking about a split distribution? I think I get those, although I haven’t done any.
[quote]
[li]What are the advantages and disadvantages of using a Memo data type?[/li][/quote]
OK, what are the advantages? My policy is usually “avoid them like the plague unless there’s no other option for a comment field that won’t be used for much anyway”.
That would pretty much be my answer:). We’ve had a few fields, though, that required about 30,000 characters so we didn’t have much of a choice.
The main advantage of splitting an MDB file into a front end (forms, reports, and so on) and a back end (tables only) is that you can switch out the front ends for modifications without worrying about the data. Also, you can have multiple front ends to a single back end, so everyone is accessing the same data.
You can pretty much figure out the Format and Input Mask questions by looking at a field’s Format and Input Mask properties in the design view of a table.
The “Event” question can have several answers. The most obvious would be to place code on the OnClose event of the form to check for the value of a field, and to cancel the close if it’s null.
An unbound control is any control not bound to a particular field. A text box to return today’s date or a calculation would be an example.
An orphan record is one that exists without an associated “parent” record. For instance, an Invoice Detail record without the associated Invoice record. The easiest way to prevent orphan records in Access is by enforcing referential integrity for those tables.
That is a good one. We’ve used the classic Student-Class Event-Class relationship when I’ve taught Intermediate level Access to learn about the different join types in a query (find all classes without students, students without classes, etc.).
Sorry kids, didn’t mean to disappear. It got a bit crazy and they postponed the interview.
I wanted to say you guys are TERRIFIC!
With your questions, I was able to show clearly to a moderately-knowledgeable interviewer that this person doesn’t actually know anything about programming or databases or Access (and not much about Excel), and would be completely unsuited to the job.
Lessee, despite claims of having programmed applications in Access and other software, didn’t know Access datatypes, didn’t know what a join is, didn’t understand normalization (although she was familiar with the word), didn’t know any VBA (or any other coding/scripting), etc. Only had minimal knowledge of Excel.
Almost all of her work has been on Macs so she’s not actually done much with MS products. The “programs” she’s built have basically been form + macro on one-table databases, which just isn’t sufficient for the stuff we do. Nothing wrong with that, but not a good fit for us.
Thanks very, very much! You’ve saved me much hair-pulling, gnashing of teeth, and head-on-desk beating.
In fact, I’m keeping my list of questions and am going to try to get a chance to interview applicants as needed.
