4 ms·

I found this point in particular to be very important: Speaking of the need to ask any candidate to solve technical problems on the whiteboard: The best peopl

I found this point in particular to be very important: Speaking of the need to ask any candidate to solve technical problems on the whiteboard: The best people not only welcome a challenge, they require it. All the great people I know would never work for a company that doesn’t perform a tough, formal interview because they recognize the company will mostly end up with bad employees.

brown9-2 17y ago
This is a great point for the person from the other side of the interview as well. I think some of the jobs I've taken which I later looked on as regrets could have been avoided if I was paying more attention / placing more weight on the poor interview process.
cookiecaper 17y ago
While I agree companies with "tough, formal interview[s]" sound better on paper, after interviewing at many companies who esteem themselves such interviewers, I now believe that it mostly all comes out in the wash. I'm all for vetting technical candidates, but I haven't experienced many places that perform this process intelligently. There's a web shop around here. I had a great interview with the owner, he was excited to hire me, even making overtures about how I was going to have a job in the next couple of weeks, etc. I just needed to do this one little formality, which was a "real-world" code test that was about three-five days of work. This is pretty excessive imo, and the place definitely didn't warrant that kind of effort for the atmosphere or the pay, so I gave up on it. There's another company around here that makes niche software. The first step of interviewing there is a written test more than thirty pages long, covering C, C++, Java, and C#. The only people you see the whole time are the secretaries, never meet anyone from HR or IT or anything else. After the test, if you get called back, there are several interviews before a final hire. The problem isn't that they're attempting to vet for competency, it's that the ways in which they vet are silly and arrogant. They think that theirs is the only company out there, that we should feel so privileged to get a job there that we're willing to dedicate weeks to their "quality control" measures. In my opinion, companies should focus on the "smart and gets things done" prescribed by Joel, not thirty pages of trivia about Cs and Java. Such tests generally test memorization abilities and not practical thinking abilities; one can sit in class and memorize syntax and data structure implementations in hundreds of programming languages, but still write crappy code in the real world. They should also realize that most of these guys who are walking CS textbooks are completely dysfunctional socially. I don't mean that these people are awkward or have bad hygiene or any thing like that, I mean that they can't work together with the other engineers on their team, they're focused on proving that their solution is right, and generally just lead to lots of in-fighting and drama. They think that their intelligence or above-average competence is a license to ignore decorum and be cruelly rude and blunt to those around them. We see this attitude in open-source a lot; how much worse is it when the mailing list is private? Honestly I think the key to a good hire is getting to know the candidate. Attitude is 90%. One should also control for competence, but should be reasonable about it. Again, Joel's couplet "smart and gets things done" is a great motto for the technical recruiter.
- plinkplonk 17y ago
  "Attitude is 90%." you wouldn't accept "attitude being 90%" of a doctor's competence. A lawyer with 90 % attitude and 10 % competence will lose your case for you. Why should programmers get away with "attitude"? There is no excuse for not being able to answer basic data structure questions if you call yourself a programmer. The fact that some Google interviewers layer on arrogance and excess doesn't obviate the basic idea. "They should also realize that most of these guys who are walking CS textbooks are completely dysfunctional socially. mean that they can't work together with the other engineers on their team, they're focused on proving that their solution is right, and generally just lead to lots of in-fighting and drama. They think that their intelligence or above-average competence is a license to ignore decorum and be cruelly rude and blunt to those around them." Stereotype much? I don't have any kind of CS degree, but I have met and worked with many people with MS and PhD degrees in CS, who knew theri datastructures and algorithms cold, and the ratio of good folk to dumbasses is if anything greater than among than the population of "developers" who wrote a welcome web page in PHP and think algorithms are unimportant. (see? I just used your rhetorical trick in the opposite direction. Making weak arguments based on anecdotes is easy) These guys are working on an algorithms/data structure heavy project. "90% attitude" is a guaranteed fail.
  - dustingetz 17y ago
    i think your parent means that attitude highly correlates competence, and is easier to evaluate.
  - roc 17y ago
    Most people complaining about formal interview 'tests' are really complaining about the ones loaded with trivia and minutia; classic 'gotcha' testing. And most people defending them pretend like the trivia and minutia never happen. As with anything else, I think a formal development test or question is something that can be done well or done poorly. You just can't generalize the applicability or usefulness of something practiced by a million different people in a million different ways.
  - enjo 17y ago
    What do you consider 'basic data structure questions'? That always seems the rub, and it always seems to vary with the relative age of the person asking the questions. I haven't interviewed in quite awhile. The last time I did, every time I saw a relatively young group in the conference room my heart just sank. I knew that I was going to be spending the next hour talking about red-black trees and low level language trivia. There has been a point in my life where I knew the implementation details for various sorting algorithms and exotic data structures. That was called 'college'. More than a decade into my career, I simply don't remember most of it. I've been coding at a senior-level (meaning, primary designer and implementation) for about 8 years. In that time I've only had to build a data-structure of any complexity once. It was the internal structure for a word processor (Quickword). Everything else has been deferred to standard libraries of the various languages I've worked in. It seems to me that we should be trying to identify engineers who can think at the abstract level great software requires. Identifying that is fantastically difficult, however. To the point that I'm not sure if I know how to do it even today. I do tend to ask more design related questions (not logic puzzles). I've found that 10-15 minutes of talking about a specific problem tell me everything I need to know about a candidate.

brown9-2 17y ago

This is a great point for the person from the other side of the interview as well. I think some of the jobs I've taken which I later looked on as regrets could have been avoided if I was paying more attention / placing more weight on the poor interview process.

cookiecaper 17y ago

While I agree companies with "tough, formal interview[s]" sound better on paper, after interviewing at many companies who esteem themselves such interviewers, I now believe that it mostly all comes out in the wash. I'm all for vetting technical candidates, but I haven't experienced many places that perform this process intelligently. There's a web shop around here. I had a great interview with the owner, he was excited to hire me, even making overtures about how I was going to have a job in the next couple of weeks, etc. I just needed to do this one little formality, which was a "real-world" code test that was about three-five days of work. This is pretty excessive imo, and the place definitely didn't warrant that kind of effort for the atmosphere or the pay, so I gave up on it. There's another company around here that makes niche software. The first step of interviewing there is a written test more than thirty pages long, covering C, C++, Java, and C#. The only people you see the whole time are the secretaries, never meet anyone from HR or IT or anything else. After the test, if you get called back, there are several interviews before a final hire. The problem isn't that they're attempting to vet for competency, it's that the ways in which they vet are silly and arrogant. They think that theirs is the only company out there, that we should feel so privileged to get a job there that we're willing to dedicate weeks to their "quality control" measures. In my opinion, companies should focus on the "smart and gets things done" prescribed by Joel, not thirty pages of trivia about Cs and Java. Such tests generally test memorization abilities and not practical thinking abilities; one can sit in class and memorize syntax and data structure implementations in hundreds of programming languages, but still write crappy code in the real world. They should also realize that most of these guys who are walking CS textbooks are completely dysfunctional socially. I don't mean that these people are awkward or have bad hygiene or any thing like that, I mean that they can't work together with the other engineers on their team, they're focused on proving that their solution is right, and generally just lead to lots of in-fighting and drama. They think that their intelligence or above-average competence is a license to ignore decorum and be cruelly rude and blunt to those around them. We see this attitude in open-source a lot; how much worse is it when the mailing list is private? Honestly I think the key to a good hire is getting to know the candidate. Attitude is 90%. One should also control for competence, but should be reasonable about it. Again, Joel's couplet "smart and gets things done" is a great motto for the technical recruiter.

plinkplonk 17y ago
"Attitude is 90%." you wouldn't accept "attitude being 90%" of a doctor's competence. A lawyer with 90 % attitude and 10 % competence will lose your case for you. Why should programmers get away with "attitude"? There is no excuse for not being able to answer basic data structure questions if you call yourself a programmer. The fact that some Google interviewers layer on arrogance and excess doesn't obviate the basic idea. "They should also realize that most of these guys who are walking CS textbooks are completely dysfunctional socially. mean that they can't work together with the other engineers on their team, they're focused on proving that their solution is right, and generally just lead to lots of in-fighting and drama. They think that their intelligence or above-average competence is a license to ignore decorum and be cruelly rude and blunt to those around them." Stereotype much? I don't have any kind of CS degree, but I have met and worked with many people with MS and PhD degrees in CS, who knew theri datastructures and algorithms cold, and the ratio of good folk to dumbasses is if anything greater than among than the population of "developers" who wrote a welcome web page in PHP and think algorithms are unimportant. (see? I just used your rhetorical trick in the opposite direction. Making weak arguments based on anecdotes is easy) These guys are working on an algorithms/data structure heavy project. "90% attitude" is a guaranteed fail.
- dustingetz 17y ago
  i think your parent means that attitude highly correlates competence, and is easier to evaluate.
- roc 17y ago
  Most people complaining about formal interview 'tests' are really complaining about the ones loaded with trivia and minutia; classic 'gotcha' testing. And most people defending them pretend like the trivia and minutia never happen. As with anything else, I think a formal development test or question is something that can be done well or done poorly. You just can't generalize the applicability or usefulness of something practiced by a million different people in a million different ways.
- enjo 17y ago
  What do you consider 'basic data structure questions'? That always seems the rub, and it always seems to vary with the relative age of the person asking the questions. I haven't interviewed in quite awhile. The last time I did, every time I saw a relatively young group in the conference room my heart just sank. I knew that I was going to be spending the next hour talking about red-black trees and low level language trivia. There has been a point in my life where I knew the implementation details for various sorting algorithms and exotic data structures. That was called 'college'. More than a decade into my career, I simply don't remember most of it. I've been coding at a senior-level (meaning, primary designer and implementation) for about 8 years. In that time I've only had to build a data-structure of any complexity once. It was the internal structure for a word processor (Quickword). Everything else has been deferred to standard libraries of the various languages I've worked in. It seems to me that we should be trying to identify engineers who can think at the abstract level great software requires. Identifying that is fantastically difficult, however. To the point that I'm not sure if I know how to do it even today. I do tend to ask more design related questions (not logic puzzles). I've found that 10-15 minutes of talking about a specific problem tell me everything I need to know about a candidate.