As I interview developers, I would like to assess their comfort level and experience with Storyline. Has anyone created an assessment for this already that might be willing to share it with me? If not, might the hive mind consider sharing some questions they would ask of candidates? Thank you!
I would get them to build you a PoC, 4-5 slides is probably 2 hours work. I would specify the content, I have had a lot of developers rehash stuff from the community or even submit my own stuff.
I did an assessment for a large Elearning company that involved fixing a course built by someone else. One part was a progress bar that I completely rebuilt because their current bar was flawed.
I'm not a fan of asking developers to create work as part of an interview process. It really is asking them to make quite an investment in time and energy for, what is, an interview.
I much prefer Phil's second suggestion - show them a couple of slides with some basic issues, ask them to fix it (or talk through the issues) and allow them to explain how they might make it better (or different).
I'm not a fan of asking developers to create work as part of an interview process. It really is asking them to make quite an investment in time and energy for, what is, an interview.
It could show the committed developers, sometimes it is difficult for prospective clients to see how my work will fit with them. A PoC is probably 2-3 hours work, the assessment I completed took longer and although I was added to ether list of preferred developers I have never worked for them (in 3 years).
Hi Phil and Kevin! I was thinking of some questions for a survey to see if they even knew the basics. Like "How would you change the color of a rectangle from blue to green?" This would show if they knew states and triggers, correct? I suppose they could get the answers from Heroes or Google, but even that would show their willingness to research to find the right way.
Depends on what you are after, but changing colours for me would not show competency in using storyline. I would be more interested in their use of triggers, states, layers and variables conditions.
Yes I'm with Phil on that - knowledge of triggers, states, layers and variables (and if you really want to push them dreaded sliders!). Changing a font, a colour or swapping out one image to another really isn't going to sift the basic developers from those who know a bit more.
To be honest I'm more interested in why a developer did x and not y -their thought processes, what options they considered and why they chose to code the way that they did. If they have a portfolio of previous work, or literally anything they've developed previously that would be my starting point.
I always prefer to see actual work completed in Storyline. If you just ask for work samples it can be hard to gage how much of the work in the "sample" they actually completed, so asking for a PoC is the preferred way to go in my opinion.
The problem with asking for work samples is, more often than not, the prospective employee cannot show them because legally they are owned by the organization he/she works for and not available for public consumption.
I have a long development history using Macromedia Authorware, Director, Dreamweaver, and Flash (plus a whole ton of other tolls, many now defunct). When I was hired by my previous employer about 6 years ago, I had been "out of the game" for more than 5 years, and had ZERO experience with Articulate products (Storyline didn't exist when I exited the eLearning industry in 2008). Did that preclude me from picking up Storyline and applying my extensive background in eLearning design and development with this new tool? Hardly. In less than a week I was up-and-running with Storyline 2 creating engaging courses, finding bugs a few weeks later, and writing complex Javascript code to communicate with the LMS a week or two after that.
If a prospect can demonstrate, as Kevin Hayes said above, "why a developer did x and not y, their thought processes, what options they considered, and why they chose to code the way that they did," that means he/she can adapt to whatever tool you throw at him/her.
10 Replies
I would get them to build you a PoC, 4-5 slides is probably 2 hours work. I would specify the content, I have had a lot of developers rehash stuff from the community or even submit my own stuff.
I did an assessment for a large Elearning company that involved fixing a course built by someone else. One part was a progress bar that I completely rebuilt because their current bar was flawed.
I'm not a fan of asking developers to create work as part of an interview process. It really is asking them to make quite an investment in time and energy for, what is, an interview.
I much prefer Phil's second suggestion - show them a couple of slides with some basic issues, ask them to fix it (or talk through the issues) and allow them to explain how they might make it better (or different).
It could show the committed developers, sometimes it is difficult for prospective clients to see how my work will fit with them. A PoC is probably 2-3 hours work, the assessment I completed took longer and although I was added to ether list of preferred developers I have never worked for them (in 3 years).
Hi Phil and Kevin! I was thinking of some questions for a survey to see if they even knew the basics. Like "How would you change the color of a rectangle from blue to green?" This would show if they knew states and triggers, correct? I suppose they could get the answers from Heroes or Google, but even that would show their willingness to research to find the right way.
Depends on what you are after, but changing colours for me would not show competency in using storyline. I would be more interested in their use of triggers, states, layers and variables conditions.
I'm interested in gauging their level of competence. I guess you're right - a project with some errors might be the best way to go.
Yes I'm with Phil on that - knowledge of triggers, states, layers and variables (and if you really want to push them dreaded sliders!). Changing a font, a colour or swapping out one image to another really isn't going to sift the basic developers from those who know a bit more.
To be honest I'm more interested in why a developer did x and not y -their thought processes, what options they considered and why they chose to code the way that they did. If they have a portfolio of previous work, or literally anything they've developed previously that would be my starting point.
Reading over this maybe Phil and I are aiming too high? If you just want basic knowledge then a true/false or multiple choice/selection asking basic questions might be enough? If you need just basic technical questions a good source would be: https://articulate.com/support/article/Getting-Started-with-Articulate-Storyline-360
Correct Phil (as always).
It is important to get the interviewee to demonstrate that they understand how the features of Storyline work rather than, say, PowerPoint.
I always prefer to see actual work completed in Storyline. If you just ask for work samples it can be hard to gage how much of the work in the "sample" they actually completed, so asking for a PoC is the preferred way to go in my opinion.
The problem with asking for work samples is, more often than not, the prospective employee cannot show them because legally they are owned by the organization he/she works for and not available for public consumption.
I have a long development history using Macromedia Authorware, Director, Dreamweaver, and Flash (plus a whole ton of other tolls, many now defunct). When I was hired by my previous employer about 6 years ago, I had been "out of the game" for more than 5 years, and had ZERO experience with Articulate products (Storyline didn't exist when I exited the eLearning industry in 2008). Did that preclude me from picking up Storyline and applying my extensive background in eLearning design and development with this new tool? Hardly. In less than a week I was up-and-running with Storyline 2 creating engaging courses, finding bugs a few weeks later, and writing complex Javascript code to communicate with the LMS a week or two after that.
If a prospect can demonstrate, as Kevin Hayes said above, "why a developer did x and not y, their thought processes, what options they considered, and why they chose to code the way that they did," that means he/she can adapt to whatever tool you throw at him/her.
This discussion is closed. You can start a new discussion or contact Articulate Support.