Your run of the mill dev would be more like a studio musician hired to play a specific instrument in a specific genre.
Surely, he/she needs to be able to come up with lines/hooks/riffs/solos (when asked) and play part in the arrangement but composing from scratch and for multiple instruments would be rather out of scope.
While there's no direct audience for studio musicians (only the output matters) there are definitely performance expectations and the studio musicians are expected to be efficient.
Some employers ask for your personal github. That’s just like a portfolio of past work.
Wrong audition can be worse than no audition.
If you hire a piano player for large symphonic orchestra, or a famous band, and they are not already famous, you want to hear them play. Maybe one piece they chose themselves, but maybe also a piece everyone in the genre is expected to know.
And if they have to improvize a bit, that may tell you a lot, too:
https://www.youtube.com/watch?v=HtI3IMlGRMY
Sometime you meet programmer like this, than you can jam with on almost any topic. Those that can repeatedly improvize their way to "leetcode" solutions, while you observe their thinking process.
The "problem" with "leetcode" is that it has become too common and formalized. When people start to practice leetcode just to land the job, it suck the fun out of it, and it becomes harder to tell if the candidate is able to solve similar, but novel problems.
https://www.quora.com/How-does-seating-and-hiring-firing-in-...
My former teacher (he's been a concertmaster of a major city symphony for years, and is also well versed in the different ways in which one can ask "Did you actually practice?") wrote this explanation:
Think of it as management and labor. Management is Executive Director, Music Director, Principal Guest, staff, etc. Labor is orchestra musicians. Then you have the Board, which is there to raise money. Then you have the volunteers. Bear in mind, orchestras are non-profit, 501(c)(3).
So between management and musicians there is a CBA, or collective bargaining agreement. Just like the Major League Baseball has one between players and owners. In the CBA, you'll find chapters on hiring and firing. Each Symphony has its own CBA.
Usually, hiring is done by auditions behind a screen. If you're hired, your first year is the probationary period (sometimes two years). At the end of it, if management deems you fit for the job, you are granted tenure, just like at a university when you're applying for a teaching position. You don't need to re-audition, unless it is for a different title (from section to title chair, etc.), in which case you do. Firing, if it must come down to it, is also explained in the CBA.
The big symphonies are part of AFM (American Federation of Musicians). Then you have regional orchestras, community orchestras, etc. Some might be unionized, some not, but essentially it sort of works the same way.
Some concertmasters, like in England, are contracted outside the CBA, so they may be on a 3 or 4 yr contract, or more. But I think it the US, most are part of the CBA.Orchestra musicians indeed are routinely hired via a process that involves auditions, but my understanding is that applies only to those at the beginnings of their careers.
Popular/rock/jazz band formation process IMO is indeed similar to how start-ups are created (i.e. rather informal process generally based on networking, though audition jams also happen to fill a specific position). I fail to see how corporate staffing is similar.
Except that audition is to heavy on theory and minutia and the performer isn’t really showing (not given the chance) their better performance. There’s a variety of skills that leetcode style interviews flattens into a narrow category.
Engineering is overwhelmingly an applied science, not an art.
Sure, arts have elements of science and sciences have elements of arts. But, there's a reason we don't normally call scientists artists and vice-versa.
Birds are not fish, even though some birds swim and some fish fly. See?
This objection would be better addressed to the comment I was replying to, since I was just accepting the premise for the sake of argument.
Almost like fashion. At least in Europe, young people dress like a Stranger Things inspired mashup of 70s, 80s and 90s nowadays picking the best parts of those decades while leaving the 2000s and 2010s fashion in the dust.
Are you gonna do a certificate on microservices? And what's that gonna help when suddenly everyone starts building some shape of monoliths again because people keep running into the "no free lunch" issues?
On the other hand, open source culture is vastly different from proprietary culture.
So many times in proprietary culture I've churned out craptastic code to meet a deadline that didn't matter for a project whose customers were straw-persons. There's definitely some projects or features I've coded which I'm glad to hide from public view.
That said, artists can curate their portfolio, and unless they're presenting to a public forum, their turds won't have to see the light of day again.
As a software person I don't know enough about the scheme to comment on the quality of the article, but knowing Wikipedia I imagine it's on point.
edit For a broader context than just the UK, see https://en.wikipedia.org/wiki/Regulation_and_licensure_in_en...
Nothing like that exists in programming, not even languages or platforms. Which is why there exist multiple proprietary certifications instead focusing on specific details.
I agree.
After enough bridges fell down causing massive human fatalities, standards and accepted practices almost certainly "emerged."
Standards and accepted practices in software engineering will emerge, as if by magic, once enough "bridges fall down."
You are a diplomat sir; I'm merely a common street brawler.
That assertion is blatantly wrong.
Software engineers are like civil engineers and mechanical engineers because, ummm, yeah, of that word engineer. See?
I found the following on The Internets...
"California licenses Professional Engineers in the following engineering disciplines: Agricultural, Chemical, Civil, Control System, Electrical, Fire Protection, Industrial, Mechanical, Metallurgical, Nuclear, Petroleum, and Traffic."
It's almost certain that software engineers will be licensed... just like many other engineers. Why? Because certification helps to ensure people who call themselves "software engineers" meet certain standards.
Just like blind people normally aren't able to obtain a driver's license, people who can't solve FizzBuzz shouldn't receive a license to be software engineers.
You are always free to launch a revolution in the hopes of overthrowing your national government so that you can make the regulations and laws you would like.
In the meantime, when the jurisdiction you are in creates a requirement for certain software engineers to become certified (not "if" but "when"), even if the law were to apply to software engineers like you (the arrogant artistic types, you know what I mean, right?), I suppose you'll probably be grandfathered in because governments usually don't want to fight too hard to initiate new regulations and laws.
Grandfathering the "crusy old-timers" like you keeps you off their collective back because, at the end of the day, you probably don't really care about the issue generally. You probably simply don't want to be bothered to spend the time and energy to become certified.