First up, I’m not a fan of ‘evaluating skill’ for a job candidate. It’s never accurate in my experience. In fact I’m not sure I’ve seen that process work in anyone’s favor. Best case you are more confident in the hire. More likely it sets a bad tone for the employee before they even start ('ok this is going to be like primary school all over again).
Another way to think of it is like finding someone to fix your car - you want the most qualified and capable available. But even for the best mechanic in the world their favorite wrench is a wrench - asking them how they use their favorite wrench isn’t going to explain why they’re the best mechanic in the world. Instead ask ‘why they like it,’ and the like - you’ll get better answers there. The creativity and passion of the mechanic will shine through there, and that’s what matters and that will come through in the ‘why’ question.
That said, if you had to get into a ‘skills test’, try for stuff like this:
- Stay away from workflow questions and ‘technical’ stuff. That will almost always be invalid 6 -12 months from now as the industry moves too quick. Speak to the concepts instead, and ask in a way which gets them to teach you, not which gets them to recite a well known blog post. My reasoning there is that if you can’t teach a novice user something, or at least have a conversation with a peer about it than you’re certainly not an expert about it. One such example: “Let’s say I was a new user who’d never opened the program before - how would you explain the different types of lacing to me?”
- Complexity is generally bad - aim for simplicity and usability instead. "Can you tell me about a time you’ve found a way to take a really complex task or process and simplified it?
- Most of the time if you pose your questions around Revit you’ll expose a ‘strong’ dynamo user from a ‘novice’ or ‘non-user’. “What’s your favorite method of moving content between Revit models?” is a better line of questioning than the ‘via dynamo’ as it’s not leading the witness (and rooms don’t really have geometry
). - All of your challenging questions are way too specific to expose anything of use unless you sit them in front of a computer and test them on ‘how’. That’ll quickly be pointless - to @Nick_Boyts point there are too many ways to do anything. Focus instead on what ‘generic’ debate topics as if you’re able to ‘talk’ about stuff in an intelligent way it’s a pretty strong sign you know it and have thought through the issues at play. Don’t focus on if they agree with you but rather how they discuss the topic and if they are basing their opinion on use (that will be obvious pretty quickly in most cases). Ideally you’d even have some disagreement on a topic, but in a professional way, so that you’ll understand how you two will work together when everyone can’t get their way. Topics to discuss are things like:
- Packages: Require all ‘code’ live in the graph or only use standard nodes vs ok with ‘in house’ developed nodes only vs ok with ‘this blessed list of packages’ vs anything you can get your hands on.
- Python nodes: Ok to use all python in every graph in fact it should be the most used node in your library vs python only in custom nodes vs no python ever.
- Graph Documentation: groups, design script annotation, Python annotation, Python libraries and package management, coloring standards, wiring standards, how-to documentation, troubleshooting documentation, etc…
- Graph usage and file locations: Project specific only vs office standards vs ‘one offs’. What lives where, why to use which method when, etc…
- Element Binding usage and management: I have said enough about this so no more shall be said here.
- User interface standards and techniques: Launch by Dynamo or by Dynamo Player? Datashapes vs standard UI vs custom UI? Something in between?
- Other Topics: Anyone could likely dole out and laundry list of topics where you can have a conflicting views on.
