5 ms·

tl;dr - Ship something, THEN look for a job. In the real world, your age is a handicap, no matter what people say. Look for differentiators. A great one is the

tl;dr - Ship something, THEN look for a job. In the real world, your age is a handicap, no matter what people say. Look for differentiators. A great one is the ability to point to something reasonably complicated that you built from scratch and shipped. Very few programmers can do that, and the ones that can are a class above in the eyes of many employers. One thing you have going for you is actual life experience that a fresh college grad can't possibly have. I'd try to figure out a way to emphasize that in the interview process. Certainly it's a better strategy than trying to hide your age. I earnestly recommend going WAY, WAY past whatever you're learning in class, and becoming a subject matter expert in whatever you like working on most. If it's Java, read the entire JVM spec, for instance. Many employers will test primarily for raw problem-solving ability and general CS knowledge in interviews, but I find that intimate, detailed knowledge of one or two areas can also be a powerful differentiator. Of course, make sure you can actually code. The only way to do that is to code a lot. Remember it's possible to know a lot, and even be able to explain a lot of technological concepts, and still not be able to code worth a damn. Don't be that guy. If you ship something substantial, you're going to have no choice but to do a good deal of coding, and enough server admin / networking / etc work to get an idea of how everything fits together, and a taste of the sorts of compromises one makes in actually getting something out the door. I suffer from a different, though similar, disadvantage in the interview process: being black (and dressing, acting, talking like it unabashedly). I've learned to live with reduced initial expectations over the course of my educational and professional career (not interested in a debate on this; I have dozens of unambiguous life experiences to confirm). The upside is that people are primed to be surprised by what you can do. Try to view that as an advantage.

hypnocode 14y ago
Great points! It comes down to how deep you want to go, too. Programmers are still finding jobs, and it seems like our market is better than most hiring markets, at least in the United States. So if you just want a job programming: they're out there. If you want to be a real hacker, though, (Why else would you be here?) you need to be a little crazy, and obsess over the deep details of your specialty.
patio11 14y ago
Knowing the entire JVM spec is frequently less useful than being able to code a for loop whose contents do some domain specific thing that a 22 year old ninjedi will, with diligent study, understand in ten more years.
- eru 14y ago
  You mean, be able to come up with in ten years, or understand in ten years? The former is good. But in case of the latter, I wouldn't want to touch your code with a ten foot pole. (Even complicated Haskell type trickery, or, say, mathematical optimization algorithms shouldn't take longer than a few weeks to explain.)
  - loumf 14y ago
    "domain specific" means something like, your code implements the thing you spent the last 10 years becoming an expert on, which you hopefully understand to such a degree that expert coding will be no help in trying to replicate it.
    - eru 14y ago
      Yes. That's why I mentioned not only type trickery but the one domain specific example where I can claim to be an expert in (mathematical optimization). I guess, the original ten years was hyperbole?
      - sethev 14y ago
        I think you're missing the point completely. Patrick's comment wasn't about a specific for loop and how hard it is to understand. Knowing what types of problems people have and how to write code to solve them is much harder than learning the JVM spec and much more valuable. How long did it take you to become an expert in mathematical optimization, for example? I doubt very much that that's something you picked up in a few weeks.
        14y ago
abc_lisper 14y ago
Don't read the entire VM spec. This thinking of knowing something inside out helps you how to use it is bunk. You don't have to know the how the rules of chess came into being to play chess. Or you could go that way, and do it as the parent says, and end up like me, somewhat dazed and confused a decade later. Just because you invented radio does not mean the programming you put on it is the best. Realize that programming(computer) is a skill that most can achieve only through rigorous grind. There, I saved a few years of frustration to you. Knowledge is power. Amen.
- djtriptych 14y ago
  I have to disagree strongly here. I do believe understanding something inside and out help you use it, and more importantly helps you invent new solutions, but I realize mine may be a minority opinion. Then again, this is HACKER news and what I've described is pretty damn close to the core hacker ethic. The two languages I call myself an expert at are Python and Javascript, I can say confidently that I wouldn't call myself an expert at the former without a damn good understanding of the entire language, data model, standard lib, and standard CPython implemention, nor the other without at least a decent grasp of the ECMA-262 spec, the knowledge of which comes into play more often than one who hasn't read it might guess. Your chess analogy doesn't really make any sense, sorry. A better one is to understand how a car is built before you drive it. I think that might just make for better drivers. Hopefully, the OP and those reading the discussion take away that you shouldn't stop at proficiency. Strive to know your stuff down to the bits. Don't become complacent; as I've read elsewhere here, Feel the incline, and walk uphill.
  - abc_lisper 14y ago
    > A better one is to understand how a car is built before you drive it. Yep, I agree. That is a better analogy. If you know how to build a car, you will be an expert at building cars, not driving them. I mean, how many of the better racing drivers are builders themselves? If you always have to think about the how, the expression and the art suffers. Always. Human brain does not think in abstract logic, no matter how much you convince yourselves otherwise(may be except for some). It is always better at thinking intuitively. Now, if you disagree, I would encourage you to keep posting. I like to discuss this. Not just to challenge you, but would like to know about the mistakes in my thinking.

hypnocode 14y ago

Great points! It comes down to how deep you want to go, too. Programmers are still finding jobs, and it seems like our market is better than most hiring markets, at least in the United States. So if you just want a job programming: they're out there. If you want to be a real hacker, though, (Why else would you be here?) you need to be a little crazy, and obsess over the deep details of your specialty.

patio11 14y ago

Knowing the entire JVM spec is frequently less useful than being able to code a for loop whose contents do some domain specific thing that a 22 year old ninjedi will, with diligent study, understand in ten more years.

eru 14y ago
You mean, be able to come up with in ten years, or understand in ten years? The former is good. But in case of the latter, I wouldn't want to touch your code with a ten foot pole. (Even complicated Haskell type trickery, or, say, mathematical optimization algorithms shouldn't take longer than a few weeks to explain.)
- loumf 14y ago
  "domain specific" means something like, your code implements the thing you spent the last 10 years becoming an expert on, which you hopefully understand to such a degree that expert coding will be no help in trying to replicate it.
  - eru 14y ago
    Yes. That's why I mentioned not only type trickery but the one domain specific example where I can claim to be an expert in (mathematical optimization). I guess, the original ten years was hyperbole?
    - sethev 14y ago
      I think you're missing the point completely. Patrick's comment wasn't about a specific for loop and how hard it is to understand. Knowing what types of problems people have and how to write code to solve them is much harder than learning the JVM spec and much more valuable. How long did it take you to become an expert in mathematical optimization, for example? I doubt very much that that's something you picked up in a few weeks.
      - 14y ago

abc_lisper 14y ago

Don't read the entire VM spec. This thinking of knowing something inside out helps you how to use it is bunk. You don't have to know the how the rules of chess came into being to play chess. Or you could go that way, and do it as the parent says, and end up like me, somewhat dazed and confused a decade later. Just because you invented radio does not mean the programming you put on it is the best. Realize that programming(computer) is a skill that most can achieve only through rigorous grind. There, I saved a few years of frustration to you. Knowledge is power. Amen.

djtriptych 14y ago
I have to disagree strongly here. I do believe understanding something inside and out help you use it, and more importantly helps you invent new solutions, but I realize mine may be a minority opinion. Then again, this is HACKER news and what I've described is pretty damn close to the core hacker ethic. The two languages I call myself an expert at are Python and Javascript, I can say confidently that I wouldn't call myself an expert at the former without a damn good understanding of the entire language, data model, standard lib, and standard CPython implemention, nor the other without at least a decent grasp of the ECMA-262 spec, the knowledge of which comes into play more often than one who hasn't read it might guess. Your chess analogy doesn't really make any sense, sorry. A better one is to understand how a car is built before you drive it. I think that might just make for better drivers. Hopefully, the OP and those reading the discussion take away that you shouldn't stop at proficiency. Strive to know your stuff down to the bits. Don't become complacent; as I've read elsewhere here, Feel the incline, and walk uphill.
- abc_lisper 14y ago
  > A better one is to understand how a car is built before you drive it. Yep, I agree. That is a better analogy. If you know how to build a car, you will be an expert at building cars, not driving them. I mean, how many of the better racing drivers are builders themselves? If you always have to think about the how, the expression and the art suffers. Always. Human brain does not think in abstract logic, no matter how much you convince yourselves otherwise(may be except for some). It is always better at thinking intuitively. Now, if you disagree, I would encourage you to keep posting. I like to discuss this. Not just to challenge you, but would like to know about the mistakes in my thinking.