5 ms·

Anecdotally I have come across developers that match the description the OP gives of himself. They read a lot of papers, they know a lot about the inner working

by nixy 13y ago

Anecdotally I have come across developers that match the description the OP gives of himself. They read a lot of papers, they know a lot about the inner workings of many common and obscure programming languages. Many know and love development process theory and they contribute to open source projects. Here is the but: when push comes to shove, they can't deliver to production. I've seen many smart coders falling short in real-life scenarios, where they refuse to take the shortcuts and make the trade-offs that most high-paced production projects need to deliver on time. And on the other side of the fence I have seen mediocre programmers deliver quality apps on schedule by allowing themselves to take what to a purist would look like shortcuts. More often than not, companies prefer the latter one. Perhaps many employers have a process of surfacing stuff like that during the interview phase? Every time I interview someone to fill a position working with developing and delivering applications written in X, and all they want to do is tell me about the awesome type system in Y, alarms start to sound in my head.

mynameishere 13y ago
Tend to agree (though it's impossible to say about any particular person.) Mentioning TAOCP and SICP at an interview (as he did in the post) would raise some alarms with me. They're not useful books in most jobs, and bringing them up just makes you look like the kind of person who doesn't understand that.
- jarrett 13y ago
  I see it from another perspective: Mentioning that kind of stuff suggests an appreciation for the finer points of the trade. No, I don't want to work with people who are all theory and no practice. But I do want to work with people who treat coding as more than "copy and paste from Stack Overflow until my boss tells me I'm done."
- eli_gottlieb 13y ago
  Yes, surely we wizards have no desire to leave our big dinners and comfy armchairs at the Unseen University to do any actual magic.
- krmboya 13y ago
  Steve Yegge calls it "The Awful Place Where People Make Money With Software" http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html http://steve-yegge.blogspot.com/2007/06/rich-programmer-food...
  - papsosouid 13y ago
    Wow, I forgot how horrible he was. How can someone spend that many words just to cough up a few awful strawmen, and then not even bother to knock them down?
- nilkn 13y ago
  > They're not useful books in most jobs, and bringing them up just makes you look like the kind of person who doesn't understand that. That seems like a rather silly conclusion to draw. I actually think these sorts of hasty conclusions are part of the problem with the hiring process in the industry.
- papsosouid 13y ago
  >They're not useful books in most jobs Yes, I would certainly question their relevance to most jobs. But we're not talking about most jobs, we're talking specifically about software development jobs. Where they are incredibly useful.
arghbleargh 13y ago
It's clear that the author is very motivated and probably pretty smart, but I wonder if there might be some gaps in his knowledge foundation. I was surprised for example that he was learning about information theory, and yet he had trouble analyzing the computational complexity of a function that he coded.
- boyter 13y ago
  Not sure if that's really relevant. Unless you are applying for a job where time is money stock trading or some such I don't see how knowing a method you are writing is O(log N) rather then O(N2) is useful. Its something to keep in mind sure, but I would rather have the slower method integrated into the code base faster. Yes performance is a feature but realistically you can get away with some fairly awfully performing code for a long time in most situations. I remember a conversation a while ago where people we asking if you could have a language that offered X increase in performance over C for X increase in processing time what value of X would you pick? In most cases people are willing to trade a lot of performance for a lot of productivity.
  - gizmo686 13y ago
    Knowing the time complexity a given function you write is generally not important. However, the skill to analyze the complexity is an important one to have, because when performance issues to come up, it is often a very powerful tool to have.
    - boyter 13y ago
      Agreed. However it would probably be better to show someone some code with a loop in a loop and ask them why it could potentially be a problem. If they can tell you in Big O notation why its bad for large inputs then great, but so long as they can tell you why that's what really matters.
      - jtheory 13y ago
        Right -- Big O notation is a useful formalization of a thinking process that in practice usually includes more information. That is -- anytime you write a loop, you'd better think about what's inside it (and how long those things will take), and -- given the amount of data you might be sending through that loop -- if that's a problem or not. I want someone to notice that they're making a remote call in a loop when it could be batched, cached, etc.. I don't want them to spend 2 days optimizing an algorithm tinkering with a bit of text that yes, is inefficient, but in practice is only going to take a few milliseconds anyway and isn't a hotspot.
nilkn 13y ago
I actually don't think any of this is relevant to the OP's situation, as by his own admission his interviews never progressed to any sort of production-level problems. He was just given algorithmic puzzles to solve. It sounds to me like the opposite of what you're saying: he's good at delivering to production, but he's not good at pet interview questions.

by nixy 13y ago

mynameishere 13y ago

Tend to agree (though it's impossible to say about any particular person.) Mentioning TAOCP and SICP at an interview (as he did in the post) would raise some alarms with me. They're not useful books in most jobs, and bringing them up just makes you look like the kind of person who doesn't understand that.

jarrett 13y ago
I see it from another perspective: Mentioning that kind of stuff suggests an appreciation for the finer points of the trade. No, I don't want to work with people who are all theory and no practice. But I do want to work with people who treat coding as more than "copy and paste from Stack Overflow until my boss tells me I'm done."
eli_gottlieb 13y ago
Yes, surely we wizards have no desire to leave our big dinners and comfy armchairs at the Unseen University to do any actual magic.
krmboya 13y ago
Steve Yegge calls it "The Awful Place Where People Make Money With Software" http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html http://steve-yegge.blogspot.com/2007/06/rich-programmer-food...
- papsosouid 13y ago
  Wow, I forgot how horrible he was. How can someone spend that many words just to cough up a few awful strawmen, and then not even bother to knock them down?
nilkn 13y ago
> They're not useful books in most jobs, and bringing them up just makes you look like the kind of person who doesn't understand that. That seems like a rather silly conclusion to draw. I actually think these sorts of hasty conclusions are part of the problem with the hiring process in the industry.
papsosouid 13y ago
>They're not useful books in most jobs Yes, I would certainly question their relevance to most jobs. But we're not talking about most jobs, we're talking specifically about software development jobs. Where they are incredibly useful.

arghbleargh 13y ago

It's clear that the author is very motivated and probably pretty smart, but I wonder if there might be some gaps in his knowledge foundation. I was surprised for example that he was learning about information theory, and yet he had trouble analyzing the computational complexity of a function that he coded.

boyter 13y ago
Not sure if that's really relevant. Unless you are applying for a job where time is money stock trading or some such I don't see how knowing a method you are writing is O(log N) rather then O(N2) is useful. Its something to keep in mind sure, but I would rather have the slower method integrated into the code base faster. Yes performance is a feature but realistically you can get away with some fairly awfully performing code for a long time in most situations. I remember a conversation a while ago where people we asking if you could have a language that offered X increase in performance over C for X increase in processing time what value of X would you pick? In most cases people are willing to trade a lot of performance for a lot of productivity.
- gizmo686 13y ago
  Knowing the time complexity a given function you write is generally not important. However, the skill to analyze the complexity is an important one to have, because when performance issues to come up, it is often a very powerful tool to have.
  - boyter 13y ago
    Agreed. However it would probably be better to show someone some code with a loop in a loop and ask them why it could potentially be a problem. If they can tell you in Big O notation why its bad for large inputs then great, but so long as they can tell you why that's what really matters.
    - jtheory 13y ago
      Right -- Big O notation is a useful formalization of a thinking process that in practice usually includes more information. That is -- anytime you write a loop, you'd better think about what's inside it (and how long those things will take), and -- given the amount of data you might be sending through that loop -- if that's a problem or not. I want someone to notice that they're making a remote call in a loop when it could be batched, cached, etc.. I don't want them to spend 2 days optimizing an algorithm tinkering with a bit of text that yes, is inefficient, but in practice is only going to take a few milliseconds anyway and isn't a hotspot.

nilkn 13y ago

I actually don't think any of this is relevant to the OP's situation, as by his own admission his interviews never progressed to any sort of production-level problems. He was just given algorithmic puzzles to solve. It sounds to me like the opposite of what you're saying: he's good at delivering to production, but he's not good at pet interview questions.