... You are making a load of assumptions that are wrong.
We ask the candidate to describe a system they have recently built. Therefore they should have product context, they are not being tested on inventing whatsoever (unless they are actually doing an impressive con, in which case, they'll have to be extra skillfull). As mentioned below, we give candidates the benefit of the doubt, but quite a lot of candidates are unable to give even a simple explanation of what they've worked on.
As for the amount of pressure - all of the pressure is circumstantial. We try as hard as possible to put candidates at ease. Obviously it's not entirely possible, but we try our best. Secondly, scenarios like that happen all the time. Maybe I won't get fired, but if there is a pressing issue, for example, I often need to draw diagrams to explain what is happening to a part of a distributed system. It is impossible to do without diagrams. And communicating these issues clearly and concisely often leads to quicker resolution times and happier clients/stakeholders
Can I just use words to describe it though? Or pseudocode? Short lists of issues that need to be considered in the design, with various options and their pros and cons, in words?
It's the expectation of drawing pictures on a whiteboard that's so strange to me, that's completely alien to the way I think about software. I think in text.
We ask the candidate to describe a system they have recently built. Therefore they should have product context, they are not being tested on inventing whatsoever (unless they are actually doing an impressive con, in which case, they'll have to be extra skillfull). As mentioned below, we give candidates the benefit of the doubt, but quite a lot of candidates are unable to give even a simple explanation of what they've worked on.
As for the amount of pressure - all of the pressure is circumstantial. We try as hard as possible to put candidates at ease. Obviously it's not entirely possible, but we try our best. Secondly, scenarios like that happen all the time. Maybe I won't get fired, but if there is a pressing issue, for example, I often need to draw diagrams to explain what is happening to a part of a distributed system. It is impossible to do without diagrams. And communicating these issues clearly and concisely often leads to quicker resolution times and happier clients/stakeholders