14 ms·

Whiteboard Interviews

73 points by pw 10y ago

amalfra 10y ago
Seriously people think whiteboard interviews are reason for diversity? I think the much bigger reason for diversity issue is that companies are reluctant to even interview if you don't have a brand name associated with your profile(a tier 1 college degree or previous exp at top tech firms). There are lots of job postings these days which state tier 1 college degree as requirement. I am from India and here the situation is if you are not from a tier 1 college you are a moron and designated to do low quality cheap work. It may not be the case in other areas like the valley, but here it seems the filter for participating in the interview has more to do with diversity than how interview is conducted.
throwaway_374 10y ago
>>"Back when I was at Google, I was mostly interviewing people for “Developer Advocate” positions, and a lot of people somehow got into the process without being able to code at all. So, early on, I’d ask. “You’ve got a list of objects, write some code to select one of them at random. Any language, don’t worry about syntax, assume the built-in random function is good enough.” That was actually a nice question: If you wanted to dive a little deeper, you could ask the candidate to sketch in unit tests. And if you’re talking to somebody super-technical, ask “Your code is in production and sometimes it’s throwing illegal-index exceptions under heavy load. What’s going on and how do you fix it?” Just because that’s a cool problem, very real-life, and most people smile when they get it." Genuinely curious as to what the reasons for illegal-index exceptions under heavy load would be? I genuinely can't think of any reason. Perhaps the problem is under specified. Unit-testing would need to be seeded to be reproducible.
- fnbr 10y ago
  I could see it being some sort of shared memory problem, where the system is misallocating memory because it's running out of free space.
  - joshuamorton 10y ago
    Or similarly, the application is multithreaded and the list length at `idx = randint(list.length)` time is greater than the next line `obj = list[idx]`, when you pick one of the last few indices and objects are removed.
- jsnell 10y ago
  I think the implication is that another thread is modifying the list at the same time, and there's inadequate locking.
- joshvm 10y ago
  I think you need more information about the code and what situation it's in. Illegal index presumably means trying to access part of the list that's no longer there. If it's a shared data structure, perhaps something is popping the list while another is trying to access the last element. But without anything else to go on, who knows, maybe you accidentally stored the length of the list in a data type that could overflow? Though in the first part of the question (ignoring the next bit), is the answer anything more complex than import random; random.choice(my_list)?
news_to_me 10y ago
This article is a nice reminder of the truism, "don't do things in a shitty way and they won't be shitty." That is, whiteboard interviews aren't inherently terrible, it's just that a lot of interviewers ask terrible whiteboard-based questions, like asking to code in unrealistic circumstances. But I think that also kind of highlights what DHH and others are trying to get at - a lot of programming interviews are terrible because they abuse the whiteboard, and that needs to stop.
- wry_discontent 10y ago
  The problem is that you have to have some way to evaluate someone's skill level relatively quickly. Take home assignments will never work. Part time work, or contracting work until you're satisfied is going to be even worse from the perspective of a job searcher. Imagine you get a new job that pays half of what your last job did and then you get dismissed at the end of 3 months and have to restart your search. I don't understand all the fuss. Whiteboard interviews are unpleasant, sure, but I've done a lot of them and they're not that bad.
  - lj3 10y ago
    > Imagine you get a new job that pays half of what your last job did and then you get dismissed at the end of 3 months and have to restart your search. I'd take that. You're still getting paid for your work instead of spending months searching with no income. It also gives you a chance to see who you're working with, who your boss is and the state of the code base you'll be spending the next several years of your life on. You don't get any of that in a whiteboard interview.
    - watwut 10y ago
      That form of interview would make company loose on employed applicants. It would also be expensive in case there are more applicants then positions - or you would be back to normal interviews. Also, imagine competing with multiple other people for three minths over which one will stay after three months and who will have to search again. I can easily see how toxic it all could become.
tptacek 10y ago
Interviews don't demonstrate ability or aptitude so much as they demonstrate ability to keep a cool head under incredible pressure. It doesn't matter how soft you make the whiteboard question: you are getting lower quality signal in an in-person office interview than you will in any other venue. Interviews are incredibly hostile experiences and nothing you can do, including comfy chairs, bright, cheerful surroundings, or free drinks will change that. We need to engage with the fact that these interview processes are just stupid. We know a number of better ways to extract signal from candidates, but we keep interviewing face-to-face for technical ability because that's how it's always been done. A number of companies are trying to embrace work-sample challenges to boost signal from candidates. But I don't think they get it. They assign take-home work before or after an interview, and still make decisions on candidates based on an "interview loop". If you have an interview loop composed solely of people, I don't believe in your process. We had a sort of interview loop at Matasano, but the open secret was it largely didn't matter, because if your (numeric) scores on our work sample tests were solid, the burden of proof was on the interviewers to override the work sample tests. We worked with a number of different hiring groups at Starfighter last year, some of them quite smart, and at none of them did I see a process that deliberately and meaningfully insulated itself from "I'm having a bad day and haven't eaten lunch yet and now I have to interview someone" bias, or from "I'm putting you, the candidate, in the most uncomfortable imaginable professional circumstances and expecting not only perfect recall of the intricate details of your craft but also that you recite those details in a way that demonstrates confidence and ability to get things done". All the hiring I see is still done by by subjective X-factors; worse, each interviewer in a "loop" has a different X-factor. Where's the table-flip emoji when I need it?
- Retric 10y ago
  A huge chunk of this stress is most people simply don't code on whiteboards most of the time. It's a skill which you can pick up fairly quickly which destroys the validity of this kind of hazing.
  - lj3 10y ago
    That's not the source of the stress of coding on a whiteboard. The source of the stress is you have to guess what the interviewer wants or you don't get to pay your bills next month.
tbirrell 10y ago
I'm glad he does it right. Now if the people interviewing me could do it right, that would be great.
the_arun 10y ago
Whiteboard really helps one to express his/her thought process to the other person and I'd hope it will continue to exist in the interviews.
- orless 10y ago
  The whole topic is about coding on the whiteboard, not just expressing the thought process.
- m3kw9 10y ago
  Then the interviewer should explicitly say he wants to know your thought process too. 99% of them just say code this and let me know when you are done
charles-salvia 10y ago
I've been doing interviews pretty frequently lately. Maybe it's just the limited scope of my experience, but I've never asked anyone to code bubble-sort, nor do I know anyone who has ever asked that, nor have I ever been asked that at a job interview. The closest thing I've seen to this, probably, is generic tree-traversal questions, like find the lowest common ancestor of two nodes, or whatever. Apparently the feeling these days is that these sort of questions suck because they're not "real world" enough, and you'll never need to know about such stupid things like "nodes" and "algorithms" and "computer science" on the job. So now I guess the trend is to ask more trendy, design-oriented questions like, "how would you design Facebook?", etc. But the problem with all this backlash to algorithm-heavy whiteboard interviews is that it ignores the reality that there are tons and tons and tons of crappy candidates out there. I'd prefer a candidate who understands pointer arithmetic and can implement a recursive descent parser over someone who vaguely describes how Twitter might work at a high level. It's not that I am claiming that most on-the-job programming is implementing algorithms and data structures (it's obviously not), but being able to do these things indicates a certain quantifiable level of aptitude. The trick is to present the questions in a way that isn't vulnerable to rote memorization. Don't ask someone to simply code a tree or graph traversal algorithm. Instead ask them about the most efficient way to route packets or whatever. And more importantly, tailor the interview questions to the actual experience they claim to have on their resume. If they claim to be a machine learning expert, ask them to sketch out how a multilayer-perceptron actually works. If they claim to know about the Linux kernel, ask them to design a page-cache, etc. I agree the "you have 5 minutes to implement quick-sort now!!" is not helpful. I also hate the stupid logic-puzzle crap. But let's not completely dumb-down the whole interview process as a remedy to all this, just because "real-world" programming is more about import java.util.* rather than coding up custom radix tries.
- deleted 10y ago
  [deleted]
- Domenic_S 10y ago
  > I'd prefer a candidate who understands pointer arithmetic and can implement a recursive descent parser over someone who vaguely describes how Twitter might work at a high level. If the position you're hiring for involves those things on a regular basis, fine. If not, you're probably selecting inefficiently. The reason for the swing over into high-level questions is managers are learning that smart, often academically-inclined engineers will happily burn weeks on something they find interesting but adds value incongruent with the expenditure. The recent trend of hiring experienced engineers to be engineering managers either exposes the problem or exacerbates it. If two candidates are equally qualified to do the job, but one demonstrated they can think through high-level designs -- I pick that one.
orless 10y ago
In my previous company we used ask candidates to code a very simple task: reverse a string in Java, on the whiteboard or on paper. It is a trivial task but many seasoned people failed it to the extent that we thought "you don't really know Java, do you?". To this day I'm very suspicious when I don't get a coding task on an interview. That's generally a pretty bad sign. Best option is when I get a notebook with "my" IDE, but I also coded on whiteboards, paper, Google Docs. Frankly, I don't know what other options are there. There should be code in the developer interview. Take-home task? GitHub account? Probation day?
- patrickmay 10y ago
  > In my previous company we used ask candidates to code a very simple task: reverse a string in Java, on the whiteboard or on paper. It is a trivial task but many seasoned people failed it to the extent that we thought "you don't really know Java, do you?". At the end of a day of interviews for a consulting gig a number of years ago I was asked to sit in front of a workstation and type while most of the developers were watching. I asked "Type what?" and got the answer "Anything." I started typing a paragraph from my resume and after one sentence the interviewer said "Stop, that's fine. The last guy who made it through the interview couldn't do that." It turned out to be a fun project.
  - orless 10y ago
    On one interview they asked me what my favorite pattern was. I said "visitor", was already about to start explaining but heard a deep breath-out and "thanks God he didn't say singleton". Appeared they had it pretty high in hiring criteria.
- ashark 10y ago
  > In my previous company we used ask candidates to code a very simple task: reverse a string in Java, on the whiteboard or on paper. It is a trivial task but many seasoned people failed it to the extent that we thought "you don't really know Java, do you?". I've written quite a bit of Java in the last year (though not in the last couple months), and a fair bit before that. I'd have a low probability of giving you a correct answer to that question without references—I have several possible approaches but I'm not 100% certain which would work without checking. Can I treat Java strings as arrays? Or is there some kind of toArray thing I need to do first? I think so but I'd have to check to be certain. Is there a string-reversing util method somewhere? Quite possibly. How do I read it one byte (glyph? Ugh, I can't remember how Java strings work and I have Go on the brain, I think) at a time if the treat-as-an-array thing doesn't work? God, I don't remember. What's string length again? size, length? Maybe even len? Assuming I figure that out, was that a property or a method, now? Hell if I know, it's not like I've written more than a dozen lines of Java outside an IDE, ever, unlike some other languages. I suppose I can use split if I have to (it's just called "split" in java, right? I can't remember for certain, of course!) I'm sure some people memorize this stuff. Plenty of us, I'm sure, if it's not something we use ALL. THE. TIME. rely very heavily on tools, context (i.e. cheating for syntax by looking at surrounding lines) and documentation. I haven't been doing tons of specifically string manipulation in java lately, so I'd likely be screwed on this question. I dunno, I guess by that standard I know zero of the 7-8 languages I've been paid to write over the last fifteen years or so.
m3kw9 10y ago
The issue is the dependence of code completion, google, and IDEs that writes boiler plate code for you, and companies just use stupid services like hackerrank to test algorithm implementations, which has to run and compile properly u see that environment.
OhHeyItsE 10y ago
I don't think anyone has any issue with having to physically use a marker on a whiteboard during an interview. What else would you use for a system design question? What is insane is expecting a candidate to be able to navigate a million state modification and off-by-one gotchas using only a marker and their short-term memory.
- kevinr 10y ago
  > I don't think anyone has any issue with having to physically use a marker on a whiteboard during an interview. I have friends whose RSI is sufficiently bad that it could be an issue.
djhworld 10y ago
> By the way I got one of those in my interview day at Google, and another at Amazon, and I blew them both. Interesting to hear this, can't have done that badly as he got jobs at both of those companies!
mcbits 10y ago
Being able to communicate via whiteboard is a useful skill. I'm not good at it, but I appreciate those who are. That seems to be what this author is advocating: jotting down ideas, designs, diagrams, temporary notes. If the team depends on everyone being comfortable at a whiteboard, then it's worth testing at an interview. I don't think that is what most people are pushing against, but rather actual whiteboard coding. Taking the whiteboard out of the picture, the task is to write code in an unrealistically broken editor. You get a partially functioning backspace but no insert, indent/outdent, search/replace, etc. And the editor restricts your typing speed to 10% of your normal capacity. On top of that, strangers are staring at you. If whiteboard coding really leads to better hires than other forms of evaluation, I'd like to see the data.
joeax 10y ago
Maybe I'm out there as far as this topic is concerned, but as a software engineer I enjoy whiteboard interviews. If you can't get up in front of a couple potential colleagues and talk/draw code, how are you supposed to whiteboard complex designs in meetings after you are hired, possibly to higher-ups? But I agree there should be set parameters in an interview: ask every candidate the same open-ended design questions, stress that they just use pseudocode, keep the problem questions small (5-10 mins max), don't be a overlording interviewing jerk, etc.
MorePowerToYou 10y ago
I think the optimal solution to the hiring problem requires trying out the actual relationship. It's similar to dating. Predicting the long-term success of a relationship based on a first date is sub-optimal. A service that provides this "trial relationship" could work. When I'm looking for a new job, I could do one hour per day of real work for a few companies. After five days, both employer and prospective employee will have a better understanding of each other than a single day of interviews allows. There's practical concerns. Companies certainly wouldn't give prospective employees full access to internal codebases or data. Companies would have to break off small tasks which could devolve into throw-away take-home assignments. Employees at the company would have to endure the annoyance of dealing with prospective hires. It might be worth it for everyone.
- w0rd-driven 10y ago
  This is sadly rife for abuse. Why hire anyone? You can just string enough candidates along to possibly not work a full solution but it could be a first line or give you a fair number of prototypes. Granted I don't know that this could ever be viable but companies would sure try because free work > paying any amount. I think most of us understand the phrase 'you get what you pay for' and yet I've personally seen many individuals and companies believe they're getting a steal. I feel like there are a few good ideas. I personally love the idea of work related assignments but only if the result is actually measured. If I don't get the job I know I've wasted my time and I can handle that. What I can't handle is giving me a task and completely ignoring the results. What will that signal to me about day to day operations? That you'll likely ignore the very real value I bring to your organization on a consistent basis. That's a big enough red flag for me to stop everything and walk right out the door. If I'm supposed to extend the courtesy of not wasting the interviewers time I expect at least some attempt at that same courtesy.
agentgt 10y ago
I absolutely hate whiteboard interviews. I have been lucky enough to have had only one whiteboard interview in my career and I will say it was awful. Luckily I didn't really need the job as I had freelance on the side. IIRC the company was TripAdvisor... I will not name the interviewer's name but he does have a blog... sadly I think he is actually proud of his interviewing and management techniques). I have absolutely terrible handwriting and even worse ability in penmanship layout (basically what I call consistent and appropriate spacing). Before the interview the interviewer didn't even shake my hand and barely made eye contact with me. He looked pissed before we even started (its ironic again because the guy praises his people skills in his blog). In the interview I was asked to do a binary tree sort. I did it recursively. He wanted it to be not recursive and with an array. At this point I was pretty nervous and my whiteboard looked like a 5 year olds scribbling. I just wanted the interview to end so I sort of just gave up. A couple months later I ironically started a successful recruiting software company. Even more ironic the interviewer later tried to start his own startup but failed and had to go back to TripAdvisor (this was about 3 or 4 years ago). I tried to connect on LinkedIn with him to give him some feedback... alas he did not connect. The reason I wanted to leave him feedback (besides the sick inkling to rub in my success) is I have learned so much from my recruiting software company. I see people desperately applying for jobs everyday (we are career portals as a service. We try to make the apply process as painless as possible). People seem to forget how uncomfortable it is to go looking for a job (probably why he went back to his old company).
nunez 10y ago
Two weeks ago, a coworker and I were thinking through ways of implementing an extension to a library we've been writing for a client. We were drawing all sorts of things to come to a consensus of what to do. Through doing all of that, I finally experienced a real-life reason to whiteboard code, since after writing down psuedocode on the whiteboard explaining the implementation that we were agreeing upon, everyone on our team "got it" immediately. I think whiteboard interviews are incredibly useful. We use them in our interviews, and they've been successful in helping us learn more about our candidates' abilities and for them to show us what they know.

73 points by pw 10y ago

Seriously people think whiteboard interviews are reason for diversity? I think the much bigger reason for diversity issue is that companies are reluctant to even interview if you don't have a brand name associated with your profile(a tier 1 college degree or previous exp at top tech firms). There are lots of job postings these days which state tier 1 college degree as requirement. I am from India and here the situation is if you are not from a tier 1 college you are a moron and designated to do low quality cheap work. It may not be the case in other areas like the valley, but here it seems the filter for participating in the interview has more to do with diversity than how interview is conducted.

throwaway_374 10y ago

>>"Back when I was at Google, I was mostly interviewing people for “Developer Advocate” positions, and a lot of people somehow got into the process without being able to code at all. So, early on, I’d ask. “You’ve got a list of objects, write some code to select one of them at random. Any language, don’t worry about syntax, assume the built-in random function is good enough.” That was actually a nice question: If you wanted to dive a little deeper, you could ask the candidate to sketch in unit tests. And if you’re talking to somebody super-technical, ask “Your code is in production and sometimes it’s throwing illegal-index exceptions under heavy load. What’s going on and how do you fix it?” Just because that’s a cool problem, very real-life, and most people smile when they get it." Genuinely curious as to what the reasons for illegal-index exceptions under heavy load would be? I genuinely can't think of any reason. Perhaps the problem is under specified. Unit-testing would need to be seeded to be reproducible.

fnbr 10y ago
I could see it being some sort of shared memory problem, where the system is misallocating memory because it's running out of free space.
- joshuamorton 10y ago
  Or similarly, the application is multithreaded and the list length at `idx = randint(list.length)` time is greater than the next line `obj = list[idx]`, when you pick one of the last few indices and objects are removed.
jsnell 10y ago
I think the implication is that another thread is modifying the list at the same time, and there's inadequate locking.
joshvm 10y ago
I think you need more information about the code and what situation it's in. Illegal index presumably means trying to access part of the list that's no longer there. If it's a shared data structure, perhaps something is popping the list while another is trying to access the last element. But without anything else to go on, who knows, maybe you accidentally stored the length of the list in a data type that could overflow? Though in the first part of the question (ignoring the next bit), is the answer anything more complex than import random; random.choice(my_list)?

news_to_me 10y ago

This article is a nice reminder of the truism, "don't do things in a shitty way and they won't be shitty." That is, whiteboard interviews aren't inherently terrible, it's just that a lot of interviewers ask terrible whiteboard-based questions, like asking to code in unrealistic circumstances. But I think that also kind of highlights what DHH and others are trying to get at - a lot of programming interviews are terrible because they abuse the whiteboard, and that needs to stop.

wry_discontent 10y ago
The problem is that you have to have some way to evaluate someone's skill level relatively quickly. Take home assignments will never work. Part time work, or contracting work until you're satisfied is going to be even worse from the perspective of a job searcher. Imagine you get a new job that pays half of what your last job did and then you get dismissed at the end of 3 months and have to restart your search. I don't understand all the fuss. Whiteboard interviews are unpleasant, sure, but I've done a lot of them and they're not that bad.
- lj3 10y ago
  > Imagine you get a new job that pays half of what your last job did and then you get dismissed at the end of 3 months and have to restart your search. I'd take that. You're still getting paid for your work instead of spending months searching with no income. It also gives you a chance to see who you're working with, who your boss is and the state of the code base you'll be spending the next several years of your life on. You don't get any of that in a whiteboard interview.
  - watwut 10y ago
    That form of interview would make company loose on employed applicants. It would also be expensive in case there are more applicants then positions - or you would be back to normal interviews. Also, imagine competing with multiple other people for three minths over which one will stay after three months and who will have to search again. I can easily see how toxic it all could become.

tptacek 10y ago

Interviews don't demonstrate ability or aptitude so much as they demonstrate ability to keep a cool head under incredible pressure. It doesn't matter how soft you make the whiteboard question: you are getting lower quality signal in an in-person office interview than you will in any other venue. Interviews are incredibly hostile experiences and nothing you can do, including comfy chairs, bright, cheerful surroundings, or free drinks will change that. We need to engage with the fact that these interview processes are just stupid. We know a number of better ways to extract signal from candidates, but we keep interviewing face-to-face for technical ability because that's how it's always been done. A number of companies are trying to embrace work-sample challenges to boost signal from candidates. But I don't think they get it. They assign take-home work before or after an interview, and still make decisions on candidates based on an "interview loop". If you have an interview loop composed solely of people, I don't believe in your process. We had a sort of interview loop at Matasano, but the open secret was it largely didn't matter, because if your (numeric) scores on our work sample tests were solid, the burden of proof was on the interviewers to override the work sample tests. We worked with a number of different hiring groups at Starfighter last year, some of them quite smart, and at none of them did I see a process that deliberately and meaningfully insulated itself from "I'm having a bad day and haven't eaten lunch yet and now I have to interview someone" bias, or from "I'm putting you, the candidate, in the most uncomfortable imaginable professional circumstances and expecting not only perfect recall of the intricate details of your craft but also that you recite those details in a way that demonstrates confidence and ability to get things done". All the hiring I see is still done by by subjective X-factors; worse, each interviewer in a "loop" has a different X-factor. Where's the table-flip emoji when I need it?

Retric 10y ago
A huge chunk of this stress is most people simply don't code on whiteboards most of the time. It's a skill which you can pick up fairly quickly which destroys the validity of this kind of hazing.
- lj3 10y ago
  That's not the source of the stress of coding on a whiteboard. The source of the stress is you have to guess what the interviewer wants or you don't get to pay your bills next month.

tbirrell 10y ago

I'm glad he does it right. Now if the people interviewing me could do it right, that would be great.

the_arun 10y ago

Whiteboard really helps one to express his/her thought process to the other person and I'd hope it will continue to exist in the interviews.

orless 10y ago
The whole topic is about coding on the whiteboard, not just expressing the thought process.
m3kw9 10y ago
Then the interviewer should explicitly say he wants to know your thought process too. 99% of them just say code this and let me know when you are done

charles-salvia 10y ago

I've been doing interviews pretty frequently lately. Maybe it's just the limited scope of my experience, but I've never asked anyone to code bubble-sort, nor do I know anyone who has ever asked that, nor have I ever been asked that at a job interview. The closest thing I've seen to this, probably, is generic tree-traversal questions, like find the lowest common ancestor of two nodes, or whatever. Apparently the feeling these days is that these sort of questions suck because they're not "real world" enough, and you'll never need to know about such stupid things like "nodes" and "algorithms" and "computer science" on the job. So now I guess the trend is to ask more trendy, design-oriented questions like, "how would you design Facebook?", etc. But the problem with all this backlash to algorithm-heavy whiteboard interviews is that it ignores the reality that there are tons and tons and tons of crappy candidates out there. I'd prefer a candidate who understands pointer arithmetic and can implement a recursive descent parser over someone who vaguely describes how Twitter might work at a high level. It's not that I am claiming that most on-the-job programming is implementing algorithms and data structures (it's obviously not), but being able to do these things indicates a certain quantifiable level of aptitude. The trick is to present the questions in a way that isn't vulnerable to rote memorization. Don't ask someone to simply code a tree or graph traversal algorithm. Instead ask them about the most efficient way to route packets or whatever. And more importantly, tailor the interview questions to the actual experience they claim to have on their resume. If they claim to be a machine learning expert, ask them to sketch out how a multilayer-perceptron actually works. If they claim to know about the Linux kernel, ask them to design a page-cache, etc. I agree the "you have 5 minutes to implement quick-sort now!!" is not helpful. I also hate the stupid logic-puzzle crap. But let's not completely dumb-down the whole interview process as a remedy to all this, just because "real-world" programming is more about import java.util.* rather than coding up custom radix tries.

deleted 10y ago
[deleted]
Domenic_S 10y ago
> I'd prefer a candidate who understands pointer arithmetic and can implement a recursive descent parser over someone who vaguely describes how Twitter might work at a high level. If the position you're hiring for involves those things on a regular basis, fine. If not, you're probably selecting inefficiently. The reason for the swing over into high-level questions is managers are learning that smart, often academically-inclined engineers will happily burn weeks on something they find interesting but adds value incongruent with the expenditure. The recent trend of hiring experienced engineers to be engineering managers either exposes the problem or exacerbates it. If two candidates are equally qualified to do the job, but one demonstrated they can think through high-level designs -- I pick that one.

orless 10y ago

In my previous company we used ask candidates to code a very simple task: reverse a string in Java, on the whiteboard or on paper. It is a trivial task but many seasoned people failed it to the extent that we thought "you don't really know Java, do you?". To this day I'm very suspicious when I don't get a coding task on an interview. That's generally a pretty bad sign. Best option is when I get a notebook with "my" IDE, but I also coded on whiteboards, paper, Google Docs. Frankly, I don't know what other options are there. There should be code in the developer interview. Take-home task? GitHub account? Probation day?

patrickmay 10y ago
> In my previous company we used ask candidates to code a very simple task: reverse a string in Java, on the whiteboard or on paper. It is a trivial task but many seasoned people failed it to the extent that we thought "you don't really know Java, do you?". At the end of a day of interviews for a consulting gig a number of years ago I was asked to sit in front of a workstation and type while most of the developers were watching. I asked "Type what?" and got the answer "Anything." I started typing a paragraph from my resume and after one sentence the interviewer said "Stop, that's fine. The last guy who made it through the interview couldn't do that." It turned out to be a fun project.
- orless 10y ago
  On one interview they asked me what my favorite pattern was. I said "visitor", was already about to start explaining but heard a deep breath-out and "thanks God he didn't say singleton". Appeared they had it pretty high in hiring criteria.
ashark 10y ago
> In my previous company we used ask candidates to code a very simple task: reverse a string in Java, on the whiteboard or on paper. It is a trivial task but many seasoned people failed it to the extent that we thought "you don't really know Java, do you?". I've written quite a bit of Java in the last year (though not in the last couple months), and a fair bit before that. I'd have a low probability of giving you a correct answer to that question without references—I have several possible approaches but I'm not 100% certain which would work without checking. Can I treat Java strings as arrays? Or is there some kind of toArray thing I need to do first? I think so but I'd have to check to be certain. Is there a string-reversing util method somewhere? Quite possibly. How do I read it one byte (glyph? Ugh, I can't remember how Java strings work and I have Go on the brain, I think) at a time if the treat-as-an-array thing doesn't work? God, I don't remember. What's string length again? size, length? Maybe even len? Assuming I figure that out, was that a property or a method, now? Hell if I know, it's not like I've written more than a dozen lines of Java outside an IDE, ever, unlike some other languages. I suppose I can use split if I have to (it's just called "split" in java, right? I can't remember for certain, of course!) I'm sure some people memorize this stuff. Plenty of us, I'm sure, if it's not something we use ALL. THE. TIME. rely very heavily on tools, context (i.e. cheating for syntax by looking at surrounding lines) and documentation. I haven't been doing tons of specifically string manipulation in java lately, so I'd likely be screwed on this question. I dunno, I guess by that standard I know zero of the 7-8 languages I've been paid to write over the last fifteen years or so.

m3kw9 10y ago

The issue is the dependence of code completion, google, and IDEs that writes boiler plate code for you, and companies just use stupid services like hackerrank to test algorithm implementations, which has to run and compile properly u see that environment.

OhHeyItsE 10y ago

I don't think anyone has any issue with having to physically use a marker on a whiteboard during an interview. What else would you use for a system design question? What is insane is expecting a candidate to be able to navigate a million state modification and off-by-one gotchas using only a marker and their short-term memory.

kevinr 10y ago
> I don't think anyone has any issue with having to physically use a marker on a whiteboard during an interview. I have friends whose RSI is sufficiently bad that it could be an issue.

djhworld 10y ago

> By the way I got one of those in my interview day at Google, and another at Amazon, and I blew them both. Interesting to hear this, can't have done that badly as he got jobs at both of those companies!

mcbits 10y ago

Being able to communicate via whiteboard is a useful skill. I'm not good at it, but I appreciate those who are. That seems to be what this author is advocating: jotting down ideas, designs, diagrams, temporary notes. If the team depends on everyone being comfortable at a whiteboard, then it's worth testing at an interview. I don't think that is what most people are pushing against, but rather actual whiteboard coding. Taking the whiteboard out of the picture, the task is to write code in an unrealistically broken editor. You get a partially functioning backspace but no insert, indent/outdent, search/replace, etc. And the editor restricts your typing speed to 10% of your normal capacity. On top of that, strangers are staring at you. If whiteboard coding really leads to better hires than other forms of evaluation, I'd like to see the data.

joeax 10y ago

Maybe I'm out there as far as this topic is concerned, but as a software engineer I enjoy whiteboard interviews. If you can't get up in front of a couple potential colleagues and talk/draw code, how are you supposed to whiteboard complex designs in meetings after you are hired, possibly to higher-ups? But I agree there should be set parameters in an interview: ask every candidate the same open-ended design questions, stress that they just use pseudocode, keep the problem questions small (5-10 mins max), don't be a overlording interviewing jerk, etc.

MorePowerToYou 10y ago

I think the optimal solution to the hiring problem requires trying out the actual relationship. It's similar to dating. Predicting the long-term success of a relationship based on a first date is sub-optimal. A service that provides this "trial relationship" could work. When I'm looking for a new job, I could do one hour per day of real work for a few companies. After five days, both employer and prospective employee will have a better understanding of each other than a single day of interviews allows. There's practical concerns. Companies certainly wouldn't give prospective employees full access to internal codebases or data. Companies would have to break off small tasks which could devolve into throw-away take-home assignments. Employees at the company would have to endure the annoyance of dealing with prospective hires. It might be worth it for everyone.

w0rd-driven 10y ago
This is sadly rife for abuse. Why hire anyone? You can just string enough candidates along to possibly not work a full solution but it could be a first line or give you a fair number of prototypes. Granted I don't know that this could ever be viable but companies would sure try because free work > paying any amount. I think most of us understand the phrase 'you get what you pay for' and yet I've personally seen many individuals and companies believe they're getting a steal. I feel like there are a few good ideas. I personally love the idea of work related assignments but only if the result is actually measured. If I don't get the job I know I've wasted my time and I can handle that. What I can't handle is giving me a task and completely ignoring the results. What will that signal to me about day to day operations? That you'll likely ignore the very real value I bring to your organization on a consistent basis. That's a big enough red flag for me to stop everything and walk right out the door. If I'm supposed to extend the courtesy of not wasting the interviewers time I expect at least some attempt at that same courtesy.

agentgt 10y ago

I absolutely hate whiteboard interviews. I have been lucky enough to have had only one whiteboard interview in my career and I will say it was awful. Luckily I didn't really need the job as I had freelance on the side. IIRC the company was TripAdvisor... I will not name the interviewer's name but he does have a blog... sadly I think he is actually proud of his interviewing and management techniques). I have absolutely terrible handwriting and even worse ability in penmanship layout (basically what I call consistent and appropriate spacing). Before the interview the interviewer didn't even shake my hand and barely made eye contact with me. He looked pissed before we even started (its ironic again because the guy praises his people skills in his blog). In the interview I was asked to do a binary tree sort. I did it recursively. He wanted it to be not recursive and with an array. At this point I was pretty nervous and my whiteboard looked like a 5 year olds scribbling. I just wanted the interview to end so I sort of just gave up. A couple months later I ironically started a successful recruiting software company. Even more ironic the interviewer later tried to start his own startup but failed and had to go back to TripAdvisor (this was about 3 or 4 years ago). I tried to connect on LinkedIn with him to give him some feedback... alas he did not connect. The reason I wanted to leave him feedback (besides the sick inkling to rub in my success) is I have learned so much from my recruiting software company. I see people desperately applying for jobs everyday (we are career portals as a service. We try to make the apply process as painless as possible). People seem to forget how uncomfortable it is to go looking for a job (probably why he went back to his old company).

nunez 10y ago

Two weeks ago, a coworker and I were thinking through ways of implementing an extension to a library we've been writing for a client. We were drawing all sorts of things to come to a consensus of what to do. Through doing all of that, I finally experienced a real-life reason to whiteboard code, since after writing down psuedocode on the whiteboard explaining the implementation that we were agreeing upon, everyone on our team "got it" immediately. I think whiteboard interviews are incredibly useful. We use them in our interviews, and they've been successful in helping us learn more about our candidates' abilities and for them to show us what they know.