More whiteboard coding won’t build you a better team • Hacker News Board

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

#21

Post by funkaster » Tue, Oct 02, 2012, 4:36 PM UTC

I've been on both sides of the fence: being interviewed and interviewing. The times I've been interviewed I felt (most of the times) that either the person questioning me had no complete understand of what he/she was asking --it could be possible he/she was a junior engineer-- or it was a tricky algorithm question. The thing is that not everyone thinks or plans the same way. Analytical thinking is different for everybody. Most of the time I like to solve problems first either by brute force or the simplest solution and then try to improve it, but the author of the post also got a very good point: "why".

When asked questions without a context, you have no motivation and they seem weird. If you want to know if I know what a b-tree or a hash-table is, or what is database normalization, just ask me to explain you what it is. I also, wouldn't expect a candidate to implement one of those things right out of their head... that's just crazy. I would expect for him to be able to use them or at least how they work. If you need to see what I've done or how I perform against a particular issue your company might be having, code review of already code-reviewed code is a great, great way to test a candidate.

Github profiles are also a good indicator: it shows what you want, want motivates you, it can show real-world code that you have written.

Just talking of your experiences and how you've solved problems is also a good thing.

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

#22

Post by paulgb » Tue, Oct 02, 2012, 4:37 PM UTC

jpdoctor wrote: post #11

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.

Very true.

In one such interview, I was asked for a way to implement Rock Paper Scissors in OOP without using a conditional. I came up with a neat way to do it with modulo operations and array lookups, but that wasn't The Right Way. So I came up with a way to do it with exceptions, but it wasn't The Right Way. Finally I came up with the solution the interviewer had in mind, which used Java's method overloading (my background is not Java).

I'm not sure if I "passed" the interview, but it certainly didn't make me want to.

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

#23

Post by MisterBastahrd » Tue, Oct 02, 2012, 4:38 PM UTC

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…

Google hires the best because they have the capacity to pay the best. If you're hiring a mid-level developer in Texas and can only pay 70K a year, don't be surprised if your candidates have a hard time working out esoteric brain teasers.

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

#24

Post by groby_b » Tue, Oct 02, 2012, 4:39 PM UTC

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…

It is adversarial, because it's a gating mechanism.

Sure, I'll be happy to discuss deep issues with you - after you've shown me that you're proficient in basic CS. It used to be that you could screen that over the phone, but now that you can look up the answers on your phone, that's kind of hard :)

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

#25

Post by danielweber » Tue, Oct 02, 2012, 4:41 PM UTC

randometc wrote: post #19

danielweber wrote: post #18

Earlier quoted context omitted.

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 thi…

They jump straight in at the deep end with difficult algorithmic puzzles, and don't ever do an easy one. I have experienced this

Yeah, I have hard algorithm questions I ask, but I don't open with them, and I know they are hard. I expect them to possibly fill the entire remaining time.

Also, for the hard question, it's not even about getting it "right": the one person I ever had get my hardest question right was flushed by other people in my process, and I've hired many people who never got close. I want to see how they try.

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

#26

Post by bduerst » Tue, Oct 02, 2012, 4:45 PM UTC

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…

Anecdotal, but I interviewed for a position where they gave me a tab deliminated data set, and said, "Show us what you can do with this in X language". I had two days.

It was one of my favorite interviews.

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

#27

Post by bduerst » Tue, Oct 02, 2012, 4:48 PM UTC

groby_b wrote: post #24

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…

It is adversarial, because it's a gating mechanism. Sure, I'll be happy to discuss deep issues with you - after you've shown me that you're proficient in basic CS. It used to be that you could screen that over the phone, but now that you can look up the answers on your phone, that's kind of hard :)

But the question he is raising with the false positives is that it is a gating mechanism for what? The ability to talk shop on a white board?

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

#28

Post by randometc » Tue, Oct 02, 2012, 5:02 PM UTC

groby_b wrote: post #24

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…

It is adversarial, because it's a gating mechanism. Sure, I'll be happy to discuss deep issues with you - after you've shown me that you're proficient in basic CS. It used to be that you could screen that over the phone, but now that you can look up the answers on your phone, that's kind of hard :)

Assuming your whiteboard session is a good test of basic CS proficiency, the real question is "does basic CS proficiency correlate with effectiveness at the job?" - if you're like Google the answer is probably yes, and if so you only have to have tolerance for false negatives. Given enough applicants that's clearly less of a problem than false positives.

My other point is that some companies might find there are other qualities they're looking for that occur in the pool of people they pass on. That's what's really worth looking at, I think - all the while being careful not to mistake "good cultural fit" for "promotes long term monoculture".

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

#29

Post by bmj » Tue, Oct 02, 2012, 5:24 PM UTC

griffindy wrote: post #9

zeteo wrote: post #7

"Advanced whiteboard coding" does have its uses: 1. It checks that you still know the basics of what's required for a CS degree. 2. Quite possibly, it also checks your capacity to (re-)learn some things for preparation. Both of these are good indications of your ability to adapt to a new technical environment.

I agree with the ability to learn part, but do you need the basics for what's required for a CS degree? I say this as someone who does not have a CS degree, but I also don't know that many places working directly with binary trees and linked lists, though I'll admit I may not have found them.

I've been doing software development for over ten years without a CS degree. Yeah, I've never had a problem that linked list solved, but I suspect having a CS degree might have better prepared me to solve certain classes of problems. After 10 years, I have a deep tool chest of patterns (and anti-patterns), but early in the game, having a better algorithmic eye would have certainly been beneficial.

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

#30

Post by dorkrawk » Tue, Oct 02, 2012, 5:27 PM UTC

I've always thought that a good programmer job interview challenge would be to hand the candidate a laptop (preferably with their OS of choice) and have them build something simple but new. For example: "Have you ever built a web scraper in Ruby? No? Ok, Ruby's installed on this computer. Here's a CLI, a text editor, and a browser with Google open, feel free to make use of existing language resources, build me something that pulls some text off of www.example.com"

I think it's good to see how people learn new things and to see if the candidate looks for existing libraries rather than writing everything from scratch. You'd need to be able to give the candidate some time but I think it would be a valuable exercise.