> Personally, I prefer the “audition” being a problem/task for the developer to be sent out, allowing the candidate to do the test in the comfort of their own home, with their editor or IDE of choice, using proper build- and version control tools[...]
If your test requires the developer to use some version control tools, this probably means that it'll take an extended period of time.
At that point, you should pay her or him for that "test".
The problem is that the "audition" is valuable work product that can be redeployed and has value to the employer whereas if a theatric audition is recorded and ever used in the final movie or anywhere, then that actor will get paid, period.
Re-posting a response to that article:
Auditioning actors are a terrible analogy. You seriously want to compare your hiring protocol to the film industry which has a surplus of good looking qualified actors ready to work for sex? You do understand that there is a shortage of decent programmers in technology. So what your process ends up doing is alienating the best ones and attracting the mediocre/inexperienced/desperate ones who'll do anything for a job. Great. Exactly the kind of screening tool I want (I'm the product officer and hiring lead for my startup).
Imagine how ridiculous it sounds to "audition" a marketing executive: "Ok, so we have a problem with expansion in South America. This is what we've been doing in the last 18 months. Please read this 5 page summary and spend the next 48 hours to come up with your best answer, prepared on our cloud hosted marketing platform."
I understand your reasoning (as an employer, can empathize), but this whole auditioning process as you've described is completely stacked against the interests of the developer. Auditioning is fine if you can address the following issues:
Protect the candidates: be their advocate and share their problem solving tasks (open source their solution? make it available to all employer members on your internal Git?) so that other employers can benefit from the "audition". Just like a recorded audition can be shared with prospective movie producers and directors to demonstrate an actor's range, the same should be allowed in your audition. This solves the biggest fear of developers: you are not exploiting them; by sharing the "auditions" that a candidate has completed over the course of five interviews, the candidate now has a strong portfolio that future employers can review without having to ask much more of the candidate. You have an "us versus them" mentality; employers do not want to have a confrontational relationship from day one where I have to justify and convince the candidate (who has three other offers on the table, because he's awesome) to go through this time consuming process.
Remember, your value as a tool to employers (like me) comes about because there are thousands of programmers signed up to "audition" their skills on your platform; so the golden egg is not me (the employer) but the programmers themselves. Focus on the programmers, they will love that you help solve their problem, and employers will see the value because candidates love flowing through you. LinkedIn is precious because there are millions of active candidates posting their information; use this analogy, not the audition/film industry.
> Programmer auditions -- Actors do it, so why shouldn't developers?
Programmer auditions that are analogous to what actors do would involve doing actual development work on the actual code based used by the hiring firm (potentially working with one or more other developers, who may either be on staff, hired specifically for the audition process, or also auditioning), the same way that actor auditions involve performing actual scenes from the actual work for which the actor is auditioning.
But, of course, under terms which prevent the hiring firm from making any use of the work product without hiring the auditioning programmer.
But auditions are a fairly expensive tool for evaluating applicants and is generally used for performers when the act of performance is itself the output and is highly specific to the particular work and for which there is no real substitute screening tool (some key points of which -- particularly the high specificity to the particular work and the absence of a suitable substitute -- may well be true of developers, making real auditions as I discuss above potentially useful for them, if quite expensive), but this article isn't about auditions at all, its about selling a platform for automating standard programming interview exercises, but its using the strained metaphor of "auditons" as an attention getter (but nothing in the article even addresses any substance to the comparison to auditions, fairly immediately switching to discussing what this is really about -- making interviewees take a test rather than perform an audition -- and its clear that "developer auditions" is just a a new weird brand name for programming tests with automated scoring that Code Qualified is trying to sell as a service.
6 comments
[ 3.1 ms ] story [ 36.6 ms ] threadIf your test requires the developer to use some version control tools, this probably means that it'll take an extended period of time. At that point, you should pay her or him for that "test".
Imagine how ridiculous it sounds to "audition" a marketing executive: "Ok, so we have a problem with expansion in South America. This is what we've been doing in the last 18 months. Please read this 5 page summary and spend the next 48 hours to come up with your best answer, prepared on our cloud hosted marketing platform."
I understand your reasoning (as an employer, can empathize), but this whole auditioning process as you've described is completely stacked against the interests of the developer. Auditioning is fine if you can address the following issues:
Protect the candidates: be their advocate and share their problem solving tasks (open source their solution? make it available to all employer members on your internal Git?) so that other employers can benefit from the "audition". Just like a recorded audition can be shared with prospective movie producers and directors to demonstrate an actor's range, the same should be allowed in your audition. This solves the biggest fear of developers: you are not exploiting them; by sharing the "auditions" that a candidate has completed over the course of five interviews, the candidate now has a strong portfolio that future employers can review without having to ask much more of the candidate. You have an "us versus them" mentality; employers do not want to have a confrontational relationship from day one where I have to justify and convince the candidate (who has three other offers on the table, because he's awesome) to go through this time consuming process.
Remember, your value as a tool to employers (like me) comes about because there are thousands of programmers signed up to "audition" their skills on your platform; so the golden egg is not me (the employer) but the programmers themselves. Focus on the programmers, they will love that you help solve their problem, and employers will see the value because candidates love flowing through you. LinkedIn is precious because there are millions of active candidates posting their information; use this analogy, not the audition/film industry.
Programmer auditions that are analogous to what actors do would involve doing actual development work on the actual code based used by the hiring firm (potentially working with one or more other developers, who may either be on staff, hired specifically for the audition process, or also auditioning), the same way that actor auditions involve performing actual scenes from the actual work for which the actor is auditioning.
But, of course, under terms which prevent the hiring firm from making any use of the work product without hiring the auditioning programmer.
But auditions are a fairly expensive tool for evaluating applicants and is generally used for performers when the act of performance is itself the output and is highly specific to the particular work and for which there is no real substitute screening tool (some key points of which -- particularly the high specificity to the particular work and the absence of a suitable substitute -- may well be true of developers, making real auditions as I discuss above potentially useful for them, if quite expensive), but this article isn't about auditions at all, its about selling a platform for automating standard programming interview exercises, but its using the strained metaphor of "auditons" as an attention getter (but nothing in the article even addresses any substance to the comparison to auditions, fairly immediately switching to discussing what this is really about -- making interviewees take a test rather than perform an audition -- and its clear that "developer auditions" is just a a new weird brand name for programming tests with automated scoring that Code Qualified is trying to sell as a service.