3 ms·

In every single company I've been for the last 15 years, I haven't had any algorithmic problem to solve, most programmer jobs is just making software as quickly

by krzyk 10y ago

In every single company I've been for the last 15 years, I haven't had any algorithmic problem to solve, most programmer jobs is just making software as quickly as possible and fix performance issues only when they appear. I really don't think that every programmer in Amazon or Google is faced with algorithm problems everyday, that's probably localized to some projects that deal with those, not the majority of programmer population. Expecting every programmer to know how to solve given problem on a whiteboard is like expecting every life gourd to know how to do a water escape (because it involves swimming AFTER you solve a problem of tied hands).

JustSomeNobody 10y ago
This gourd could solve it: http://veggietales.wikia.com/wiki/Mr._Lunt http://veggietales.wikia.com/wiki/Mr._Lunt
ryandrake 10y ago
I agree. Most companies SAY they want algorithm experts and API ninjas, and computer science wizards, because it sounds like the right kind of thing to say. But most of the actual work out there is either 1. plumbing some data from one layer in the stack to the other (typical CRUD app) or 2. writing glue code to integrate one vendor's middleware to another vendor's middleware, or 3. fixing bugs in some 10 year old legacy application, or if you're lucky, 4. getting an application to work barely well enough in order to ship it on time. An in-depth knowledge of traversing binary trees is not required for any of this stuff.
- stcredzero 10y ago
  But most of the actual work out there is either 1. plumbing some data from one layer in the stack to the other (typical CRUD app) or 2. writing glue code to integrate one vendor's middleware to another vendor's middleware, or 3. fixing bugs in some 10 year old legacy application, or if you're lucky, 4. getting an application to work barely well enough in order to ship it on time. And most of a lifeguard's job is sitting around blowing a whistle at troublemakers. Does that mean you'd be fine with a lifeguard who only has those two actions in his skillset? Also, as someone who has held a number of jobs that involve your 1 through 4 above: knowing basic algorithms is beneficial to the job. You don't need that knowledge often, but when you do, it has outsized benefits. Also, you wouldn't know that, unless you had that knowledge while doing that job. If you didn't have that knowledge, you wouldn't know how it would have benefited you. The fact that "in-depth knowledge" is applied to "traversing binary trees" makes me sigh and feel uneasy.
  - ryandrake 10y ago
    I'm not sure the lifeguard analogy is apt. There are plenty of programming jobs where algorithm knowledge is helpful but not strictly necessary. You and I might not find ourselves in them but they exist. It's more about testing the range of skills that will actually be applied. To toss in another incomplete analogy: If you're interviewing someone to build you a deck in your backyard don't spend 90% of the interview time asking him how he'd chop down trees for wood and manufacture the nails. You probably also don't need to ask him his opinion on the local building height restrictions or if he knows how to install an attic fan. You want to know that he can build a deck.
    - stcredzero 10y ago
      I'm not sure the lifeguard analogy is apt. There are plenty of programming jobs where algorithm knowledge is helpful but not strictly necessary. I think a lot of the above analogy mismatch and "not strictly necessary"-ness is because an application slowdown is much less severe than a drowning death. But if you account for that difference, it is very apt. If you're interviewing someone to build you a deck in your backyard don't spend 90% of the interview time asking him how he'd chop down trees for wood and manufacture the nails. You probably also don't need to ask him his opinion on the local building height restrictions or if he knows how to install an attic fan. You want to know that he can build a deck. But "how he'd chop down trees for wood and manufacture the nails" isn't apt at all! As a programmer, understanding algorithms is much more like 1st principles knowledge behind understanding building materials. Your contractor needs to know the structural properties of different kinds of wood, the properties of the soil in your backyard, and some basic chemistry/engineering/physics. Otherwise, she might put the wrong materials together and invite galvanic corrosion, or use the wrong materials in the wrong context and invite premature wood rot. You'd want a carpenter to understand wood harvesting, milling, and treatment in how it effects the properties of wood. Could you get by most of the time, just knowing how to saw boards and drive nails with power equipment? Sure. But someone with the right knowledge is going to avoid the unlikely but very costly pitfall and save her customer thousands of dollars otherwise. You want to know that he can build a deck. On time and under budget. She's more likely to do that if she's armed beforehand with certain experience and 1st principles knowledge. All things being equal, the contractors who built decks on time and under budget had good trades instruction or otherwise had the right experience and/or 1st principles knowledge. Also, if you look at the longevity and long term structural integrity of deck projects, you will likely find such a correlation. (Also, it would be a really good idea if your contractor had a knowledge of local building regulations concerning the deck.)
stcredzero 10y ago
I haven't had any algorithmic problem to solve, most programmer jobs is just making software as quickly as possible and fix performance issues only when they appear. I sense a contradiction between the 1st clause and the last clause. Expecting every programmer to know how to solve given problem on a whiteboard is like expecting every life gourd to know how to do a water escape Expecting every programmer to know the basics of recursion and about 10 basic algorithms and the reasons behind their time/space complexity analyses is like expecting every life guard to know what a drowning person looks like (nothing like what they show in movies and TV shows) has the ability to tread water without using arms, and knows how to tow a panicked, struggling swimmer without letting them kick you in the stomach. A programmer who can't explain the three bits of knowledge in my comment above is like a lifeguard who simply knows how to swim and doesn't know what a drowning person looks like. Over 90% of the time, all you have to do is sit in the tower chair and blow your whistle at troublemakers, but in the occasional instance, you will have to know something special, with a higher cost than usual if you don't know.
sjellis 10y ago
I like the analogy of jet fighter pilots vs. airline pilots. Most programmers are metaphorically airline pilots, doing a routine job that is more about following the processes than elite skills, but some people wish that they were doing something more complex than they are.
- stcredzero 10y ago
  And yet, there are still occasions where the airline pilot needs to draw on deeper skills. We know this from many deaths averted by good pilots, and needless deaths resulting from poorly trained pilots. The failed landing of Asiana Airlines at SF and the Air France Airbus that dropped into the ocean are two good examples. Most programmers are metaphorically airline pilots, doing a routine job that is more about following the processes than elite skills, but some people wish that they were doing something more complex than they are. Programmers who think they can only get by with the "routine" skill level are like airline pilots who think it's just fine for them to do the checklists, run the autopilot, and know nothing else. Who would you rather have piloting your plane?

by krzyk 10y ago

JustSomeNobody 10y ago

This gourd could solve it: http://veggietales.wikia.com/wiki/Mr._Lunt http://veggietales.wikia.com/wiki/Mr._Lunt

ryandrake 10y ago

I agree. Most companies SAY they want algorithm experts and API ninjas, and computer science wizards, because it sounds like the right kind of thing to say. But most of the actual work out there is either 1. plumbing some data from one layer in the stack to the other (typical CRUD app) or 2. writing glue code to integrate one vendor's middleware to another vendor's middleware, or 3. fixing bugs in some 10 year old legacy application, or if you're lucky, 4. getting an application to work barely well enough in order to ship it on time. An in-depth knowledge of traversing binary trees is not required for any of this stuff.

stcredzero 10y ago
But most of the actual work out there is either 1. plumbing some data from one layer in the stack to the other (typical CRUD app) or 2. writing glue code to integrate one vendor's middleware to another vendor's middleware, or 3. fixing bugs in some 10 year old legacy application, or if you're lucky, 4. getting an application to work barely well enough in order to ship it on time. And most of a lifeguard's job is sitting around blowing a whistle at troublemakers. Does that mean you'd be fine with a lifeguard who only has those two actions in his skillset? Also, as someone who has held a number of jobs that involve your 1 through 4 above: knowing basic algorithms is beneficial to the job. You don't need that knowledge often, but when you do, it has outsized benefits. Also, you wouldn't know that, unless you had that knowledge while doing that job. If you didn't have that knowledge, you wouldn't know how it would have benefited you. The fact that "in-depth knowledge" is applied to "traversing binary trees" makes me sigh and feel uneasy.
- ryandrake 10y ago
  I'm not sure the lifeguard analogy is apt. There are plenty of programming jobs where algorithm knowledge is helpful but not strictly necessary. You and I might not find ourselves in them but they exist. It's more about testing the range of skills that will actually be applied. To toss in another incomplete analogy: If you're interviewing someone to build you a deck in your backyard don't spend 90% of the interview time asking him how he'd chop down trees for wood and manufacture the nails. You probably also don't need to ask him his opinion on the local building height restrictions or if he knows how to install an attic fan. You want to know that he can build a deck.
  - stcredzero 10y ago
    I'm not sure the lifeguard analogy is apt. There are plenty of programming jobs where algorithm knowledge is helpful but not strictly necessary. I think a lot of the above analogy mismatch and "not strictly necessary"-ness is because an application slowdown is much less severe than a drowning death. But if you account for that difference, it is very apt. If you're interviewing someone to build you a deck in your backyard don't spend 90% of the interview time asking him how he'd chop down trees for wood and manufacture the nails. You probably also don't need to ask him his opinion on the local building height restrictions or if he knows how to install an attic fan. You want to know that he can build a deck. But "how he'd chop down trees for wood and manufacture the nails" isn't apt at all! As a programmer, understanding algorithms is much more like 1st principles knowledge behind understanding building materials. Your contractor needs to know the structural properties of different kinds of wood, the properties of the soil in your backyard, and some basic chemistry/engineering/physics. Otherwise, she might put the wrong materials together and invite galvanic corrosion, or use the wrong materials in the wrong context and invite premature wood rot. You'd want a carpenter to understand wood harvesting, milling, and treatment in how it effects the properties of wood. Could you get by most of the time, just knowing how to saw boards and drive nails with power equipment? Sure. But someone with the right knowledge is going to avoid the unlikely but very costly pitfall and save her customer thousands of dollars otherwise. You want to know that he can build a deck. On time and under budget. She's more likely to do that if she's armed beforehand with certain experience and 1st principles knowledge. All things being equal, the contractors who built decks on time and under budget had good trades instruction or otherwise had the right experience and/or 1st principles knowledge. Also, if you look at the longevity and long term structural integrity of deck projects, you will likely find such a correlation. (Also, it would be a really good idea if your contractor had a knowledge of local building regulations concerning the deck.)

stcredzero 10y ago

I haven't had any algorithmic problem to solve, most programmer jobs is just making software as quickly as possible and fix performance issues only when they appear. I sense a contradiction between the 1st clause and the last clause. Expecting every programmer to know how to solve given problem on a whiteboard is like expecting every life gourd to know how to do a water escape Expecting every programmer to know the basics of recursion and about 10 basic algorithms and the reasons behind their time/space complexity analyses is like expecting every life guard to know what a drowning person looks like (nothing like what they show in movies and TV shows) has the ability to tread water without using arms, and knows how to tow a panicked, struggling swimmer without letting them kick you in the stomach. A programmer who can't explain the three bits of knowledge in my comment above is like a lifeguard who simply knows how to swim and doesn't know what a drowning person looks like. Over 90% of the time, all you have to do is sit in the tower chair and blow your whistle at troublemakers, but in the occasional instance, you will have to know something special, with a higher cost than usual if you don't know.

sjellis 10y ago

I like the analogy of jet fighter pilots vs. airline pilots. Most programmers are metaphorically airline pilots, doing a routine job that is more about following the processes than elite skills, but some people wish that they were doing something more complex than they are.

stcredzero 10y ago
And yet, there are still occasions where the airline pilot needs to draw on deeper skills. We know this from many deaths averted by good pilots, and needless deaths resulting from poorly trained pilots. The failed landing of Asiana Airlines at SF and the Air France Airbus that dropped into the ocean are two good examples. Most programmers are metaphorically airline pilots, doing a routine job that is more about following the processes than elite skills, but some people wish that they were doing something more complex than they are. Programmers who think they can only get by with the "routine" skill level are like airline pilots who think it's just fine for them to do the checklists, run the autopilot, and know nothing else. Who would you rather have piloting your plane?