6 ms·
I interview a lot of candidates and we do whiteboarding - to see how candidates can communicate architecture designs and decisions. The interviews have made me
by simplesleeper 8y ago
I interview a lot of candidates and we do whiteboarding - to see how candidates can communicate architecture designs and decisions.
The interviews have made me realise that countless candidates are unable to:
1. Give a high level overview of a product
2. Critique design choices and suggest improvements
3. Communicate well as to what the value of components are to the broader business.
Many of the developers can explain a particular piece of logic very well, others can't even do that. But in an enterprise scenario, we need excellent communicators.
- vitovito 8y agoBut communication on-the-fly, on-your-feet, in a high pressure environment, which is what a whiteboard test is, is not most communication. Most communication gets thought about, drafted, revised, critiqued, socialized, ahead of distribution. If your whiteboarding comes after hours or days of consideration and review, that sounds like a great way to vet good communicators. Otherwise, aren't you optimizing only for speed? If someone cracks a joke in the moment, they're a wit; but we only pay money to and call comedians those who worked on it for a while.
- nxc18 8y agoEver been in a tense meeting? Most (almost all) verbal communication comes with time pressure. Speak too long (ramble) and your message is lost and your coworkers are annoyed. Don't speak fast enough and now someone else is using all the air in the room.
- hopler 8y agoWe shouldn't setting up interviews that are biased toward to hiring people who will make the company even more toxic and counterproductive.
- simplesleeper 8y agoWhat makes you think they'll be toxic and counterproductive? If, as you seem to think, whiteboarding is a test for this, then everyone should have whiteboarding tests where the good whiteboarders don't get a job.
- JustSomeNobody 8y ago> Ever been in a tense meeting? This should not be what interviews are like.
- deathanatos 8y agoIf anything, my interviews are less tense and stressful than my meetings. On both sides of the table. (If anything, this is probably not what meetings should be like. I wish to god my coworkers would have real agendas for meetings — and a one-sentence subject does not count as an "agenda", and ideally, written material detailing any proposal that will be proposed, s.t. I can arrive at the meeting already understanding what it is that someone wants to do.)
- 01100011 8y agoYes. They're still nothing like an interview. It's a different kind of pressure.
- simplesleeper 8y agoOf course the candidate is under more pressure than they would be at work - that's why we don't expect them to create a Leonardo masterpiece in front of us and we give the candidate the benefit of the doubt. You would be surprised at how poor some of the candidates are at this. Candidates who are unable to draw a few squares on a board to describe the last thing they worked on, and candidates who have never questioned any of the work they were assigned or don't understand that there are often multiple options for a solution, each with pros and cons. If someone can't even draw a simple diagram on a board, I don't want to have to plan and come up with highly complex solutions over whole months with them.
- mlthoughts2018 8y agoI think an important point is that you are assuming someone’s design communication moves along a spectrum from good to bad as you increase time pressure or stress, and so you can accordingly adjust your expectations along a spectrum and still be well-calibrated to evaluate the meaning of the candidate’s performance. I propose it doesn’t work like that at all. Rather, if someone’s brain is loaded with time pressure or interview jitters, and they are not the type of person who thrives on stress, then it will be more like you have totally switched off the part of their brain that is good at communicating design thinking, and their performance in the interview will be entirely unrepresentative of what their performance would be in a regular day-to-day team meeting on the job. I think the same effect is even more severe with any type of coding / mathematics / puzzle solving questions done inside a short timed session or using things like Coderpad or HackerRank.
- simplesleeper 8y agoAnd how do you propose a removal of all stress? Shall we hire everyone and fire them if they turn out to be dreadful after a week? That would ensure EVERYONE is under pressure all the time...
- malvosenior 8y agoThis is what take home projects or allowing someone to present their own code help fix.
- jjav 8y agoHowever, 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 agoCan 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.