3 ms·

I really don't understand where this meme has come from. How else are you supposed to assess a candidate's ability to do the job, if not to pose them a problem

I really don't understand where this meme has come from. How else are you supposed to assess a candidate's ability to do the job, if not to pose them a problem and watch them work?

mathgeek 10y ago
> How else are you supposed to assess a candidate's ability to do the job, if not to pose them a problem and watch them work? Unless the job is responding to problems and being watched while you work, the argument here is that you're not actually assessing anything that's very useful. Most engineers/developers, for example, spend a lot of time thinking about a problem or trying out their ideas (many of which quickly get thrown out). If you do this in most programming interviews, you're going to fail them.
warcher 10y ago
The problem as I see it is the difficulty in posing a problem that's interview-sized and still relevant to their actual workflow. I don't know how much whiteboard algorithm time you spend during your day to day, but for me it's vanishingly small. What is relevant in my day to day is dumb shit like "What do you name things?" "How do you control access to classes internals?" "How do you construct an API?" "How do you communicate your designs to people living outside your head?" Virtually none of which you can get done on a whiteboard with a problem set that you can define in five minutes or so.
jstewartmobile 10y ago
A good start would be talking with them like they were professionals: asking for advice, listening to their answers, debating their answers if you disagree so they have a chance to respond and possibly change your mind. Or, you could just have them jump through hoops and do tricks like trained monkeys. Depends on what you're looking for.
aanm1988 10y ago
It's not a realistic assessment of skills though. You don't write code on a whiteboard for work, you do it in an environment you have setup to let you work most efficiently. You have the option to look up things you can't quite remember, do some research to see if there is anything you missed, take a quick break to clear your head, etc... Plus, too often it devolves into a game of algorithm trivia with the interviewer. Gotta prove how smart* you are. "So what have you been working on?" "Oh I was the lead engineer on our new backend system. Built it on top of X, built a custom foobar because we needed to scale Y functionality blah blah blah" "Oh cool, cool. We actually are looking at building something similar. Well anyway enough of this obviously useless information exchange, here's a question about graph searches". *smart may be substituted for grinding out leetcode questions for weeks beforehand, at the interviewees discretion.

I really don't understand where this meme has come from. How else are you supposed to assess a candidate's ability to do the job, if not to pose them a problem and watch them work?

mathgeek 10y ago

> How else are you supposed to assess a candidate's ability to do the job, if not to pose them a problem and watch them work? Unless the job is responding to problems and being watched while you work, the argument here is that you're not actually assessing anything that's very useful. Most engineers/developers, for example, spend a lot of time thinking about a problem or trying out their ideas (many of which quickly get thrown out). If you do this in most programming interviews, you're going to fail them.

warcher 10y ago

The problem as I see it is the difficulty in posing a problem that's interview-sized and still relevant to their actual workflow. I don't know how much whiteboard algorithm time you spend during your day to day, but for me it's vanishingly small. What is relevant in my day to day is dumb shit like "What do you name things?" "How do you control access to classes internals?" "How do you construct an API?" "How do you communicate your designs to people living outside your head?" Virtually none of which you can get done on a whiteboard with a problem set that you can define in five minutes or so.

jstewartmobile 10y ago

A good start would be talking with them like they were professionals: asking for advice, listening to their answers, debating their answers if you disagree so they have a chance to respond and possibly change your mind. Or, you could just have them jump through hoops and do tricks like trained monkeys. Depends on what you're looking for.

aanm1988 10y ago

It's not a realistic assessment of skills though. You don't write code on a whiteboard for work, you do it in an environment you have setup to let you work most efficiently. You have the option to look up things you can't quite remember, do some research to see if there is anything you missed, take a quick break to clear your head, etc... Plus, too often it devolves into a game of algorithm trivia with the interviewer. Gotta prove how smart* you are. "So what have you been working on?" "Oh I was the lead engineer on our new backend system. Built it on top of X, built a custom foobar because we needed to scale Y functionality blah blah blah" "Oh cool, cool. We actually are looking at building something similar. Well anyway enough of this obviously useless information exchange, here's a question about graph searches". *smart may be substituted for grinding out leetcode questions for weeks beforehand, at the interviewees discretion.