Indeed as you say, to separate the boys from men you’d ask questions on a different level. This post was mostly written with “boys” in mind – developers who will need to write code to automate Excel to solve problems of low to medium complexity.

To be honest, I think that an Excel VBA application should never reach beyond a certain level of complexity at all. If it does, I’d wager that you’ve chosen the wrong tool. Excel VBA is a specialized tool for solving a specific kind of problem, not an all-purpose language.

I think what is lacking from above is the serious OOP questions, even though that VBA is not a 100% OOP but it is as close as. For example, what are the interfaces for? Where and how do you encapsulate code? what are the benefits of using Classes as oppose to modules, how do you make a simple class object, how do you start and dispose of classes…

Also some questions on the how to make a singleton design patterns, what is good and bad with them? also, hash tables or arrays? when would you use dictionary or collection object and why?

This I believe will separate the boys from men!

I have been on both side of the table and when in interview, asking specific task to do is the worst test. General knowledge of something is one thing, but asking someone to write code is another! let’s say you have worked with one particular technology (InterOps for integration of excel in C sharp) then asking the poor interviewee about that specific test, is pointless. It is better to ask if he/she knows the subject and give examples of where and how to use it.

Anyhow, that is my opinion.

Link to the wrong article! http://wp.me/pN8iB-1r

As I said on another post, I found this really useful. It inspired me to do my own!

http://wp.me/pN8iB-1D

thanks again -john