Am I the only one around here who doesn’t mind whiteboard interviews? Ultimately you’re just discussing a technical topic with someone and drawing a few boxes and arrows is really useful.
The last time I did a whiteboard interview I didn’t 100% nail the CS puzzler question and, given the offer I got, the interviewer really was mostly interested in my thought process and not my ability to hand indent python code on a whiteboard. I’ve had this experience more than once. Written communication is a skill and being able to communicate your thought process to someone else isn’t as artificial an environment as some make it out to be.
I’m a broken record about how bad whiteboard interviews are, but I think I generally do pretty well on them. After ~15 years of consulting and product management, I’m pretty comfortable in a neutral-to-hostile room. I think I can talk my way through most situations.
But that’s one of the things that scares me about whiteboard interviews. Not that they’re insurmountable hurdles for my own career, but that they’re too easy, and that I get undue positive evaluations just from the ability to remain confident-sounding during them, and, more importantly, by being able to redirect questions and reframe interviews.
I’ve worked with too many people who interviewed well but were almost total zeroes when it came to delivery too put any faith in ad-hoc interview processes.
I came here to say this. I’d much rather go to a whiteboard interview. I don’t do riddles or competitive programming, but I’d appreciate being tested a little more than “tells us about your last project”.
Seeing DHH’s tweet makes me cringe. Sure it works for him, and it works for a lot of people, but for me it is important to know some CS basics. I wouldn’t mind if he said quicksort, or something a little more complicated like that … but bragging that you can’t write the simplest algorithm there is, how is that a good thing?
However, I do agree that take home excercises are good, and I enjoy those too. But they’re not as representative if you don’t ask the candidate to do easy something live.
I think it’s not necessarily a question about substance but more about style. Not everyone’s coding style is amenable to standing in front of people and hand-coding an algorithm while people are sitting there judging every character you write. You’re doing this while you’re expected to talk through what you’re writing on the board. That doesn’t come naturally to some people – when you’re sitting at a computer implementing an algorithm, you’re not talking about it out loud.
Another aspect of this is that a candidate can do better by studying for an interview. That’s a sign of a broken candidate vetting process. A candidate with years of experience and a top performer at their previous job could possibly be rejected based on questions that they may not have seen in years.
CS basics are important but some of that knowledge fades over time. I couldn’t give you a good definition of polymorphism without looking it up but I know what it means. I think the issue comes down to treating every candidate as though they were fresh out of school and the further they are from that, the more likely they are to fail those “basic” CS questions in this type of interview environment.
DHH has written some valuable software, but the world is bigger than rails. So when I hear that in the early days of rails things leaked memory so bad that app servers had to be restarted every few minutes I think that’s bad. I realize for the type of work his websites were used for that wasn’t a critical defect. In most software I write that would be a critical defect.
There was a popular (now depublished) blog post by Zed Shaw called “Rails is a ghetto” where he was railing against a lot of things he perceived as wrong in the Rails community. One of them was that he wrote a critical piece of software, but no one would pay him for that. It was one of the first specialized HTTP adapters in Ruby, called Mongrel. Along with that, he wrote a critical gem that fixed MRIs heavy threading problem back then.
In that post, he mentioned in passing that DHH told him that their initial web stack was so bad that they had to restart it every ~100 requests because it leaked memory and Mongrel improved things a lot.
Now, having programmed Ruby since version 1.6, I think this is probably true. Ruby back then was a fringe language built by a few people that were good language designers, but not necessarily runtime implementors. Also, the runtime was built for scripting workloads, so threading, servers and similar were a not so well tested case. With it becoming popular, thing improved massively and from 1.8.7 and later, I’d call MRI a runtime on par with Python and others. 1.9 finally made it somewhat modern.
But as /u/shanemhansen sais: that wasn’t too critical these kinds of applications. For example, it was standard that PHP websites would follow a CGI-like “one process per connection”-approach to make sure there’s no memory problems due to leaks. Restarting a set of webservers every nth request is also acceptable in such an environment, even if there is always another around.
I think the core of DHH’s argument is rather that he’d like people that understand those subleties and possibilities and you can’t really test that on a whiteboard.
I believe, if I could point at one thing it’s the following statement on 2007-01-20 to me by David H. creator of Rails:
(15:11:12) DHH: before fastthread we had ~400 restarts/day
(15:11:22) DHH: now we have perhaps 10
(15:11:29) Zed S.: oh nice
(15:11:33) Zed S.: and that’s still fastcgi right?
Notice how it took me a few seconds to reply. This one single statement basically means that we all got duped. The main Rails application that DHH created required restarting ~400 times/day. That’s a production application that can’t stay up for more than 4 minutes on average.
In broad strokes, there are three problems with whiteboard interviews.
First: an in-person interview with a stranger at someone’s office is an inherently hostile experience. Different people react differently to that hostile experience. Some people react terribly to it. Two of the very best people I’ve ever hired were physically impaired by stress during their in-person interviews. In one of those cases I had to override the results of the interview process to get the person hired. Since no part of a typical dev job involves working under that kind of stress, it is counterproductive to filter based on it.
Second, and equally importantly: some people do really well in these kinds of interviews. But their performance in the interview is not necessarily correlated with their ability to deliver. Making a bad hire is extremely expensive. A process that selects based on something other than delivery ability is either implicitly or explicitly game-able. I think there’s a whole class of people in this industry who sort of fail “diagonally”, mostly horizontally from company to company but eventually upwards as well as their resumes grow, because it’s virtually impossible for most companies to fire someone in under a year. This happens in part because our screening processes, which are dominated by whiteboard interviews, don’t detect people like this.
Finally, even though I’m not personally that ill-at-ease in a conference room with a whiteboard, I sure as shit don’t code as well on a whiteboard as I do on my laptop in emacs with nobody looking at me. This is the least of the three problems but also the problem I think pretty much everyone identifies with. You could deal with that by letting people code on their own laptop instead of on a whiteboard, but you’d still have the basic problem of interviewing people in a hostile environment.
I think people are too concerned about the whiteboard itself. It isn’t about using a whiteboard or not, it’s what you do with it.
Quizzing candidates about CS problems that have nothing to do with the day-to-day work and penalizing them if they don’t get it perfect on the first try is lame, whether or not you use a whiteboard for it.
On the other hand, getting candidates to write some kind of code somewhere that does something useful and discussing their thought process on techniques, tradeoffs, etc is a good idea, and I’d be worried about working somewhere that didn’t do that. A whiteboard can be a nice way to do that, but there’s lots of other ways, including paper, shared text documents, take-home projects, etc.
The result is a list of companies that do take-home tests… not much of an improvement to be honest, a lot of the time I’d rather spend 15 minutes on a whiteboard than the entire weekend trying to polish up whatever question they thought would only take 2 hours.
I’ve never had to to a whiteboard interview nor did I heard of someone having to do it here in France, maybe that’s more of an American technical interview practice.
Not saying this is you, but I’ve had people say it’s to garner an understanding of my thought process and that the answers don’t matter. I still feel like they’re really hoping for me to get the right answer. Like, if I can’t correctly count the number of substrings that start and end with 1 in a binary string I’ve somehow proven that I can’t program. It can be very demoralizing.
I’ve done one whiteboard test and it was abysmal. The one of the two interviewers was a complete dick throughout, offering no actual help, while the other guy worked with me very well.
Shit I just realized who I’m replying to and you’re familiar with this scenario.
In general, I dislike homework a lot more than whiteboard problems.
I don’t think I’ve ever met the mythical hardass who expects perfect code on a whiteboard. In general, I don’t think it matters a great deal if you miss a semicolon. They’re trying to get a sense of whether you can solve technical problems at all, because our industry is full of charlatans who can’t. (Eventually, they get the hint and go into management or “product”.) Once you realize that perfection isn’t mandatory, those get easier.
I wouldn’t call whiteboarding fun, but it’s definitely one of the less unpleasant interview practices. I’d rather try to optimize a data structure than deal with “Tell me about a time when blah blah” behavioral questions that are designed to trip you up. Considering that software is one of the most dysfunctional industries in modern times, the whiteboard interview is one of the least broken things you’ll encounter in this so-called “career”.
I realized my hate for homework problems, several years ago when I was a lot younger, when I spent a good 20 hours on one. I was told that my submission was one of the top 3 of all time. And I still got the same junior-ish offer that I could have gotten anywhere else. So what was the point of that? All that work for no gain. On the flip side, I’ve been involved in hiring for long enough that I’ve seen a lot of good submissions rejected for bullshit stylistic reasons. The conclusion that I’m left with is that homework can hurt you, but that there’s no upside. So fuck it, it’s a waste of time.
I think I perform better than average if there is a paper programming test or a whiteboard test. If we just talk for 20 minutes instead I don’t think I come off as strong.
Am I the only one around here who doesn’t mind whiteboard interviews? Ultimately you’re just discussing a technical topic with someone and drawing a few boxes and arrows is really useful.
The last time I did a whiteboard interview I didn’t 100% nail the CS puzzler question and, given the offer I got, the interviewer really was mostly interested in my thought process and not my ability to hand indent python code on a whiteboard. I’ve had this experience more than once. Written communication is a skill and being able to communicate your thought process to someone else isn’t as artificial an environment as some make it out to be.
I’m a broken record about how bad whiteboard interviews are, but I think I generally do pretty well on them. After ~15 years of consulting and product management, I’m pretty comfortable in a neutral-to-hostile room. I think I can talk my way through most situations.
But that’s one of the things that scares me about whiteboard interviews. Not that they’re insurmountable hurdles for my own career, but that they’re too easy, and that I get undue positive evaluations just from the ability to remain confident-sounding during them, and, more importantly, by being able to redirect questions and reframe interviews.
I’ve worked with too many people who interviewed well but were almost total zeroes when it came to delivery too put any faith in ad-hoc interview processes.
I came here to say this. I’d much rather go to a whiteboard interview. I don’t do riddles or competitive programming, but I’d appreciate being tested a little more than “tells us about your last project”.
Seeing DHH’s tweet makes me cringe. Sure it works for him, and it works for a lot of people, but for me it is important to know some CS basics. I wouldn’t mind if he said quicksort, or something a little more complicated like that … but bragging that you can’t write the simplest algorithm there is, how is that a good thing?
However, I do agree that take home excercises are good, and I enjoy those too. But they’re not as representative if you don’t ask the candidate to do easy something live.
I think it’s not necessarily a question about substance but more about style. Not everyone’s coding style is amenable to standing in front of people and hand-coding an algorithm while people are sitting there judging every character you write. You’re doing this while you’re expected to talk through what you’re writing on the board. That doesn’t come naturally to some people – when you’re sitting at a computer implementing an algorithm, you’re not talking about it out loud.
Another aspect of this is that a candidate can do better by studying for an interview. That’s a sign of a broken candidate vetting process. A candidate with years of experience and a top performer at their previous job could possibly be rejected based on questions that they may not have seen in years.
CS basics are important but some of that knowledge fades over time. I couldn’t give you a good definition of polymorphism without looking it up but I know what it means. I think the issue comes down to treating every candidate as though they were fresh out of school and the further they are from that, the more likely they are to fail those “basic” CS questions in this type of interview environment.
EDIT: better explanation than mine: https://medium.com/make-better-software/against-the-whiteboard-f1df0013954f#.hx2sgjnrl
DHH has written some valuable software, but the world is bigger than rails. So when I hear that in the early days of rails things leaked memory so bad that app servers had to be restarted every few minutes I think that’s bad. I realize for the type of work his websites were used for that wasn’t a critical defect. In most software I write that would be a critical defect.
more on this?
There was a popular (now depublished) blog post by Zed Shaw called “Rails is a ghetto” where he was railing against a lot of things he perceived as wrong in the Rails community. One of them was that he wrote a critical piece of software, but no one would pay him for that. It was one of the first specialized HTTP adapters in Ruby, called Mongrel. Along with that, he wrote a critical gem that fixed MRIs heavy threading problem back then.
In that post, he mentioned in passing that DHH told him that their initial web stack was so bad that they had to restart it every ~100 requests because it leaked memory and Mongrel improved things a lot.
Now, having programmed Ruby since version 1.6, I think this is probably true. Ruby back then was a fringe language built by a few people that were good language designers, but not necessarily runtime implementors. Also, the runtime was built for scripting workloads, so threading, servers and similar were a not so well tested case. With it becoming popular, thing improved massively and from 1.8.7 and later, I’d call MRI a runtime on par with Python and others. 1.9 finally made it somewhat modern.
But as /u/shanemhansen sais: that wasn’t too critical these kinds of applications. For example, it was standard that PHP websites would follow a CGI-like “one process per connection”-approach to make sure there’s no memory problems due to leaks. Restarting a set of webservers every nth request is also acceptable in such an environment, even if there is always another around.
I think the core of DHH’s argument is rather that he’d like people that understand those subleties and possibilities and you can’t really test that on a whiteboard.
The relevant bit from Rails is a Ghetto:
[Comment removed by author]
In broad strokes, there are three problems with whiteboard interviews.
First: an in-person interview with a stranger at someone’s office is an inherently hostile experience. Different people react differently to that hostile experience. Some people react terribly to it. Two of the very best people I’ve ever hired were physically impaired by stress during their in-person interviews. In one of those cases I had to override the results of the interview process to get the person hired. Since no part of a typical dev job involves working under that kind of stress, it is counterproductive to filter based on it.
Second, and equally importantly: some people do really well in these kinds of interviews. But their performance in the interview is not necessarily correlated with their ability to deliver. Making a bad hire is extremely expensive. A process that selects based on something other than delivery ability is either implicitly or explicitly game-able. I think there’s a whole class of people in this industry who sort of fail “diagonally”, mostly horizontally from company to company but eventually upwards as well as their resumes grow, because it’s virtually impossible for most companies to fire someone in under a year. This happens in part because our screening processes, which are dominated by whiteboard interviews, don’t detect people like this.
Finally, even though I’m not personally that ill-at-ease in a conference room with a whiteboard, I sure as shit don’t code as well on a whiteboard as I do on my laptop in emacs with nobody looking at me. This is the least of the three problems but also the problem I think pretty much everyone identifies with. You could deal with that by letting people code on their own laptop instead of on a whiteboard, but you’d still have the basic problem of interviewing people in a hostile environment.
I think people are too concerned about the whiteboard itself. It isn’t about using a whiteboard or not, it’s what you do with it.
Quizzing candidates about CS problems that have nothing to do with the day-to-day work and penalizing them if they don’t get it perfect on the first try is lame, whether or not you use a whiteboard for it.
On the other hand, getting candidates to write some kind of code somewhere that does something useful and discussing their thought process on techniques, tradeoffs, etc is a good idea, and I’d be worried about working somewhere that didn’t do that. A whiteboard can be a nice way to do that, but there’s lots of other ways, including paper, shared text documents, take-home projects, etc.
The result is a list of companies that do take-home tests… not much of an improvement to be honest, a lot of the time I’d rather spend 15 minutes on a whiteboard than the entire weekend trying to polish up whatever question they thought would only take 2 hours.
Basically a list of companies I’d want to work for.
I’ve never had to to a whiteboard interview nor did I heard of someone having to do it here in France, maybe that’s more of an American technical interview practice.
[Comment from banned user removed]
Not saying this is you, but I’ve had people say it’s to garner an understanding of my thought process and that the answers don’t matter. I still feel like they’re really hoping for me to get the right answer. Like, if I can’t correctly count the number of substrings that start and end with 1 in a binary string I’ve somehow proven that I can’t program. It can be very demoralizing.
Just stare blankly at the interviewer for 5 minutes and if they say anything just say you are thinking.
Is the answer “count the number of 1s, then it’s n choose 2”?
Dunno, do they want unique substrings?
I’ve done one whiteboard test and it was abysmal. The one of the two interviewers was a complete dick throughout, offering no actual help, while the other guy worked with me very well.
Shit I just realized who I’m replying to and you’re familiar with this scenario.
[Comment removed by author]
In general, I dislike homework a lot more than whiteboard problems.
I don’t think I’ve ever met the mythical hardass who expects perfect code on a whiteboard. In general, I don’t think it matters a great deal if you miss a semicolon. They’re trying to get a sense of whether you can solve technical problems at all, because our industry is full of charlatans who can’t. (Eventually, they get the hint and go into management or “product”.) Once you realize that perfection isn’t mandatory, those get easier.
I wouldn’t call whiteboarding fun, but it’s definitely one of the less unpleasant interview practices. I’d rather try to optimize a data structure than deal with “Tell me about a time when blah blah” behavioral questions that are designed to trip you up. Considering that software is one of the most dysfunctional industries in modern times, the whiteboard interview is one of the least broken things you’ll encounter in this so-called “career”.
I realized my hate for homework problems, several years ago when I was a lot younger, when I spent a good 20 hours on one. I was told that my submission was one of the top 3 of all time. And I still got the same junior-ish offer that I could have gotten anywhere else. So what was the point of that? All that work for no gain. On the flip side, I’ve been involved in hiring for long enough that I’ve seen a lot of good submissions rejected for bullshit stylistic reasons. The conclusion that I’m left with is that homework can hurt you, but that there’s no upside. So fuck it, it’s a waste of time.
I think I perform better than average if there is a paper programming test or a whiteboard test. If we just talk for 20 minutes instead I don’t think I come off as strong.