4 ms·

"under pressure and time constraints" Isn't that the situation during a startup and some companies? If someone is not able to use a linked list, how are you g

by volida 17y ago

"under pressure and time constraints" Isn't that the situation during a startup and some companies? If someone is not able to use a linked list, how are you going to trust them think of/implement something new and harder? And I never said mistakes are unacceptable.

rosser 17y ago
First, I never suggested giving every dummy off the street a pass if they blow the technical portion of the interview. You're right: mistakes are acceptable. Given that, you have to base your decision on whether the person is a match for your needs on more than just a coding exercise during an interview. Second, and more importantly, a coding exercise during an interview is long, long way from working in a startup, or working of pretty much any kind -- unless you've somehow managed to find a way to get paid for solving toy problems. I've done both, and both are hard, but in different ways. To use running analogies, working in a startup (in my experience) is a relay: you have a team, each of you is carrying your own respective bit of the endeavor, but the success or failure proposition is net across the team. In an interview, you're running a sprint, and all eyes are on you, and you alone. One feels completely different from the other, because it is. Also, half the times (for a sample size of two) I've been asked to do a code exercise during an interview, the interviewer realized halfway through the exercise that he'd misrepresented the specifications of the widget I was supposed to make. The plural of "anecdote" may not be "data", but I've seen and heard, and can conceive of enough problems with the practice of interview coding exercises that I just can't trust them for anything more than exploring how a candidate approaches programming: the way they think.
- volida 17y ago
  Obviously we agree. The "linked list" is the metaphor here. You always should hire the best person that will respond to the needs of his/her role.

by volida 17y ago

rosser 17y ago

First, I never suggested giving every dummy off the street a pass if they blow the technical portion of the interview. You're right: mistakes are acceptable. Given that, you have to base your decision on whether the person is a match for your needs on more than just a coding exercise during an interview. Second, and more importantly, a coding exercise during an interview is long, long way from working in a startup, or working of pretty much any kind -- unless you've somehow managed to find a way to get paid for solving toy problems. I've done both, and both are hard, but in different ways. To use running analogies, working in a startup (in my experience) is a relay: you have a team, each of you is carrying your own respective bit of the endeavor, but the success or failure proposition is net across the team. In an interview, you're running a sprint, and all eyes are on you, and you alone. One feels completely different from the other, because it is. Also, half the times (for a sample size of two) I've been asked to do a code exercise during an interview, the interviewer realized halfway through the exercise that he'd misrepresented the specifications of the widget I was supposed to make. The plural of "anecdote" may not be "data", but I've seen and heard, and can conceive of enough problems with the practice of interview coding exercises that I just can't trust them for anything more than exploring how a candidate approaches programming: the way they think.

volida 17y ago
Obviously we agree. The "linked list" is the metaphor here. You always should hire the best person that will respond to the needs of his/her role.