4 ms·

"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 y

"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.
- plinkplonk 17y ago
  "I knew that I was going to be spending the next hour talking about red-black trees and low level language trivia." I know what you are talking about. Not too long ago, I was "that guy" - the guy whose heart sank at such interviews and couldn't get what the focus on "trivia" was all about. I know how to write software dammit why ask me all these stupid questions about the fine detail of Red Black Tree implementations and language edge cases? "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 had to learn CS from scratch (because I quit working on enterprise sw after 10 years and started working on projects where such knowledge was important), without a formal degree, mentors, or any guidance whatsoever. So in a sense I have traversed the opposite arc from most college educated developers. I first became a "in the trenches" programmer and then get a CS and math education (entirely self taught). I was an "architect" at ThoughtWorks (At TW, "architects" code every day) ar at least they used to when I was there) , working on large enterprise systems, when I stopped doing outsourced enterprise sw and started working on Machine Learning/AI projects and found myself neck deep in hairy math with no clue what was going on. I have sat in 3 hour meetings not comprehending a single sentence because the other guys were speaking "math-y programming" and I knew only "hands on programming". It is a terrible, sinking feeling. Which is all just away of saying, there are projects on which deep algorithmic/data structure knowledge (and other hard things) is important. And if a company's success or failure in such a project depended on finding people with that knowledge they would be foolish to ask "abstract" questions at interviews. Whether this is important enough to be probed in an interview or not depends on what the company is doing. If you are building simple db backed websites you can get by with understanding lists and hashtables. If you are building databases (like rethinkdb) is, then being very thorough the nuances of RB trees, networking, OS internals etc becomes significant. I agree that the interview should test for what the skills the job would need in real life, if that is what you are saying. I was just irritated at the stereotyping of programmers with deep CS knowledge as lacking team work and being too abstract and so on. I know from personal experience how hard that stuff is. And it is orthogonal to "in the trenches " knowledge and experience. You can be very good at both.
cookiecaper 17y ago
Well, I don't mean that competence is 10% of a hire, more that attitude is 90% of competence, especially in our field where things change so quickly. Your hires should be competent to perform the job. Still, the analogue to doctors or lawyers is quite different. Most programming languages are pretty similar and once you get the basic concepts down you don't need to radically modify it to switch from one context to another. Information and manuals about programming languages, troubleshooting, etc., is available plentifully online, and someone with a basic grasp and an attitude of teachibility and eagerness to learn can make a lot of progress very quickly. Things don't work the same way with lawyering or medicine, but probably the most important difference is that someone isn't going to be sent to the jail or the morgue because your programmer wrote a naive implementation of something (generally). I agree with the basic idea of reasonable testing, which is why I said that it "sounds good on paper". It's just that most places don't do it right, so I don't get excited anymore about workplaces that claim to test for competence.

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.

plinkplonk 17y ago
"I knew that I was going to be spending the next hour talking about red-black trees and low level language trivia." I know what you are talking about. Not too long ago, I was "that guy" - the guy whose heart sank at such interviews and couldn't get what the focus on "trivia" was all about. I know how to write software dammit why ask me all these stupid questions about the fine detail of Red Black Tree implementations and language edge cases? "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 had to learn CS from scratch (because I quit working on enterprise sw after 10 years and started working on projects where such knowledge was important), without a formal degree, mentors, or any guidance whatsoever. So in a sense I have traversed the opposite arc from most college educated developers. I first became a "in the trenches" programmer and then get a CS and math education (entirely self taught). I was an "architect" at ThoughtWorks (At TW, "architects" code every day) ar at least they used to when I was there) , working on large enterprise systems, when I stopped doing outsourced enterprise sw and started working on Machine Learning/AI projects and found myself neck deep in hairy math with no clue what was going on. I have sat in 3 hour meetings not comprehending a single sentence because the other guys were speaking "math-y programming" and I knew only "hands on programming". It is a terrible, sinking feeling. Which is all just away of saying, there are projects on which deep algorithmic/data structure knowledge (and other hard things) is important. And if a company's success or failure in such a project depended on finding people with that knowledge they would be foolish to ask "abstract" questions at interviews. Whether this is important enough to be probed in an interview or not depends on what the company is doing. If you are building simple db backed websites you can get by with understanding lists and hashtables. If you are building databases (like rethinkdb) is, then being very thorough the nuances of RB trees, networking, OS internals etc becomes significant. I agree that the interview should test for what the skills the job would need in real life, if that is what you are saying. I was just irritated at the stereotyping of programmers with deep CS knowledge as lacking team work and being too abstract and so on. I know from personal experience how hard that stuff is. And it is orthogonal to "in the trenches " knowledge and experience. You can be very good at both.

cookiecaper 17y ago

Well, I don't mean that competence is 10% of a hire, more that attitude is 90% of competence, especially in our field where things change so quickly. Your hires should be competent to perform the job. Still, the analogue to doctors or lawyers is quite different. Most programming languages are pretty similar and once you get the basic concepts down you don't need to radically modify it to switch from one context to another. Information and manuals about programming languages, troubleshooting, etc., is available plentifully online, and someone with a basic grasp and an attitude of teachibility and eagerness to learn can make a lot of progress very quickly. Things don't work the same way with lawyering or medicine, but probably the most important difference is that someone isn't going to be sent to the jail or the morgue because your programmer wrote a naive implementation of something (generally). I agree with the basic idea of reasonable testing, which is why I said that it "sounds good on paper". It's just that most places don't do it right, so I don't get excited anymore about workplaces that claim to test for competence.