18 ms·
VP of Engineering at Eaze, previously CTO at Getable and engineer at Yammer. No, not at all. Whiteboard interviews test one thing well: How well does a can
by bradenb 8y ago
VP of Engineering at Eaze, previously CTO at Getable and engineer at Yammer.
No, not at all. Whiteboard interviews test one thing
well: How well does a candidate code on a whiteboard.
Engineers on my team never have to code on a whiteboard
(whiteboards are really bad at running code), why would I
make candidates do something that I don't ask the
engineers already on my team to do?
This comes close, but I think the real issue that most of these reasons aren't hitting on is that software development is typically done asynchronously. Whether it's a whiteboard or a computer connected to a projector or TV or a live peer coding session it doesn't matter: if done in the interview, it puts the candidate on the spot in a way that they rarely (if ever) will be on the job. Developers typically are able to take time by themselves or with trusted/known colleagues to solve a problem. There are very few opportunities to get over performance anxiety related to coding in front of others that we don't know.
- pavel_lishin 8y agoMinor kvetch: quoting the way you did it makes long lines very difficult to read. I usually quote like this: > I am a quote This makes the quotation doubly-distinct, and still readable on mobile devices. === To the actual point I wanted to make: plenty of engineers at companies code on a whiteboard. They schedule a meeting, grab a room, and talk things out, while making notes, diagrams and sometimes even actually writing out some code on a whiteboard. I hope nobody asks people to write compilable code on a whiteboard, but asking a person to talk through a problem and jot down some pseudocode doesn't seem like an awful thing to me. Communication is a pretty critical part of our job.
- pmiller2 8y ago“Jotting down some code on a whiteboard” with a colleague is a much lower stress scenario than deriving and writing down, under a time limit, some DP algorithm you might not have used since college, and proving its correctness and run time to some stranger who may be barely out of college themselves.
- recursive 8y agoInterviews are necessarily more stressful than typical work. That's not just a property of whiteboard coding.
- pmiller2 8y agoMore stressful, sure. For many people, whiteboard coding is disproportionately more stressful than typical work, and that’s the problem.
- lfowles 8y agoOne particular expectation when whiteboard coding for an interview is that there is little/no downtime, you must be making progress or talking about your thoughts. Incidentally, 50% of my thought process then becomes "How do I talk about what I'm thinking about? Oh no, I'm only thinking about talking about what I'm thinking about..."
- ubernostrum 8y agoI'm working on a large-ish project right now, and into one of the more tricky bits literally today. And you know what? I take breaks. I go read something on the internet or post a comment, or I go for a walk, or I go do one of the smaller housekeeping tickets I keep in my queue to give my brain a rest from continually focusing on the hard parts of the problem. Can't do that in a whiteboard session.
- hackits 8y agoMost of the time their technology stack with be vastly different than anything else you've worked with. There will be other people you will need to discuss and coordinate with. Articulating your thoughts and expressing yourself clearly and concisely is more important. Vast majority of the technical problems have been solved and its delivery a solution to a business problem that is the most important aspect.
- 8y ago
- ubernostrum 8y ago"Whiteboard interview" typically does not mean "sketch a general design of a system", or the other things whiteboards get actually used for on the job. It means "here's an algorithm challenge, solve it by writing the code on the whiteboard, and we'll flunk you if you make any mistakes". Not always a whiteboard, either; one of the best engineers I ever knew flunked a Google interview because of a situation where he had to write a bash script and read it over the phone to the interviewer, who apparently didn't transcribe it correctly on the other end. But "they only hire the best", you know, and their practices are rock-solid and proven.
- lfowles 8y agoOof, I've had that experience during a technical phone screen with a different "hires only the best" company. I was asked to write (over the phone) a trivial statistical algorithm and started to describe the algorithm: "Function F returns a double and has two parameters, pointer to the start of the double array P and integer N for length of array." Apparently on the other end of the line was a human compiler that kept rejecting my input and preferred "double F open parens double star P comma int n close parens"!
- scarejunba 8y agoThis is hilarious! Such a strong indicator that you, as a candidate, should reject the employer.
- lfowles 8y agoYes, it was the final straw and led to me rejecting that industry as a whole :)
- pavel_lishin 8y agoWhat are you doing now?
- 8y ago
- privacypoller 8y agoI don't doubt lots of companies do this, but I skeptical about the coding on a whiteboard. They talk in person, sketch out diagrams, highlight important aspects - why? because these things are all easier on a fluid analog medium like a whiteboard or piece of paper. Actual Code? Not a chance. Portability, Durability, Efficiency - It's the worst of all worlds.
- BinaryIdiot 8y agoI've worked at quite a lot of companies. Many of us will, occasionally, grab a room / whiteboard to go over something but 99% of the time it's a sort of flow or UX type thing. I've _never_ seen someone, or have asked to participate in, some sort of whiteboard coding thing. Even with pseudo code. That just doesn't seem helpful to me, at all.
- tluyben2 8y agoAgreed; when there is code talking, we share screen on a projector/flatscreen and do it that way. How is writing code on a whiteboard good for anyone? Cumbersome and not reusable.
- bradenb 8y agoThank you for the quote pointed. I will remember that for next time! As to you’re point, I think others have covered it well, but I will add my agreement that communicating in an environment where you are comfortable and familiar with the topics ahead of time and won’t have your career prospects put in the line is much easier. Some people like myself simply can’t prepare for an infinite number of possible whiteboard scenarios and look competent.
- teachrdan 8y agoThere's some logic to that. It's the one of the same reasons we have high stakes exams in school: to show what the individual can do under pressure. In an interview setting you can't simulate what it's like to be at the end of a high-intensity sprint, but you can ask the candidate to answer a tough question on a whiteboard and (ideally) get a notion of how they work when the going gets tough.
- jriot 8y agoAs a former air traffic controller and now data scientist, nothing in this career field is ever done under any real pressure.
- dylanrw 8y agoBut what about that one time on Swordfish!? /s
- java-man 8y agotremendous respect to air traffic controllers. i cannot imagine the level of professionalism and responsibility these people must have! no amount of monetary compensation is enough, in my opinion.
- jriot 8y agoThanks. While everything you said is true, its also a hell of rush. Hardest part of changing careers ... no rush with a daily dose of dopamine.
- romaniv 8y agoThe pressure of a whiteboard interview has nothing in common with the pressure of a short deadline. It's like testing people for Tour de France by putting them on a unicycle.
- ztjio 8y agoNow there's a prologue I'd actually watch.
- toast0 8y agoI guess it depends on the job, but for outage response, being able to understand a problem, and update or write new code in a reasonable amount of time is kind of a useful skill. Discussing it on a board with others can be useful, if the code isn't complex. Of course, that also depends on the environment; if you're in an environment can't actually push any code, even emergency fixes, quickly, then it doesn't help a lot.
- romaniv 8y agoDo you design clever search algorithms during outages?
- toast0 8y agoIf the existing search algorithm is the cause of the outage, maybe. If I a clever search algorithm will help me filter the data so I can reduce the scope of the outage, yes.
- throwawayboye 8y agoAre there no existing tools to search through data?
- toast0 8y agoEverything is already implemented, let's close the patent office.
- remoteorbust 8y ago> Whiteboard interviews test one thing well: How well does a candidate code on a whiteboard. What if you consider part of someone's job to be communicating concepts to people, possibly with the help of visual aids and diagrams? I hate this concept that if it's not typing code into an editor then it's not "real work". I absolutely communicate with my coworkers using a whiteboard and pseudocode. I reject the idea that being put on the spot is necessarily "artificial". To the contrary, I think that the number of engineering jobs where you can assume you'll never be put on the spot or have to communicate complex ideas verbally or visually is relatively low. Now if this particular skill isn't interesting to an employer and they'd rather spend the time talking about some other candidate capability, that's a whole different story.
- java-man 8y agoeven then, this is not what's being tested with the whiteboard. thinking and presenting are two separate skills, and, in my opinion, can rarely be executed at the same time.
- jdc 8y agoThe point is that the interview style in question overemphasizes on-the-spot responses. How is prowess in a game of "gotcha" an important indicator of engineering skill?
- techwraith 8y agoVPE at Eaze here (the original author of the quote above) - You're 100% correct. We give our candidates the choice between working through a problem at the office (on the spot as you say) or doing a take home project asynchronously. Not everyone has the time to do homework, but not everyone wants to do an in person coding interview either. We try to stay flexible.
- mattnewton 8y agoHow do you compare the resulting apples & oranges? I can do a lot more at home (especially if I cheat on time, which everyone who really wants your job and can afford to do will do)
- techwraith 8y agoWe're less concerned with the resulting code than we are about your ability to explain the code that you wrote and your ability to prove to us that you have good judgement when making technical decisions. Also, we're growing fast enough that we're rarely comparing candidates. If we can hire both the apple and the orange (assuming both candidates are evaluated to be good for the role), we will.
- loxias 8y agoI'm actively looking/interviewing and really like the "cut of your jib". (both your answers here, plenty of aspects of Eaze as a company, the prospect of moving back to SF...) For both the sr backend and devops positions, how important to the roles is familiarity/experience with your technical stack? I might have some of the skill set/experience you're looking for -- sr backend engineer, sr systems engineer, devops are all positions I've held -- but honestly I don't know JS, .NET, or Chef. Bluntly, I don't want to waste your (or my) time. ;) <tiny>Also, I wish HN supported private replies</>
- techwraith 8y agoWe care less about your particular technical skills than we do about your generalized engineering skills. Specific stacks are easy to teach; fundamentals, emotional intelligence, and social skills are harder to teach. In fact, if someone is too into their stack, we see that as a bad sign. So I'd be super excited if you decided to apply :)
- mrep 8y agoReally? I have multiple in person discussions per week about how we are going to tackle some problem where everyone chips in and those are just the weekly problems we are working towards. There are also the much larger design docs and while some of the feedback on those happens asynchronously, a lot also happens in real time during meeting reviews. Oh, and both of those problems are decently well covered by your standard interviews (the former generally being data structure/algorithm design, the latter generally being system design).
- sieabahlpark 8y agoWhen's the next 50% off sale?
- ndesaulniers 8y agoA team I was on at Google (XLA, the compiler for TPUs) used whiteboards almost daily to express algorithms to each other. Definitely helpful for us, but I can see that just being a single team's dynamic. No comment on it being an effective interview process.
- deleted 8y ago[deleted]
- nitely 8y agoI've aced every whiteboarding interview when the problem was the same or similar to some problem I solved before, and I failed pretty much every interview when the problem was new to me (except when the problem was trivial, ala fizzbuzz). I think that proves how whiteboarding just tests whiteboarding skills and nothing else.
- fatnoah 8y agoIt's funny, when I saw the title I immediately thought "Hell yeah, whiteboard interviews are absolutely necessary". As I read the article, I realized it meant actually making people code on whiteboards, which is absurd. I've always used whiteboards for high level design and architecture questions, and there mostly to aid the candidate in organizing their thoughts. If I want to see someone's code, I'll ask them to provide a code sample.