Ask HN: Do other fields of engineering have an equivalent to whiteboarding?

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.

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

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 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 that said, orchestra auditions didn’t used to be like this. They started out in the 40s and 50s resembling more of a whiteboard kind of a thing. Just saying— we need to think about where this might be going one day...

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.

> 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.

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.

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.

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...

Being able to work under pressure is also a skill.

Hey, cool story! May I ask how you got into MC? How old where you? How long have you been a Software Dev? Did you do an MBA?