Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

More whiteboard coding won’t build you a better team

blog.hackerhires.com

Post reply on HN
Print view View original

11–20 of 46 posts

Re: More whiteboard coding won’t build you a better team

#11

Post by jpdoctor »

paulgb wrote: post #5

The best interview experiences I've had have started with whiteboard coding but turned into a discussion about the code, assumptions, requirements, theoretical possibilities vs. practicalities, etc. The worst have been ones where it was clear the interviewer had pulled questions out of the company's interview playbook and didn't have the depth of understanding to discuss them.

> The worst have been ones where it was clear the interviewer had pulled questions out of the company's interview playbook and didn't have the depth of understanding to discuss them.

I'd argue that also belongs under the "best" list, because it told you exactly the level of the people you'd be working for/with.

Re: More whiteboard coding won’t build you a better team

#12

Post by ianstallings »

I don't care about these tests. I have a very simple interview process - I ask you what you've done and we talk through it. I may even ask you about how you've solved some problems involved with whatever you were working on. I then jokingly ask you about an inner join or a fib sequence and laugh after a few seconds.

Maybe it's because my I come from the family business of construction years ago, but I believe that it should be easy to hire someone and get them involved quickly. Then we can find out if they are worth it or not. Anything up until that point is talk, and talk is cheap. If they don't past muster eventually I get rid of them. Explaining this up front makes it even easier. I'll hire you quick, but if you don't do what I need you're out. It's not personal.

Re: More whiteboard coding won’t build you a better team

#13

Post by randometc »

munin wrote: post #10

semi-serious devils advocacy. I don't know if the below is an argument that is correct but I hope for it to be proven wrong. I am pretty sure that accurately assessing individual capacity/potential is really, really, really hard. "Google is a very successful technology company. While some of the problems they solve are very challenging and require innovative thinking and research, they have employees with decades of…

The question is: what is your tolerance for (a) false negatives and (b) false positives?

Rephrasing (a): who are we passing on, are they in fact good potential employees, and what qualities do they have that our new hires might not?

Rephrasing (b): who have we hired that, despite whiteboard coding proficiency, isn't cutting it? And why?

In my experience whiteboard coding sessions feel adversarial, like a trap or a test, and you're basically waiting for the candidate to have an epiphany moment. Either they know the problem, or they don't but they get lucky and hit the "right" answer.

Doing reviews of code samples (or even pair programming against a new problem) puts interviewer and candidate both on the same side of the problem and feels more collaborative - I want to believe this gets you a better sense of what someone would be like to work with, and fewer false positives and negatives.

If anyone has evidence or studies either way I'd love to read them.

Re: More whiteboard coding won’t build you a better team

#14

Post by kylemaxwell »

"Competant [sic] developers, even those who don’t specialize in JS, should be able to answer this question in 5-6 minutes. Therefore, this is a quick filter."

This is a false statement. I have programmed for years, but never in Javascript, so I have no clue what "add a cache to a Javascript function" even means. I can quite easily write code "that determines if a number is prime", but the assumption that everybody knows JS even if they don't "specialize" in it is problematic from my PoV.

Re: More whiteboard coding won’t build you a better team

#15

Post by cgag »

kylemaxwell wrote: post #14

"Competant [sic] developers, even those who don’t specialize in JS, should be able to answer this question in 5-6 minutes. Therefore, this is a quick filter." This is a false statement. I have programmed for years, but never in Javascript, so I have no clue what "add a cache to a Javascript function" even means. I can quite easily write code "that determines if a number is prime", but the assumption that everybody kn…

I think it just means add memoization, I don't think there's anything javascript specific about it.

Re: More whiteboard coding won’t build you a better team

#16

Post by seabee »

kylemaxwell wrote: post #14

"Competant [sic] developers, even those who don’t specialize in JS, should be able to answer this question in 5-6 minutes. Therefore, this is a quick filter." This is a false statement. I have programmed for years, but never in Javascript, so I have no clue what "add a cache to a Javascript function" even means. I can quite easily write code "that determines if a number is prime", but the assumption that everybody kn…

The question actually has nothing to do with JavaScript specifically, it's not much more than 'do you know what memoization is' if I understood it correctly.

Re: More whiteboard coding won’t build you a better team

#17

Post by munin »

randometc wrote: post #13
munin wrote: post #10

semi-serious devils advocacy. I don't know if the below is an argument that is correct but I hope for it to be proven wrong. I am pretty sure that accurately assessing individual capacity/potential is really, really, really hard. "Google is a very successful technology company. While some of the problems they solve are very challenging and require innovative thinking and research, they have employees with decades of…

The question is: what is your tolerance for (a) false negatives and (b) false positives? Rephrasing (a): who are we passing on, are they in fact good potential employees, and what qualities do they have that our new hires might not? Rephrasing (b): who have we hired that, despite whiteboard coding proficiency, isn't cutting it? And why? In my experience whiteboard coding sessions feel adversarial, like a trap or a te…

I think this is the correct question to ask.

in my experience, false positives in early ventures (research projects, startups, project partnerships, whatever) are the kiss of death. If you need a group of people to do work at high capacity, bringing someone who does not 'fit' in when the group is young will probably destroy it. existing high-capacity people will become angry, there is less fault tolerance in the quality of the work and the rate at which it has to be done, etc.

it is usually the case that it is better to have 2 workers who click and are highly productive than 5 workers where 1 is not productive. so in the early days, failing closed seems very valuable.

when you are larger, there could be a higher tolerance. you could afford to hire someone and fire them a few months later if they do not work out, because the work that they are doing for you immediately is not as critical. however, there is also a certain culture that comes along with this and if you want to avoid that culture it seems like you still want to 'think lean' and part of that thinking could be to keep the amount of productive people high.

and it might also not go well with your current group members to say "yes, that hire was bad and we'll terminate them next week" for the fifth, sixth time in a quarter ...

Re: More whiteboard coding won’t build you a better team

#18

Post by danielweber »

randometc wrote: post #13
munin wrote: post #10

semi-serious devils advocacy. I don't know if the below is an argument that is correct but I hope for it to be proven wrong. I am pretty sure that accurately assessing individual capacity/potential is really, really, really hard. "Google is a very successful technology company. While some of the problems they solve are very challenging and require innovative thinking and research, they have employees with decades of…

The question is: what is your tolerance for (a) false negatives and (b) false positives? Rephrasing (a): who are we passing on, are they in fact good potential employees, and what qualities do they have that our new hires might not? Rephrasing (b): who have we hired that, despite whiteboard coding proficiency, isn't cutting it? And why? In my experience whiteboard coding sessions feel adversarial, like a trap or a te…

Rephrasing (b): who have we hired that, despite whiteboard coding proficiency, isn't cutting it? And why?

Has someone suggested whiteboard proficiency is sufficient by itself?

The whiteboard is meant to filter out people who suck. "Add a cache to a JavaScript function" is a dumb question for reasons many others have pointed out. Joel's classic article[1] recommends these as examples:

• Write a function that determines if a string starts with an upper-case letter A-Z

• Write a function that determines the area of a circle given the radius

• Add up all the values in an array

Those are all trivial. You should be able to come up with another half-dozen if you sit and think for a bit. The language doesn't matter, and the syntax shouldn't matter (as compared to the semantics).

I hear lots of scare-stories of "great coders who choke on interviews," but I find it very hard to believe any kind of "great coder" can't add up the values in an array. I might ask "how do you find the median value in the array" just to see what they come up with. There isn't a right answer, but there are lots wrong answers.

[1] http://www.joelonsoftware.com/articles/GuerrillaInterviewing...

Re: More whiteboard coding won’t build you a better team

#19

Post by randometc »

danielweber wrote: post #18
randometc wrote: post #13

Earlier quoted context omitted.

The question is: what is your tolerance for (a) false negatives and (b) false positives? Rephrasing (a): who are we passing on, are they in fact good potential employees, and what qualities do they have that our new hires might not? Rephrasing (b): who have we hired that, despite whiteboard coding proficiency, isn't cutting it? And why? In my experience whiteboard coding sessions feel adversarial, like a trap or a te…

Rephrasing (b): who have we hired that, despite whiteboard coding proficiency, isn't cutting it? And why? Has someone suggested whiteboard proficiency is sufficient by itself? The whiteboard is meant to filter out people who suck. "Add a cache to a JavaScript function" is a dumb question for reasons many others have pointed out. Joel's classic article[1] recommends these as examples: • Write a function that determine…

Has someone suggested whiteboard proficiency is sufficient by itself?

Fair point, that is a straw man. I haven't experienced an all-whiteboard interview - there's always been more to it.

The whiteboard is meant to filter out people who suck.

I think that's what some interviewers have missed. They jump straight in at the deep end with difficult algorithmic puzzles, and don't ever do an easy one. I have experienced this.

Re: More whiteboard coding won’t build you a better team

#20

Post by wtetzner »

gordonguthrie wrote: post #6

The key thing is that 'you don't want to hire people to write code'. Code is inventory, code has a cost, code-not-written is what you want (as much as possible). So you need to hire a developer who knows 'how not to code', 'when not to code', how to write as little code as possible (libraries, reuse and designing things that don't take much code, clean, concise, elegant, and well-structured). These sort of developers…

Even better, a developer that can take an existing code base and shrink it.
Post reply on HN