Ask HN: How to look for a programming opportunity
9 comments
I think this is largely good advice. You could expand it to thinks much more concrete than "improve your job-getting skill": make yourself a portfolio website if you don't already have one. Make decisionmaker-specific pages on your portfolio website targeting the exact interests of the people who you want to hire you.
(Hypothetically assuming I wanted to apply to Google, Big Japanese Megacorp, and Cool Valley Startup, I'd be pitching myself in a very different way in the cover letters and resumes... why show them all the same portfolio? I mean, theoretically I'm supposed to be pretty good at this whole "Build a web page to sell stuff" thing -- if I can't build a web page to sell me, why should they hire me?)
If you don't already have a blog and social proof of value which you can quote to people, start building them. For example: you put a recommendation on your resume in the hope someone calls them, they agree to talk, and then they praise you, right? That's an awful lot of opportunities for the recommendation to not pan out well. Instead, when you ask for a recommendation, ask for a testimonial, too, which you will prominently quote in your Hire Me salesletter. And write the testimonial for them. "Hey boss, can I quote you on '$NAME_HERE is one of the best developers I've ever had the pleasure of working with. He has done things with $PROJECT that we never thought were possible. I'd hire him in a second.'?" (This presumes you have, actually, made a good impression on your boss. If not, then just write down their phone number and pray that no one calls it, because that is apparently what everyone else does.)
Networking is, obviously, another opportunity for improvement. Rather than spending time waiting for someone to call you back, it is (well past) time to start reacquainting yourself with friends and business associates (and mentioning, hey, you're on the market now) and making new friends/business associates.
(Hypothetically assuming I wanted to apply to Google, Big Japanese Megacorp, and Cool Valley Startup, I'd be pitching myself in a very different way in the cover letters and resumes... why show them all the same portfolio? I mean, theoretically I'm supposed to be pretty good at this whole "Build a web page to sell stuff" thing -- if I can't build a web page to sell me, why should they hire me?)
If you don't already have a blog and social proof of value which you can quote to people, start building them. For example: you put a recommendation on your resume in the hope someone calls them, they agree to talk, and then they praise you, right? That's an awful lot of opportunities for the recommendation to not pan out well. Instead, when you ask for a recommendation, ask for a testimonial, too, which you will prominently quote in your Hire Me salesletter. And write the testimonial for them. "Hey boss, can I quote you on '$NAME_HERE is one of the best developers I've ever had the pleasure of working with. He has done things with $PROJECT that we never thought were possible. I'd hire him in a second.'?" (This presumes you have, actually, made a good impression on your boss. If not, then just write down their phone number and pray that no one calls it, because that is apparently what everyone else does.)
Networking is, obviously, another opportunity for improvement. Rather than spending time waiting for someone to call you back, it is (well past) time to start reacquainting yourself with friends and business associates (and mentioning, hey, you're on the market now) and making new friends/business associates.
The one point I disagree with is giving people the suggested testimonial. This may vary by culture and person, but there is no better way to guarantee my non-cooperation than telling me what you want me to put my reputation on the line as having said. No matter how good an impression I had before, I'd have a bad one after that interaction.
Otherwise I agree with your advice.
Otherwise I agree with your advice.
I think this is fairly common. I've had two people agree to give me a recommendation on the basis that I write it for them, allow them to see it and change anything that they don't like, and then sign it. As I see it, if you're willing to help me out then I wouldn't want to take up your time unnecessarily. If you want to write the whole thing yourself, then great! But if you're willing to do it but are time-constrained, I'll help you.
Different people have wildly different expectations. When my mom wrote a book, she was dumbfounded that she was supposed to write all the back-flap testimonials herself, and then the person they were attributed to just had to sign off on them and put their name on it. All but one of the people said, "Ah great, I don't have to do any work, this is awesome." One person said "WTF is this?" and wrote her own testimonial.
In my limited sample size, I tend to trust & respect the people who say "WTF? It's my name, I'll write it myself" more. Unfortunately, they seem to be in the minority.
In my limited sample size, I tend to trust & respect the people who say "WTF? It's my name, I'll write it myself" more. Unfortunately, they seem to be in the minority.
If they ask, that is one thing. If you offer out of the blue, that is another.
Just write code. Work on open source projects, blog, twitter, and keep a GitHub account with interesting projects in it.
I know that many jobs may hire by running "grep" on hundreds of resumes, but I don't think those jobs are the good ones. I think the good jobs want to hire your brain, not for any particular language, but for the overall value you can add to the company.
Working on open source projects and posting your own projects on sites like GitHub demonstrate your ability to understand architecture and write good code in any language.
This is what I'm looking for anyway, and it seems to be what Google is trying to get at with all the silly questions they ask during interviews. How good is your brain?
http://www.fireworksproject.com/pages/extraordinary_people.h...
I know that many jobs may hire by running "grep" on hundreds of resumes, but I don't think those jobs are the good ones. I think the good jobs want to hire your brain, not for any particular language, but for the overall value you can add to the company.
Working on open source projects and posting your own projects on sites like GitHub demonstrate your ability to understand architecture and write good code in any language.
This is what I'm looking for anyway, and it seems to be what Google is trying to get at with all the silly questions they ask during interviews. How good is your brain?
http://www.fireworksproject.com/pages/extraordinary_people.h...
I have to strongly agree with your second paragraph, but finding the good opportunities is the trick.
I'd disagree with this. Most of the candidates I've seen turned down weren't rejected because they lack some nebulous job-getting skill. They were rejected because they don't have the CS and programming skills to do the job.
The part I would agree with is that learning a new language != getting better at programming. When you learn a new language, you're increasing your breadth of knowledge - but most employers don't hire for breadth, they hire for depth. They want you to be good at the job they hire you for. And when you pick up a new language, you'll perform worse than on your existing languages, until you've had the practice to bring your skills up to where they were before.
Instead, spend time learning your language better. Most languages (even Python) provide different ways to accomplish the same task; try them all out, find out which is best, and most importantly, find out which is best for which tasks. Learn some libraries in depth. Write some actual code so you have something tangible on your resume - starting a project from scratching will teach you a lot that maintenance work at your employer won't, and even contributing some patches for an open-source project will teach you something new.
A big problem with many candidates is that their knowledge is very shallow: they'll claim to be an "expert JavaScript programmer", where "expert" means they can only use JQuery snippets they found on the web. And they don't even realize that their knowledge is shallow; they're completely oblivious to the depth of the subject until they meet someone who really does have deep knowledge (and even then, only rarely).
The part I would agree with is that learning a new language != getting better at programming. When you learn a new language, you're increasing your breadth of knowledge - but most employers don't hire for breadth, they hire for depth. They want you to be good at the job they hire you for. And when you pick up a new language, you'll perform worse than on your existing languages, until you've had the practice to bring your skills up to where they were before.
Instead, spend time learning your language better. Most languages (even Python) provide different ways to accomplish the same task; try them all out, find out which is best, and most importantly, find out which is best for which tasks. Learn some libraries in depth. Write some actual code so you have something tangible on your resume - starting a project from scratching will teach you a lot that maintenance work at your employer won't, and even contributing some patches for an open-source project will teach you something new.
A big problem with many candidates is that their knowledge is very shallow: they'll claim to be an "expert JavaScript programmer", where "expert" means they can only use JQuery snippets they found on the web. And they don't even realize that their knowledge is shallow; they're completely oblivious to the depth of the subject until they meet someone who really does have deep knowledge (and even then, only rarely).
I agree with your assessment of learning a new language != getting better at programming, as well as how you become an expert in a particular field.
After reviewing these comments, it seems the interesting aspect of Giles Bowkett's paragraph is the emphasis on networking your way to a person with a need. It's easy to get blinded by the easy access to openings posted on job boards to the existence of non-advertised positions and enterprises you may not be familiar with. Rather than "job-getting" skill I'd call it "opportunity-finding" skills. Getting past HR can be a bear.
After reviewing these comments, it seems the interesting aspect of Giles Bowkett's paragraph is the emphasis on networking your way to a person with a need. It's easy to get blinded by the easy access to openings posted on job boards to the existence of non-advertised positions and enterprises you may not be familiar with. Rather than "job-getting" skill I'd call it "opportunity-finding" skills. Getting past HR can be a bear.
I think the claimed point is valid. If you are a good programmer, you can improve your chances of finding a job much more by polishing up your resume, writing awesome cover letters, networking, etc. than you can by learning new programming languages.
It's all about bang for the buck. If you spend 100 hours learning, your programming skills and hence your ability to find a job might improve by a few percent; if you spend 100 hours on marketing yourself better, your programming skills stay the same but your chances of finding a job will improve greatly. It's like a lot of software... once the internals are good enough, it's much better to make the UI good than to keep the UI crappy while making the back end a little better.
Also, anecdotally, every good company that I've interviewed with has said that if I am the right person for the job, then they will give me the benefit of the doubt that I can pick up whatever technologies are necessary.
It's all about bang for the buck. If you spend 100 hours learning, your programming skills and hence your ability to find a job might improve by a few percent; if you spend 100 hours on marketing yourself better, your programming skills stay the same but your chances of finding a job will improve greatly. It's like a lot of software... once the internals are good enough, it's much better to make the UI good than to keep the UI crappy while making the back end a little better.
Also, anecdotally, every good company that I've interviewed with has said that if I am the right person for the job, then they will give me the benefit of the doubt that I can pick up whatever technologies are necessary.
In most cases I agree. If you can't get a job with your primary language, you'll have a harder time getting one in a language you just learned.
But there are exceptions. For instance if you don't have a programming background, learning the basics of something employable is a good idea. Also some things do become obsolete. For instance if your background is VB 5, you should update your skills to be more employable. (Actually you should have done that a few years back...)
Another exception is when a particular area is hot. If not many know a suddenly popular language or library, teaching yourself that tool can give you an edge on those jobs. Of course most jobs are maintaining something that already exists, and so don't need to cool new stuff. And more people try that strategy than there are jobs, so it may be a losing proposition to compete there. But, for instance, a lot of people learned Java back in the mid-90s to jump on a bandwagon, and it worked out for many of them.
Also it is fine to learn something for the job prospects when you have an obvious hole in your resume. For instance if you've been doing statistics professionally and you haven't learned R, you probably should. If you're a Perl web programmer and haven't learned Catalyst, it is at least worth playing with for a couple of weekends. A Java programmer is on solid ground in deciding to learn Spring better.
A special case of the obvious hole is when you need to learn something to get a certification. The whole certification treadmill is something I hate. But there is no question that it can help you, and acquiring relevant certifications is not a useless endeavor.
And a final exception is if there is a specific requirement for a job you want that you have a realistic shot at. For example I learned three languages before my Google interview. I knew that the interview would be in some combination of C++, Java and Python, and I knew none of them. So I learned the basics of all three, and made my lack of experience clear in the interviews. I was not hired for my knowledge of those languages. But without putting out that effort I couldn't have passed the interview. However this kind of situation is the rarest of them all. (This has only happened to me once.)
But there are exceptions. For instance if you don't have a programming background, learning the basics of something employable is a good idea. Also some things do become obsolete. For instance if your background is VB 5, you should update your skills to be more employable. (Actually you should have done that a few years back...)
Another exception is when a particular area is hot. If not many know a suddenly popular language or library, teaching yourself that tool can give you an edge on those jobs. Of course most jobs are maintaining something that already exists, and so don't need to cool new stuff. And more people try that strategy than there are jobs, so it may be a losing proposition to compete there. But, for instance, a lot of people learned Java back in the mid-90s to jump on a bandwagon, and it worked out for many of them.
Also it is fine to learn something for the job prospects when you have an obvious hole in your resume. For instance if you've been doing statistics professionally and you haven't learned R, you probably should. If you're a Perl web programmer and haven't learned Catalyst, it is at least worth playing with for a couple of weekends. A Java programmer is on solid ground in deciding to learn Spring better.
A special case of the obvious hole is when you need to learn something to get a certification. The whole certification treadmill is something I hate. But there is no question that it can help you, and acquiring relevant certifications is not a useless endeavor.
And a final exception is if there is a specific requirement for a job you want that you have a realistic shot at. For example I learned three languages before my Google interview. I knew that the interview would be in some combination of C++, Java and Python, and I knew none of them. So I learned the basics of all three, and made my lack of experience clear in the interviews. I was not hired for my knowledge of those languages. But without putting out that effort I couldn't have passed the interview. However this kind of situation is the rarest of them all. (This has only happened to me once.)
I boned up on C++ before my Google interview because I didn't know it and heard it would be included. It turned out that my interviewers exclusively asked me questions in Java and JavaScript, both of which I had fairly extensive experience in.
Then I ended up working in C++ and Flash once I was hired. Neither of which I had any prior experience with (well, I had a little Flash, mostly as a compiler target). Go figure.
Then I ended up working in C++ and Flash once I was hired. Neither of which I had any prior experience with (well, I had a little Flash, mostly as a compiler target). Go figure.
There are still COBOL jobs. But are they the kind you're interested in?
If you're interested in, say, web programming, you're probably going to have a hard time finding a job doing web programming in COBOL.. no matter how great your interviewing/job-hunting skills are.
The same goes for many other preferences regarding work, from location to the kind of company you'll be working at or people you'll be working with. If most jobs you're interested in largely have openings for people who know language X, you'll probably be better off knowing that language.
On the other hand, it's certainly a good idea to have well-rounded skills. So if you're particularly weak at people skills, or job-hunting skills, it's a good idea to work on improving those, as often being a good programmer is not enough to land the job you want.
If you're interested in, say, web programming, you're probably going to have a hard time finding a job doing web programming in COBOL.. no matter how great your interviewing/job-hunting skills are.
The same goes for many other preferences regarding work, from location to the kind of company you'll be working at or people you'll be working with. If most jobs you're interested in largely have openings for people who know language X, you'll probably be better off knowing that language.
On the other hand, it's certainly a good idea to have well-rounded skills. So if you're particularly weak at people skills, or job-hunting skills, it's a good idea to work on improving those, as often being a good programmer is not enough to land the job you want.
> you're probably going to have a hard time finding a job doing web programming in COBOL
Nah. See http://www.coboloncogs.org/ . :-)
Nah. See http://www.coboloncogs.org/ . :-)
I can easily find you a job doing web programming in COBOL. The first tech company I worked for decided to build their new task system in COBOL. I can't really remember the framework they were using (RMCOBOL, I think), but they had somehow managed to find a way to get Apache installed on a HP 3000 that communicated with a COBOL web app.
Keep in mind, I'm 20, and I only really started working when I was 18. This all happened two years ago, and I seriously doubt they've stopped using COBOL in that time.
Keep in mind, I'm 20, and I only really started working when I was 18. This all happened two years ago, and I seriously doubt they've stopped using COBOL in that time.
The best-paying jobs advertised at the state telecom are for Senior COBOL programmers. That definitely makes me wish I knew it a bit better :P (I did have COBOL classes at college, and I'm 29)
It's an easy enough language to master. There aren't a whole lot of constructs. The difficulty is wrapping your head around the massive lines of code that any COBOL program of reasonable complexity is bound to have. Not to mention every variable being defined by what it looks like, no notion of scope, no syntactic sugar like for or while loops, and no notion of methods. It's all supposed to read like English, but while English can pack a lot of meaning in a few statements, COBOL can't do anything in a few statements.
"I worked for decided to build their new task system in COBOL" - this cannot be true .
It is indeed true. They had a pre-existing task system that ran on the HP3000 that was built in COBOL. They modeled the new one (that was supposed to be web based) on the old one, and they decided to build it all in COBOL. I'm guessing they repurposed [1] some code, and they definitely repurposed the database. I think the goal was to have employees continue to use the command-line based task system while allowing customers to input tasks on the web. I think they also wanted employees outside the main office to still be able to access the task system if they were, say, at a client's office.
I left right around this whole project got started. I even mocked up the original interfaces. Twice. The first time I didn't do the whole thing in a table and my manager couldn't understand it, so I had to rip out any CSS and divs and go back to the 90's. They had two "graphic designers" on staff, so I'm not entirely sure why I was given that task, but there it is.
My whole time there seemed like some weird trip back in time. It took me a while to get used the copyright date on the COBOL compiler being two years before I was born.
[1]: "Repurposed" is used loosely. The way you build web apps in COBOL is so convoluted that it's extremely hard to use pre-existing code.
I left right around this whole project got started. I even mocked up the original interfaces. Twice. The first time I didn't do the whole thing in a table and my manager couldn't understand it, so I had to rip out any CSS and divs and go back to the 90's. They had two "graphic designers" on staff, so I'm not entirely sure why I was given that task, but there it is.
My whole time there seemed like some weird trip back in time. It took me a while to get used the copyright date on the COBOL compiler being two years before I was born.
[1]: "Repurposed" is used loosely. The way you build web apps in COBOL is so convoluted that it's extremely hard to use pre-existing code.
Giles is wrong. Learning a new language/toolkit is actually a "job getting skill." I got my last 3 jobs by learning Javascript, Ruby, and Objective-C. They would not have hired me if I hadn't taught myself how to do stuff in those languages. If it's a startup job you are expected to hit the ground running. Figure out what job you want and then figure out what you need to know to get it.
That said, hardcore C++ skills are in demand everywhere from audio software to robots to games to wall street to scientific research. Even "web" companies need C++, Google, OKCupid, Amazon, etc. If you're already good at it, it's a great skill to polish up.
That said, hardcore C++ skills are in demand everywhere from audio software to robots to games to wall street to scientific research. Even "web" companies need C++, Google, OKCupid, Amazon, etc. If you're already good at it, it's a great skill to polish up.
In my college first year, we programmed in two languages Fortran and scheme. It really made me a better programmer. Scheme rocks.
MySpace hired this person after they built http://myspacehire.me/
I'm sure they've been other examples of people being hired (or not) after turning a cover letter into a dedicated web site for the employer they want - anyone remember any others?
I'm sure they've been other examples of people being hired (or not) after turning a cover letter into a dedicated web site for the employer they want - anyone remember any others?
As someone thinking about working in programming after not doing much real programming for a few years, I am interested in whether he's right or not. I am actually planning to dive into learning a new language or relearning C++ with its current set of metaprogramming features and extensive libraries.