Chemistry has whiteboarding, but instead of writing algorithms or code, you're expected to be able to draw structures, reactions, and synthesis. It's also similar in that this is not necessarily a core part of most chemists everyday job, but something you study for to be able to interview or give presentations regarding your research.
It's been almost a decade since I worked in an organic synthesis lab, but when I did we stuck with chalk, instead of the more "modern" whiteboards. There's not much an accidental organic solvent spill will do to slate and sticks of calcium carbonate. Acrylic paint and dry erase markers, on the other hand...
I've never heard of whiteboarding a chemical reaction mechanism. Usually since most chemists at a comparable 'engineering level' to programmers are phds, a seminar is expected, and the candidate has something ready to go. It's an opportunity for the team to learn something new while assessing the critical thinking skills of the candidate during the q&a
I've witnessed it in the post-seminar lab visits. It bears little resemblance to the "whiteboard interview" from the developer world, but if you're visiting with a faculty member after you present your work, they may ask you to help them understand some piece of your work by drawing out the mechanism.
I'll disagree with the GP, though, on its applicability to "real-world" work. When I did chemistry, diagraming out a reaction mechanism and pondering it over with colleagues gathered in front of the chalkboard was a daily activity.
sure, but it's not like the employer tells the prospective employee to figure out a mechanism that is not related to the employee's former work (for example, a reaction recently discovered in the employer's lab, or a general reaction that "all good organic chemists should know" - like "show me how dansihevsky's diene works, and apply it to the synthesis of this molecule that you've never seen before") Hah damn. I don't want to give the chemists ideas.
I think some of the physical engineering disciplines are at least partially gate-kept and signal applicant value through membership to professional organizations and certifications (FE & PE exams, etc.)
Yes. In my recent Electrical Engineering interview, I didn't literally whiteboard but we did go over some simple problems that a person at my point in college should know.
I haven't experienced it, but I've only had a couple interviews/jobs as an electrical engineer before switching to software, where they happen almost every time.
I think it's a sign that universities are failing to be trusted as credentialing institutions. You should be able to verify a degree and conclude from that the person learned the material.
I guess this is why the professional engineering exams exist.
On top of those, you've got to keep learning when you're out of school. A university degree doesn't remotely guarantee that you'll be suitable for even an entry-level developer job right at graduation, and the correlation between time and skill gets looser as time goes on.
Completely just my opinion, but I think this is because most people (both employers and potential employees) are focusing on the more vocational aspects of programming, whereas university is more theory-based.
I know that I would not have gotten as much out of my degree if I hadn't had prior experience with programming prior to university. It's tough to appreciate why complexity analysis is important if you've never personally experienced a program running slow because you chose a poor algorithm.
And most employers aren't looking for that level of theoretical knowledge. They're looking for people who can quickly get up to speed with the development environment, who can break down a problem into smaller logical chunks, and who can translate those chunks into working code.
If neither employers nor students care about the theoretical knowledge, then what is the point of going for that degree? (IMO, the best course of action would be a few years of on-the-job training, then going to university once you have enough experience to appreciate the theoretical stuff. But that would be a huge culture clash with how things are currently done).
> If neither employers nor students care about the theoretical knowledge, then what is the point of going for that degree
Because you occasionally (but often enough to get a reputation for it) get to look like a god when you pull stunts letting them shut down 30% of the app server fleet by just adding one multi column index to the db...
It was probably 5-10 years into my career when realised I occasionally pulled out knowledge or techniques from 2nd year CS courses - which other people (even ones with way more university than me) didn't even understand when I explained what was going wrong and how we could fix it.
The old comp.lang.perl.misc gag saying "There are people with 10 years programming experience, and people with one years programming experience 10 times over" has a deep kernel of truth to it. 10 years of CRUD apps or Wordpress extentions or Django sites is unlikey to have prepared you to be Netflix's platform architect (to be fair though, neither has a mid to late 1980's vintage CS education - I don't get to show off my Pascal chops much professionally... ;-)
I could not disagree more strongly that university is theory-based. The three-class theory sequence I took was a mildly annoying sideshow. The meat of my university's CS program was in Networks and Distributed Systems, Database Systems, Operating Systems, Programming Languages, Functional Programming, Computer Security, Parallel Computing, Sensing and Perception, Machine Learning, Graphics, Scientific Visualization, etc.
Each had a lecture/exam component, but it was minor. The classes mostly centered on a set of programming projects, implementing foundational components in the topic area from a specification and a skeleton. (IRC server, TCP stack, IP router, Paxos, Byzantine Generals, Raft, b-trees, query parser, thread scheduler, syscalls, filesystem, interpreter, RSA, D-H key exchange, authenticated encrypted channel, concurrency primitives and then concurrent algorithms that use them, sensor fusion, geometric transformations, shading, texture mapping, ray tracing, etc). No one I know took all of these classes, but we all took most of them.
Proofs are theoretical knowledge. Hobbes, Locke, and Rousseau are theoretical knowledge. I did plenty of that too. This isn't theoretical knowledge, it's breadth. It's knowing what's involved in the systems adjacent to the code we write, inside the libraries we rely on. It's an understanding of what problems they're solving internally, why they might be acting up, and what to do about it. It's demystifying the rest of the computing environment, pulling back the curtain on abstractions. It's a whole bunch demonstrated ability to write complex programs for complex purposes subjected to rigorous test suites, under far more realistic conditions than any whiteboard interview.
A few years of on-the-job training will teach you what matters for your specific job, right now.
Though we didn't have such a class, a degree capstone might have been "given a CPU emulator, write a secure distributed database engine on your network stack in your SML interpreter on your operating system." It wouldn't have the performance optimizations that modern, widely-used components have accumulated over the last half-century, but it would work.
Unlike electrical engineers, not all software developers have degrees in CS. More than half of the best programmers I know don't have formal education in CS, so it would be a foolish hiring practice to rely on institutional credentials.
It has probably changed a little, and varies between schools and educational systems in different countries, but back in my days, some things I learned in university was pure anti-pattern.
Especially the "coder culture" which was obviously not part of the curriculum, but not negligible.
As there seems to be no end of the stream of jerks and increased misogyny, I doubt that it's gotten that much better though.
Edit: I also did a couple of courses that were eye-openers, including a introductory course based on the wizard book (SICP), but it probably was an eye-opener only to the few hobbyist with some previous experience.
There's more to judging a candidate than whether they learned the material. A mastery of CS material does not make a candidate perfect -- I'm still very interested in their problem solving skills and their ability to communicate. For all the problems with whiteboarding they're still the best way to test for those attributes.
It's not about the medium (whiteboard or similar) but the kind of questions/problems you ask. When you have a CRUD app developer opening and you're asking the candidate to come up with Knuth-Morris-Pratt efficient substring search algorithm on spot, whereas it took months of research for Knuth, Morris and Pratt...
I had whiteboarding with aeronatuical engineering. Had to draw out pressure velocity graphs along a turbofan engine and describe exactly what happened every step of the way and why it happened,
I've found the interview process for management consulting roles to be surprisingly similar to tech interviews.
Most interviews are presented as cases[1] where students/applicants have to analyze and propose a strategy to handle example client situations in ~60m.
I've found that the people who have the most success with the interviewing process are the ones who do the most mock and focus on optimizing their skill-set for the interviews, rather than for the actual positions (which is unfortunately similar to tech recruiting and algo/whiteboarding problems).
There is also a ton of online case prep[2] and training materials specifically for the interview process, akin to CareerCup/CTCI/HackerRank/etc.
Agreed on your comment (ex software dev, now management consultant)..
In MC, the delivery of the case is extremely important (how you structure the solution, how you speak, how you present yourself, etc.). Your point on people optimizing is spot on. Some students spend 10-20 hours a week practising before a McKinsey, Bain, BCG interview..
When I'm building cases and interviewing people, I try to structure it around a real life problem we have (e.g. a wood/fiber B2B company wanting to go B2C) which makes it less awkward than solving random algorithms.
However, I'm still not satisfied with the process, so wondering if people have ideas ?
I thought about giving a case to solve at home, but we're missing the part of how an applicant will react with a lot of pressure and in front of clients :/
Another relevant question - does "Sports/competitive <field>" (similar to Competitive Programming, i.e. Olympiad and code/hacker/lity/rank sites) thing exist at all? Such that the tasks are completely different to what one might expect to do on the job.
So e.g. if there is a "Competitive Bridge-Engineering" and the problems are completely different compared to bridge-engineers day job.
To continue this theme - in case you have an opening for bridge engineer - isn't it enough to discuss the previous 5 bridges the candidate has built and maybe also discuss the relevant details the current bridge project entails? Do such bridge-engineers also get irrelevant questions?
Not really related to job interviews, but West Point used to do a bridge engineering competition (maybe they still do) where you downloaded a software package and had to design a bridge that could withstand the highest load for the smallest cost. It was pretty accessible and kind of fun to mess around with. I never submitted any solutions, but I think the prize was a scholarship.
Professional orchestras have auditions, where you will perform a piece from the solo repertoire in front of the head of the section you are auditioning for, and a few other key staff (e.g. [1]). Some auditions will include orchestral parts, and you can buy books of famous solos for most instruments.
This repertoire has little in common with the kind of playing you will be paid for, other than as a pure display of technical ability (just like whiteboarding). For example, it is relatively poor as a gauge of the ability to play with others (accompanists follow you, not the other way around), or of your fitting in with the rest of your section.
Even on a technical level, performing a showy piece well in the few minutes of the audition does not mean you have the stamina to sustain this playing through four hours of Wagner.
[1] "The jury consists of 25 members of the orchestra: two of four concertmasters, the principals, the VPO chairman and managing director, five musicians of the relevant orchestra section, two staff council members from the Vienna State Opera Orchestra, and a representative of the Vienna State Opera’s management." - http://web.archive.org/web/20141203022823/http://slippedisc....
When auditioning, would the applicant know which pieces of music they will be required to perform beforehand? I am assuming that they do, which would make it very different from 'whiteboarding' from a software engineering interview.
In software engineering interviews, most of the time the interviewer will try to have prepared questions that the interviewee has NOT seen before. To make it more like an audition, the questions would need to be provided beforehand so that the interviewee could practice them.
It's not unusual for auditions to music schools to include either 'prima vista' - where you play from the sheet - or 'secunda vista' - where you get a few minutes of prep time.
I auditioned at a number of schools and prima vista was the only thing.
At a few of the auditions they would interrupt you if it appeared that you knew the piece and give you something else.
Honestly rather annoying. Even though I entered teaching, I did a lot of time in the pit and sight reading was never a skill that was needed. I can understand the need to weed out people with no/basic reading skills, but the idea that you need to be high-level fluency (particularly with oddly notated pieces!) is nonsense.
The worst part was that most students just gamed it. They would purposely ritard some part just to make it look like they weren't familiar with a piece they could play blindfolded. The net result is that the school I ended up selecting had a number of non-fluent readers that wasted everyone's time at some point because they were so slow!
Yes and no. Usually you can play what you like and project a certain impression (e.g. last movement of Sea Eagle [1] if wanting to show brilliance, a Mozart concerto [2] if wanting to play it safe). This is similar to showing your open source work or the solution of a take home assignment.
They will then ask you to sight read or play through famous repertoire (e.g. Tchaikovsky 5th Symphony 2nd movement horn solo [3]).
This is true whiteboarding in the sense that in theory, you might not have seen it before, but a professional (or a well prepared student) will know most of the things that can be asked, just as inverting a binary tree is one of many probable whiteboard problems an engineer who knows the game will pick up in Gayle McDowell's book or whatever.
And that's part of the game, one that older engineers don't need to play anymore, which is why they have problems at the US border, whereas older musicians must continue proving themselves as their work has a physical component that unfortunately must be demonstrated throughout their professional life.
I was just reading along here, and thinking that I’d much rather whiteboard for the rest of my life than ever take another orchestral audition, although each of these practices is only loosely related to what you will do on the job itself. I recently switched to software development from a professional career in classical and jazz music. Here’s the view from the performance hall: A top five orchestral audition (the ones that pay a sort of "living wage") comes around 2-4 times a year these days, if you’re very lucky. Typically, around 200 players of that instrument apply for this rare opportunity, and they come from all over the world- language is no barrier-we welcome international competition, and they will have no problem working here if not from the USA. Conversely, Americans can’t really audition in the EU, with rare exceptions for principals and special situations. There are no even slightly weak players anymore; everyone at the audition has a list of around 20- 30 complete symphonic pieces (we don’t get these from books- we buy the complete scores, and are prepared with pieces not on this list— we have to take the other 2 that year, remember.) rock solid memorized, along with at least two of the required/allowed concertos, a Bach Suite, and possibly some longer solos that come up in the orch. repertoire. Each piece is around 15-20 pages long, and represents tricky “algorithms" in performance technique. (think of it like this- one might be: “performing Dijkstra’s algorithm in the manner of a Shakespeare monologue, but in his accent, using his exact vocal inflections, breathing points, and slang ornaments to show you understand the linguistic trends of his time and heritage-but yelling it from a stage on demand through a fussy megaphone prone to glitch, while evoking the feeling of a whisper in an office”, and that would be one of 20) There is always sight reading at major orchestral auditions— I never took one that didn’t have it. Every single player at the audition is a graduate of Juilliard (or another one of the top 5 private conservatory programs in the US) and the age range is from about 20-50 because there are no jobs. (think the top 5 CS grads of Stanford, MIT, etc… dating back to the 90s) We have all known one another since childhood, because it takes that long to learn the required repertoire and technique. At the audition, zero-1 mistakes are allowed, because there is no other way to cut people from rounds- everyone is prepared to an Olympic level, and many are on beta-blockers or complex drug cocktails so they can handle the pressure of doing this several times a year. This has all been the case since the early 90s. Younger auditioners who don’t already play in major orchestras (yes, these players are competing too, so think- top professor in CS/AI at Stanford against you at the whiteboard) must put in 4-7 hours every day for 5-7 months before the audition (players know it will come up before it is announced and practice old lists- like for the MET Orchestra or others). In addition to this, a string player can not compete acoustically in a hall with colleagues who play Strads on an instrument that costs less than $30,000. (this has nothing to do with their technique) To think that someone could win one of these with just an undergrad degree is ludicrous. Orchestral rep is not really covered in this fashion in undergraduate work. In addition, the orchestra often selects no one at all from these highly qualified people, each of whom paid for a plane ticket and hotel room for three nights, not to mention a $100 set of strings a bow rehair, and perhaps a $200 instrument adjustment, and perhaps a “lesson” with a member of the section- also $120-200. Taking a single audition is very, very expensive. Auditions at lesser orchestras that do not pay a living wage often have much longer repertoire lists and demands (insecurity with their status/ignorance about what separates the wheat from the chaff), but one still has to fly/hotel there.
All t...
Thanks for sharing your experience. As a bad amateur musician, I've wondered about what it's actually like to pursue a career in music. It's sad that the odds seem to be highly stacked against people who want play classical and/or jazz music professionally.
I live in Pittsburgh where we have a wonderful orchestra. The musicians went on strike this season because their compensation was going to be significantly reduced (after already having suffered cuts recently). I wish I knew what to do to convey a love of this music to others, such that there could be more financial support for orchestras. It seems like the supply of talented musicians far exceeds the demand.
Also, since you're a fan of jazz, I was blessed to hear what would become Phil Wood's last concert. He played here in Pittsburgh while on oxygen -- he called it his "amplifier". Members of the Pittsburgh Symphony joined him as he played selections from "Charlie Parker with Strings". Besides the fact that every solo he played was perfect, he ended the show by telling the story of his musical career (and also, to the surprise of all gathered, announced his retirement from music). He passed away only a few weeks later.
I hope that we can find a way to not only maintain but to expand the richness of these musical genres for future generations. But with the challenges that you've described, I fear that many musicians will not be able to take part of it.
I've heard about the similarity between orchestral auditions and whiteboard interviews before. As someone who has prepared for whiteboarding interviews at a Big Five firm, I'm fascinated by the comparison. For a while I couldn't figure out how the similarity arose. Today it occurred to me that while in classical music the crisis was caused by the maxing out of demand, in software engineering perhaps it's the rapid growth in supply. By either mechanism you have a slots-to-candidates ratio crisis.
Yes, so do cooks at crappy dinners and bars. This audition is also often unpaid, sometimes called a "working interview". I've known people who have gone through this in the last few years for jobs making just above minimum wage.
There's a significant difference between musical performance and composition (improvisation combining the two). I would argue that composition is closer to programming than performance, but overall it's a bit apples to oranges. Music is a unique thing.
In front of that whiteboard you have to perform with all that that entails, but you also have to compose.
Not "whiteboarding" as such, but during my wife's last job search as a UX/UI designer, she was required to participate in a series of design exercises as a part of the evaluation process. Usually these were in the middle of a series of interviews; and typically those involved a few hours' work mocking up a series of high-level designs -- wireframes, interaction flows, etc. Unlike a whiteboarding exercise, they weren't made in a room with the interviewer.
When interviewing for a field tech (electrical TS&R work) position I've been put in front of unfamiliar equipment to troubleshoot.
Some companies will end up sending you for testing. Which normally have less than a 5%-10% pass rate.
Although the entire process is far more pragmatic than programmer interviews from what I've seen here. I was also able to expect far more replies back with results than programmers do here.
It kills me that "whiteboarding" has become shorthand for "bad developer interview technique". Meanwhile I'm over here whiteboarding my ass off as a communication tool for complex systems where its much more effective to walk someone through it as you draw it than to present pre-made slides. I love whiteboarding.
Whiteboarding or any way of writing notes/diagrams on paper or on any sharable medium is an extremly good communication tool, no one would say otherwise.
Said that, it is ALSO a very bad developer interview technique.
Think if anytime you use it to communicate with a team coworker you had to feel like "I must make this good in these next 20minutes or I am getting fired" (with the bonus of not knowing what the whiteboarding will be about) and this is how feels a potential candidate when doing these types of interviews
I think the OP is talking about coding on a whiteboard. Not solving problems at a higher level or conceptually which is perfectly fine. I love using a whiteboard too for collaborative spit-balling.
It's really sad to me that whiteboard is thought of as an interviewing tool. Opened this thread thinking "cool, maybe there are some brainstorming techniques I haven't heard of from other industries" and there's only stuff about interviewing techniques.
Maybe I can help. If I need to explore some ideas and there's no whiteboard handy I write on the windows instead. Gotta be prepared when inspiration hits!
56 comments
[ 0.17 ms ] story [ 166 ms ] threadI'll disagree with the GP, though, on its applicability to "real-world" work. When I did chemistry, diagraming out a reaction mechanism and pondering it over with colleagues gathered in front of the chalkboard was a daily activity.
But i /feel/ that larger scale (civil, etc) would not? I mean i kind of imagine civil, forestry, etc would be more portfolio driven?
I think it's a sign that universities are failing to be trusted as credentialing institutions. You should be able to verify a degree and conclude from that the person learned the material.
I guess this is why the professional engineering exams exist.
- you can get a degree from a lot of universities without learning what you should
- schooling is no substitute for work experience
- software hiring is still generally broken
I know that I would not have gotten as much out of my degree if I hadn't had prior experience with programming prior to university. It's tough to appreciate why complexity analysis is important if you've never personally experienced a program running slow because you chose a poor algorithm.
And most employers aren't looking for that level of theoretical knowledge. They're looking for people who can quickly get up to speed with the development environment, who can break down a problem into smaller logical chunks, and who can translate those chunks into working code.
If neither employers nor students care about the theoretical knowledge, then what is the point of going for that degree? (IMO, the best course of action would be a few years of on-the-job training, then going to university once you have enough experience to appreciate the theoretical stuff. But that would be a huge culture clash with how things are currently done).
Because you occasionally (but often enough to get a reputation for it) get to look like a god when you pull stunts letting them shut down 30% of the app server fleet by just adding one multi column index to the db...
It was probably 5-10 years into my career when realised I occasionally pulled out knowledge or techniques from 2nd year CS courses - which other people (even ones with way more university than me) didn't even understand when I explained what was going wrong and how we could fix it.
The old comp.lang.perl.misc gag saying "There are people with 10 years programming experience, and people with one years programming experience 10 times over" has a deep kernel of truth to it. 10 years of CRUD apps or Wordpress extentions or Django sites is unlikey to have prepared you to be Netflix's platform architect (to be fair though, neither has a mid to late 1980's vintage CS education - I don't get to show off my Pascal chops much professionally... ;-)
Each had a lecture/exam component, but it was minor. The classes mostly centered on a set of programming projects, implementing foundational components in the topic area from a specification and a skeleton. (IRC server, TCP stack, IP router, Paxos, Byzantine Generals, Raft, b-trees, query parser, thread scheduler, syscalls, filesystem, interpreter, RSA, D-H key exchange, authenticated encrypted channel, concurrency primitives and then concurrent algorithms that use them, sensor fusion, geometric transformations, shading, texture mapping, ray tracing, etc). No one I know took all of these classes, but we all took most of them.
Proofs are theoretical knowledge. Hobbes, Locke, and Rousseau are theoretical knowledge. I did plenty of that too. This isn't theoretical knowledge, it's breadth. It's knowing what's involved in the systems adjacent to the code we write, inside the libraries we rely on. It's an understanding of what problems they're solving internally, why they might be acting up, and what to do about it. It's demystifying the rest of the computing environment, pulling back the curtain on abstractions. It's a whole bunch demonstrated ability to write complex programs for complex purposes subjected to rigorous test suites, under far more realistic conditions than any whiteboard interview.
A few years of on-the-job training will teach you what matters for your specific job, right now.
Though we didn't have such a class, a degree capstone might have been "given a CPU emulator, write a secure distributed database engine on your network stack in your SML interpreter on your operating system." It wouldn't have the performance optimizations that modern, widely-used components have accumulated over the last half-century, but it would work.
[0] http://collegecatalog.uchicago.edu/thecollege/computerscienc...
oh well.
Especially the "coder culture" which was obviously not part of the curriculum, but not negligible.
As there seems to be no end of the stream of jerks and increased misogyny, I doubt that it's gotten that much better though.
Edit: I also did a couple of courses that were eye-openers, including a introductory course based on the wizard book (SICP), but it probably was an eye-opener only to the few hobbyist with some previous experience.
Most interviews are presented as cases[1] where students/applicants have to analyze and propose a strategy to handle example client situations in ~60m.
I've found that the people who have the most success with the interviewing process are the ones who do the most mock and focus on optimizing their skill-set for the interviews, rather than for the actual positions (which is unfortunately similar to tech recruiting and algo/whiteboarding problems).
There is also a ton of online case prep[2] and training materials specifically for the interview process, akin to CareerCup/CTCI/HackerRank/etc.
[1]https://en.wikipedia.org/wiki/Case_interview [2]http://www.consultingcase101.com/tag/free-sample-case/
In MC, the delivery of the case is extremely important (how you structure the solution, how you speak, how you present yourself, etc.). Your point on people optimizing is spot on. Some students spend 10-20 hours a week practising before a McKinsey, Bain, BCG interview..
When I'm building cases and interviewing people, I try to structure it around a real life problem we have (e.g. a wood/fiber B2B company wanting to go B2C) which makes it less awkward than solving random algorithms.
However, I'm still not satisfied with the process, so wondering if people have ideas ?
I thought about giving a case to solve at home, but we're missing the part of how an applicant will react with a lot of pressure and in front of clients :/
So e.g. if there is a "Competitive Bridge-Engineering" and the problems are completely different compared to bridge-engineers day job.
To continue this theme - in case you have an opening for bridge engineer - isn't it enough to discuss the previous 5 bridges the candidate has built and maybe also discuss the relevant details the current bridge project entails? Do such bridge-engineers also get irrelevant questions?
Not really related to job interviews, but West Point used to do a bridge engineering competition (maybe they still do) where you downloaded a software package and had to design a bridge that could withstand the highest load for the smallest cost. It was pretty accessible and kind of fun to mess around with. I never submitted any solutions, but I think the prize was a scholarship.
Professional orchestras have auditions, where you will perform a piece from the solo repertoire in front of the head of the section you are auditioning for, and a few other key staff (e.g. [1]). Some auditions will include orchestral parts, and you can buy books of famous solos for most instruments.
This repertoire has little in common with the kind of playing you will be paid for, other than as a pure display of technical ability (just like whiteboarding). For example, it is relatively poor as a gauge of the ability to play with others (accompanists follow you, not the other way around), or of your fitting in with the rest of your section.
Even on a technical level, performing a showy piece well in the few minutes of the audition does not mean you have the stamina to sustain this playing through four hours of Wagner.
[1] "The jury consists of 25 members of the orchestra: two of four concertmasters, the principals, the VPO chairman and managing director, five musicians of the relevant orchestra section, two staff council members from the Vienna State Opera Orchestra, and a representative of the Vienna State Opera’s management." - http://web.archive.org/web/20141203022823/http://slippedisc....
In software engineering interviews, most of the time the interviewer will try to have prepared questions that the interviewee has NOT seen before. To make it more like an audition, the questions would need to be provided beforehand so that the interviewee could practice them.
At a few of the auditions they would interrupt you if it appeared that you knew the piece and give you something else.
Honestly rather annoying. Even though I entered teaching, I did a lot of time in the pit and sight reading was never a skill that was needed. I can understand the need to weed out people with no/basic reading skills, but the idea that you need to be high-level fluency (particularly with oddly notated pieces!) is nonsense.
The worst part was that most students just gamed it. They would purposely ritard some part just to make it look like they weren't familiar with a piece they could play blindfolded. The net result is that the school I ended up selecting had a number of non-fluent readers that wasted everyone's time at some point because they were so slow!
/rant
They will then ask you to sight read or play through famous repertoire (e.g. Tchaikovsky 5th Symphony 2nd movement horn solo [3]).
This is true whiteboarding in the sense that in theory, you might not have seen it before, but a professional (or a well prepared student) will know most of the things that can be asked, just as inverting a binary tree is one of many probable whiteboard problems an engineer who knows the game will pick up in Gayle McDowell's book or whatever.
And that's part of the game, one that older engineers don't need to play anymore, which is why they have problems at the US border, whereas older musicians must continue proving themselves as their work has a physical component that unfortunately must be demonstrated throughout their professional life.
Edit: this captures the spirit of the thing quite well, spot the parallels with an engineering interview: https://www.youtube.com/watch?v=SdAnogOKR0I
[1] https://www.youtube.com/watch?v=Xu2kIVSP5yw&t=8m
[2] https://www.youtube.com/watch?v=XELNRsN3Jx8
[3] https://www.youtube.com/watch?v=eEbO80q66ak&t=1m12s
I live in Pittsburgh where we have a wonderful orchestra. The musicians went on strike this season because their compensation was going to be significantly reduced (after already having suffered cuts recently). I wish I knew what to do to convey a love of this music to others, such that there could be more financial support for orchestras. It seems like the supply of talented musicians far exceeds the demand.
Also, since you're a fan of jazz, I was blessed to hear what would become Phil Wood's last concert. He played here in Pittsburgh while on oxygen -- he called it his "amplifier". Members of the Pittsburgh Symphony joined him as he played selections from "Charlie Parker with Strings". Besides the fact that every solo he played was perfect, he ended the show by telling the story of his musical career (and also, to the surprise of all gathered, announced his retirement from music). He passed away only a few weeks later.
I hope that we can find a way to not only maintain but to expand the richness of these musical genres for future generations. But with the challenges that you've described, I fear that many musicians will not be able to take part of it.
In front of that whiteboard you have to perform with all that that entails, but you also have to compose.
Some companies will end up sending you for testing. Which normally have less than a 5%-10% pass rate.
Although the entire process is far more pragmatic than programmer interviews from what I've seen here. I was also able to expect far more replies back with results than programmers do here.
Said that, it is ALSO a very bad developer interview technique.
Think if anytime you use it to communicate with a team coworker you had to feel like "I must make this good in these next 20minutes or I am getting fired" (with the bonus of not knowing what the whiteboarding will be about) and this is how feels a potential candidate when doing these types of interviews
Maybe I can help. If I need to explore some ideas and there's no whiteboard handy I write on the windows instead. Gotta be prepared when inspiration hits!