4 ms·
Well doing it on a white board in the same room as the interviewer allows you to see how some one approaches a problem - which is more important than the quonda
by mjwalshe 15y ago
Well doing it on a white board in the same room as the interviewer allows you to see how some one approaches a problem - which is more important than the quondam task of coding.
- lrobb 15y ago"allows you to see how some one approaches a problem" Although the whiteboard is good for some purposes, the author specifically mentions "brainfuck" coding questions. Having them do those on the whiteboard really only tests how the think on their feet in high pressure situations... Something not really required of 99% of coders.
- nirvdrum 15y agoWhile that may be true, if you're really top talent as he's suggesting he is, you probably aren't part of that 99% either. And that's the problem I have with the article in general. It has a very prima donna attitude to it. As in: "I'm so good you need to soften the interview for me and the fact I'm demanding that is proof enough that I'm that good."
- lrobb 15y agoThat's not what I meant. White-boarding in a high pressure situation is simply a different "skill"... I think it's fair to say that most coders are "internal" thinkers / introverts, that do their best work when they have a chance to quietly think about a problem. On the whiteboard, you're asking them to do the exact opposite. Eliminating the "brainfuck" white-board questions doesn't mean you need to soften the interview. You can actually give a more substantial take-home problem to your final round of candidates.
- nirvdrum 15y agoWell, brainfuck questions in general aren't all that useful, whether you do them on the board or take it home. But if you can't do basic stuff on a whiteboard or a sheet of paper, that's a red flag to me. But, I'm biased. I would never do a take home interview shrug
- lrobb 15y agoThe original post, and my comment, mention nothing about "basic stuff" on the whiteboard.
- mjwalshe 15y agoYes anyone who has aspirations to be a professional in this industry really should be happy to take a problem and come up with some outline solutions/approaches on the fly. Though as my first job was at a RnD Organisation this was expected from everyone from the shop guys to the Boss (the then president of the mechanicals) I might have a higher expectaion than most :-)
- jasonlotito 15y agoExcept, most people asking white board questions are asking for code. > allows you to see how some one approaches a problem I've never jumped to a whiteboard. Rather, I've researched the problem. If they really wanted to see how you'd approach a problem, they'd give you the problem before the interview, and then when you come in, ask you to explain it, allowing you to use the whiteboard.
- phamilton 15y ago> I've never jumped to a whiteboard. I've also never had to reverse a BST in place outside of an interview setting. I personally like technical questions in interviews. I've had some good experiences with them, but that may be because I have always been a good "test-taker". I feel like I understand what tests (and interviewers) are looking for and can tailor my response accordingly. For an interview, I've learned that the question isn't "come up with the best solution". The question is really "demonstrate how you approach this problem". I've learned to vocally explain that I'm starting with a naive approach. Then I explain how I'm considering the constraints for optimization. I state out loud any patterns or similarities between the optimizations I am trying to make and ones I've made in the past. (ie, "To make this O(logn), we need to find ways to eliminate half the data set each iteration. Is this similar to a BST at all?"). I pursue paths I know might not be correct, and backtrack when I see the fault in the idea. The key is to narrate for the interviewer. Maybe I've had good interviewers, but 7 of the last 8 interviews I've had resulted in job or internship offers and I felt the interviewer was able to get an accurate picture of my abilities.
- kls 15y agoRight I agree, asking someone to drag you along through there thought process while they are trying to solve problem is not natural. It's akin to saying, hey give a public speech while you are writing an algorithm. How many times do we here people say hold on I am concentrating. Most people opt to solve a problem, refine it, and then say OK here is what I did, now that I have had time to think about it and write it down.
- mjwalshe 15y agoDifferent strokes for different people I often sketch out my ideas and possible solutions on a white board or on some sheets of A1 flipchart paper laid out on a spare desk near me.
- deleted 15y ago[deleted]
- kls 15y agoI disagree, a fair majority of developers fall within the INTP or INTJ classification of Myers-briggs. both of which like to analyze a situation before they would consider answering. Specifically, the INTJ classification is filtered heavily at the whiteboard because of their Judging trait. INTJ's know what they don't know, and if they don't they are going to stop to find a resource that can provide that portion of the answer. Due to the INT part of their profile, they are not going to look at anyone in that room as a potential authority for that answer and therefore they will feel research is needed. This can cause a situation in which an INTJ can basically lock-up. They know they don't know a portion of the answer, and they have none of the natural authorities to look to, to resolve the answer so that they can move on. This can happen on something as simple as forgetting an API method or the modulus operator. No matter how much interviewers say they are just looking for solutioning, they are not being honest with themselves because when they see code that is not their style or they see someone make stupid mistakes (which we all do) on the whiteboard, it embeds in the mind. It such an overpowering signal that it outweighs all other evidence. An INT already knows this and would therefore prefer to present finished code, not how you get there, which finished code is all that really matters, you can walk them through how they arrived at the finished code, and they will have a far more competent answer because they are not trying to code and drag people along with them at the same time. Even if a developer makes 20 mistakes, and uses the compiler/debugger to catch them, then fixes them, if the code that they are going to check in is always clean, is his process bad? on the whiteboard it is, but for me personally if said hypothetical coder never checked in a mistake, he would be my top pick. There are just too many failure points for me to recommend the whiteboard. I believe that they provide no use in an interview and I believe they hurt companies more that employees. Organizations that utilize the whiteboard are doing themselves a disservice because they are setting introverted people up in a situation where a portion of them are naturally going to fail, in a situation that send such a strong false signal that all other evidence is negated. Then some of them are complaining that they cannot find talent. If a company is whiteboarding then they are filtering INTJ's out no two ways about it. As such, they are filtering out a lot of people that combine technical skills with creativity.