Has anyone had experience testing people for Dynamo skills?
A colleague brought it up to me when asking how he could find the right skills for a role that required Dynamo. It seems like we take each other’s word for it because there isn’t a Dynamo ‘white board’ coding test or anything like that.
I know it may sound excessive to test someone instead of looking for their experience and examples but it’s a good point to make if you don’t have much else to refer to from the prospect’s application.
So what would be a standard way to challenge a user to see if they have the skills and aren’t making things up for a position?
Here’s how I would create a basic QA session about Dynamo for a prospect.
Warm up:
- How many years have you been using Dynamo?
- What have you used the software for?
- Are you familiar with different packages of nodes?
- How comfortable are you with list management in Dynamo?
Workflow Questions:
- Describe the most complex script you made and what it is used for
- How would you create a custom node and when would this be a good idea to do
- What nodes and methods would you use to import non-Revit model content (rhino, Civil 3D, CAD, etc) into Revit elements using Dynamo?
- Describe a way you can import room geometry from one Revit model into another using Dynamo
Challenging Questions:
- How would you start a Python node template, what content would go into the code?
- Can you think of a script that can write content from a spreadsheet to update a Revit schedule which then updates a the Sheet index?
- How would you take linestyles from one model and convert them to linestlyes into another model?
That’s all off the top of my head.
These are issues we see on this forum all the time so many of us would be accustomed to solutions for these problems. Though it does feel like either I am missing something or these questions aren’t good enough.
This udemy course has some Dynamo skills training content:
Anyone have examples of interview questions that would be good to find out a person’s Dynamo standing? It would be great to see perspectives from people working in Construction, MEP, Civil and other fields.
1 Like
I think it’s important to clarify that this isn’t so much a “test looking for answers” as it is a “conversation discussing solutions.”
Determining the amount of experience someone has with something like Dynamo is difficult to do, but it’s something that’s becoming increasingly common and important. The kinds of problems we deal with, especially those that tend to use Dynamo as a solution, are very open-ended. There is rarely one singular “correct” solution. The point of these conversations should be to determine how a prospective user might solve these common problems - which parts of Dynamo they’re comfortable with and which parts they may struggle or have no experience with. The example questions you’ve provided seem to do that (if not get a little specific at times). Offering specific problems isn’t a bad thing if they’re exactly what you’re looking to solve, but they may not be the best indicator of someone’s knowledge of the subject.
3 Likes
Honestly, I know people might not agree but forum presence can be a pretty good indicator. Asking for their Dynamo forum username shouldn’t be an issue. In the past, during interviews my Dynamo forum’s profile was brought up by the interviewer and began the talk of my experience with Dynamo specifically.
5 Likes
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.
6 Likes