6 ms·

"Being a great business web developer and being a great algorithm developer are not mutually exclusive, but they are also not interdependent. The type of develo

by timr 13y ago

"Being a great business web developer and being a great algorithm developer are not mutually exclusive, but they are also not interdependent. The type of developer that would perform well at this kind of challenge is potentially a recent graduate, fresh from an algorithms class or one that is more focused on micro-optimizations than the big picture." Oh, good grief. Being able to answer basic algorithmic questions in an interview isn't a high bar, folks. It's not as if a basic tree-traversal question is going to trip up everyone but Don Knuth. The biggest danger you have as an interviewer is allowing a Stealth Incompetent on your team. These folks all have Github profiles, points on Stackoverflow, fancy blogs, webpages, etc. They might even have nice-looking, public-facing projects. You can even argue that these people Get Things Done (for some value of "things"). But they're still bad hires. Stealth Incompetent programmers are great at using other people's code. They can install gems, download jQuery libraries, and stick them all together. They can make websites with Rails or Django or some other framework, and know enough to be able to piece together functional "products" from parts. All fine. But unlike actual engineers, Stealth Incompetents fall on their face the first time you ask them to do anything that requires taste or independent thought. They're the people who will introduce a horrible dependency on a bad gem, or architect a solution that takes quadratic time, when they could have trivially done better with a tiny bit of thought. Algorithmic questions are designed to catch incompetent people before they can infiltrate your team. The "relevancy" of the questions to the day-to-day work is immaterial.

mamcx 13y ago
Why limit a "Stealth Incompetents" to one that is a "web developer"? A person recently graduate from the U. Perfect scores in algorithms and that stuff. Now, is in a company. That make web things. Don't know databases well (if any). Don't know JS. Don't know html5. Don't know CSS3. Don't know django, or ruby, or whatever. But know BIg(O)! Know how do a Black tree!! And that is almost useless in his job! You know what is that? A incompetent. Competence is the match of skills to the tasks. You will say "A person that know algorithmic stuff can learn web development easy!" (I will say: Why think a web developer can't learn how build a algorithms?) Real-life disagree. People are not equally good across the full spectrum of skills. Thinking that "web development" is trivial in contrast with "real engineering" is wrong. Both are hard. Requiere different skills and mind-sets.
- timr 13y ago
  I have been doing this a long time, and I have never met someone who knows computer science who has had any difficulty picking up a web development framework. This stuff isn't rocket science.
  - klibertp 13y ago
    Anecdotal: just last week a CS graduate at my work produced Python code so horrible, that our tech lead refused to comment on it. Have you heard about storing an app's - no, an app part's - settings in a __builtin__ module? And that's a tip of an iceberg in this case :) Well, being a programmer I am able to answer both simple and a bit more complicated CS questions, although I worked hard on my own to be able to as I have no CS degree. The reverse is not true - the CS graduates cannot produce maintainable code. At least that was the case in those few cases I witnessed, so of course it's not (probably) a rule, but it certainly happens.
    - mamcx 13y ago
      This. A "simple" thing like the kind of language you used to learn first have a huge impact in how you code or solve problems. And if, for example, people learn first C, then try to workaround the limitations of it... in python. I learn first foxpro. And my personal experience is that it give me a huge boost in database/data manipulation than the regular developer. To this day (I do integrations between several ERPs made with different languages and databases) the system that I have meet with people with strong C-like and algorithmic stuff are qualitative worse, by a LOT (take in account, is not normal to meet GREAT GREAT developers, so YMMV), that people that start with DBase languages (yes, DBase/Fox was HUGE in my country ;)). Is like this. If a person that learn by the CS path have a problem, inside his C/C++/Java:= Amazing. But when the same problem is inside a database engine :=Not amazing. Is weird! Some folks have tell me I'm a great developer (I know I'm not. I'm very average) because I know SQL! I could figure how solve stuff with Sql/Sql languages naturally, but then... I'm inside C/C++/Java and I lost if need to do a black tree...
  - nostrademons 13y ago
shubb 13y ago
Nice counterpoint, but you are making a some assertions here that don't seem to follow - So you say there are developers who are good at putting lego bricks together to solve business problems, but introduce bad, unmaintainable code because they are bad as engineers. You say algorithms questions are a good way to identify them. To me, algorithms questions show that you studied CS in an academic setting, and listened in class. People who introduce bad code do so because: * They 'don't have time to do it right', the root of this being that they lack the confidence or judgment to say a task will take longer. * They lack experience maintaining code, or haven't learned the skills to write maintainable code. This happens wen people have mostly worked alone, and can be rectified by working closely and under someone good who reviews their output for a while. CS school does not teach this. * They 'have not heard of' things that 'should be' common knowledge, e.g. unit testing. Fresh graduates often lack 'common knowledge', as do people who worked a long time in a role that just used some specific, older stack. With all these problems, the way to fix them is to properly monitor and understand people on a team, but also they must have the humility to take advice. I'm guilty of identifying too much with my code sometimes, but we've all seen people who get very very defensive. Look, I'm all for discriminating against people who didn't study CS. It keeps my wages up right. But if you are trying to solve this problem you describe, surely identifying the actual cause of what is bad about these candidates is a better idea?
- timr 13y ago
  "People who introduce bad code do so because....they 'don't have time to do it right'....they lack experience maintaining code, or haven't learned the skills to write maintainable code....they 'have not heard of' things that 'should be' common knowledge" Those are all things that happen. But you're missing the most dangerous one of all: programmers who just don't understand how computers work. It's a surprisingly common problem, and it's a problem that algorithmic questions are especially good at identifying quickly. Hire these people at your peril, because while they are fine for simple tasks, they generally have no idea why their code is fast or slow, have no idea why their programs eat memory like a hog, and no idea how to begin to break down a difficult problem in a way that a computer might be able to handle efficiently. Give them a hard problem, and you might get something good....or you might get total garbage. It's programmer roulette. Programmers who don't understand computers are terrifyingly bad hires, because they can do the most damage before you catch them.
zainny 13y ago
I would argue that, say, a recent graduate who can absolutely nail algorithmic questions would be the most likely to screw up on the big ticket items that matter (infrastructure, taste, independent thought) precisely because they have zero real world experience.
- thedufer 13y ago
  And you don't immediately give a recent grad a large project with no oversight. You give them time to learn that stuff, and they'll pick it up with experience. But someone who demonstrably cant understand how computers work? That's who you need to avoid.
  - scuba7183 13y ago
    Exactly, there's a reason the title 'Junior Developer' exists
- timr 13y ago
  "a recent graduate who can absolutely nail algorithmic questions would be the most likely to screw up on the big ticket items that matter" Why do people keep implying that only new grads understand algorithms as if it's some kind of fact? In my experience, new grads don't tend to know algorithms any better than they know anything else. Good engineers keep learning about algorithms because the knowledge is timeless.
  - zainny 13y ago
    Ridiculous. Good engineers solve engineering problems. The huge number of successful engineers out there in the world solving problems without remembering their CS course notes tells you everything you need to know about how important much of the algorithmic subject matter is.
    - timr 13y ago
      Uh huh. I can fix my car without knowing metallurgy and fluid dynamics, but you wouldn't want me building you an engine. Just because people are getting by doing the technical equivalent of changing sparkplugs doesn't mean that I want to hire them to do something more difficult.

by timr 13y ago

mamcx 13y ago

Why limit a "Stealth Incompetents" to one that is a "web developer"? A person recently graduate from the U. Perfect scores in algorithms and that stuff. Now, is in a company. That make web things. Don't know databases well (if any). Don't know JS. Don't know html5. Don't know CSS3. Don't know django, or ruby, or whatever. But know BIg(O)! Know how do a Black tree!! And that is almost useless in his job! You know what is that? A incompetent. Competence is the match of skills to the tasks. You will say "A person that know algorithmic stuff can learn web development easy!" (I will say: Why think a web developer can't learn how build a algorithms?) Real-life disagree. People are not equally good across the full spectrum of skills. Thinking that "web development" is trivial in contrast with "real engineering" is wrong. Both are hard. Requiere different skills and mind-sets.

timr 13y ago
I have been doing this a long time, and I have never met someone who knows computer science who has had any difficulty picking up a web development framework. This stuff isn't rocket science.
- klibertp 13y ago
  Anecdotal: just last week a CS graduate at my work produced Python code so horrible, that our tech lead refused to comment on it. Have you heard about storing an app's - no, an app part's - settings in a __builtin__ module? And that's a tip of an iceberg in this case :) Well, being a programmer I am able to answer both simple and a bit more complicated CS questions, although I worked hard on my own to be able to as I have no CS degree. The reverse is not true - the CS graduates cannot produce maintainable code. At least that was the case in those few cases I witnessed, so of course it's not (probably) a rule, but it certainly happens.
  - mamcx 13y ago
    This. A "simple" thing like the kind of language you used to learn first have a huge impact in how you code or solve problems. And if, for example, people learn first C, then try to workaround the limitations of it... in python. I learn first foxpro. And my personal experience is that it give me a huge boost in database/data manipulation than the regular developer. To this day (I do integrations between several ERPs made with different languages and databases) the system that I have meet with people with strong C-like and algorithmic stuff are qualitative worse, by a LOT (take in account, is not normal to meet GREAT GREAT developers, so YMMV), that people that start with DBase languages (yes, DBase/Fox was HUGE in my country ;)). Is like this. If a person that learn by the CS path have a problem, inside his C/C++/Java:= Amazing. But when the same problem is inside a database engine :=Not amazing. Is weird! Some folks have tell me I'm a great developer (I know I'm not. I'm very average) because I know SQL! I could figure how solve stuff with Sql/Sql languages naturally, but then... I'm inside C/C++/Java and I lost if need to do a black tree...
- nostrademons 13y ago

shubb 13y ago

Nice counterpoint, but you are making a some assertions here that don't seem to follow - So you say there are developers who are good at putting lego bricks together to solve business problems, but introduce bad, unmaintainable code because they are bad as engineers. You say algorithms questions are a good way to identify them. To me, algorithms questions show that you studied CS in an academic setting, and listened in class. People who introduce bad code do so because: * They 'don't have time to do it right', the root of this being that they lack the confidence or judgment to say a task will take longer. * They lack experience maintaining code, or haven't learned the skills to write maintainable code. This happens wen people have mostly worked alone, and can be rectified by working closely and under someone good who reviews their output for a while. CS school does not teach this. * They 'have not heard of' things that 'should be' common knowledge, e.g. unit testing. Fresh graduates often lack 'common knowledge', as do people who worked a long time in a role that just used some specific, older stack. With all these problems, the way to fix them is to properly monitor and understand people on a team, but also they must have the humility to take advice. I'm guilty of identifying too much with my code sometimes, but we've all seen people who get very very defensive. Look, I'm all for discriminating against people who didn't study CS. It keeps my wages up right. But if you are trying to solve this problem you describe, surely identifying the actual cause of what is bad about these candidates is a better idea?

timr 13y ago
"People who introduce bad code do so because....they 'don't have time to do it right'....they lack experience maintaining code, or haven't learned the skills to write maintainable code....they 'have not heard of' things that 'should be' common knowledge" Those are all things that happen. But you're missing the most dangerous one of all: programmers who just don't understand how computers work. It's a surprisingly common problem, and it's a problem that algorithmic questions are especially good at identifying quickly. Hire these people at your peril, because while they are fine for simple tasks, they generally have no idea why their code is fast or slow, have no idea why their programs eat memory like a hog, and no idea how to begin to break down a difficult problem in a way that a computer might be able to handle efficiently. Give them a hard problem, and you might get something good....or you might get total garbage. It's programmer roulette. Programmers who don't understand computers are terrifyingly bad hires, because they can do the most damage before you catch them.

zainny 13y ago

I would argue that, say, a recent graduate who can absolutely nail algorithmic questions would be the most likely to screw up on the big ticket items that matter (infrastructure, taste, independent thought) precisely because they have zero real world experience.

thedufer 13y ago
And you don't immediately give a recent grad a large project with no oversight. You give them time to learn that stuff, and they'll pick it up with experience. But someone who demonstrably cant understand how computers work? That's who you need to avoid.
- scuba7183 13y ago
  Exactly, there's a reason the title 'Junior Developer' exists
timr 13y ago
"a recent graduate who can absolutely nail algorithmic questions would be the most likely to screw up on the big ticket items that matter" Why do people keep implying that only new grads understand algorithms as if it's some kind of fact? In my experience, new grads don't tend to know algorithms any better than they know anything else. Good engineers keep learning about algorithms because the knowledge is timeless.
- zainny 13y ago
  Ridiculous. Good engineers solve engineering problems. The huge number of successful engineers out there in the world solving problems without remembering their CS course notes tells you everything you need to know about how important much of the algorithmic subject matter is.
  - timr 13y ago
    Uh huh. I can fix my car without knowing metallurgy and fluid dynamics, but you wouldn't want me building you an engine. Just because people are getting by doing the technical equivalent of changing sparkplugs doesn't mean that I want to hire them to do something more difficult.