4 ms·

However, just like like whiteboard coding is completely unrelated to real-world coding, this type of whiteboard design is also completely unrelated to the real-

by jjav 8y ago

However, just like like whiteboard coding is completely unrelated to real-world coding, this type of whiteboard design is also completely unrelated to the real-world whiteboard design people do in non-interview settings. How many times has a scenario like this happened to anyone: Your manager pulls you in with no warning into a conference room and asks you to architect on the whiteboard a new product completely unrelated to anything the company does or has done so far. And you get 45 minutes to get it correct or you're fired. Right.. never. That's the scenario interview whiteboarding is testing for and it has no real world relevance at all. In an actual job even the most impromptu whiteboarding sessions are related to product context already in your head. And most sessions are scheduled in advance so get to do research and prep work.

simplesleeper 8y ago
... 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
- Scarblac 8y ago
  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.
simplesleeper 8y ago
+ we don't set a hard time limit in the interviews. The whiteboarding piece is last and the candidate can spend as much time as he would like to. Often candidates have shown something we are happy with in just 5 minutes or so. The assumption you seem to be making is that anyone with a whiteboard is also an evil villain that wants to interrogate you violently you and pick on any mistakes that you might make. In reality, it is a higher level check to see if you can communicate at all.

by jjav 8y ago

simplesleeper 8y ago

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

Scarblac 8y ago
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.

simplesleeper 8y ago

+ we don't set a hard time limit in the interviews. The whiteboarding piece is last and the candidate can spend as much time as he would like to. Often candidates have shown something we are happy with in just 5 minutes or so. The assumption you seem to be making is that anyone with a whiteboard is also an evil villain that wants to interrogate you violently you and pick on any mistakes that you might make. In reality, it is a higher level check to see if you can communicate at all.