The working visa has some restrictions - you must be between 18 and 30. It's only valid for 12 months and you can only work for a maximum of 6 months for any one employer. The last provision is a bit tough, but there are still plenty of 6 month contracts around.

Why do Americans have such a strong reluctance to travel abroad for work? I've never understood it. It's a great opportunity to get some work experience, live a little and, particularly for the mid-west and east coasters, skip winter!

To fully understand this you'd probably have to live in the US. We grow up constantly hearing things like "in America at least we know we're free" and many of us can't help but think "why do they keep repeating this? Is everyone else not?". We're constantly indoctrinated about being the best in the world, so no matter how bad things are here, they must be worse everywhere else right?

We have an enormous amount of people in the US who've never been outside of it and have a completely wrong picture of the rest of the world. It was shocking for me, for example, when I came over to Europe and saw places like Sweden and France. I saw what I knew as socialism, but it seemed to be working! And the more I looked the more it appeared to actually work better for the average person. It was so demonized back home, who could have imagined that it's actually just a trade off like everything else. Some previously good friends of mine now literally think I'm a communist (sadly I'm not even exaggerating).

However, I don't think many people know about this particular working visa. My sister lives in Australia and I hadn't heard of it until your post. I just looked it up and it looks like it started in 2007. Too bad I no longer fit the age requirements. I'll pass the info along to my younger brother, though. Good tip.

- Working abroad means leaving behind friends, family etc. To many people, this is a big deal

- A large majority of the working population have children. Moving abroad is not a simple process when you have a family and it then also means many people's support network (fellow parents, grandparents) disappears

Also I must say, there is a dearth of interesting companies to work for in software / technology outside of the USA (I'm sure someone will now provide me with a nice list and prove me wrong :). I'm in the UK and can only think of a handful of companies I would love to have a job at.

[I'm hoping to do something about this with all the job talk at HN recently and make discovering cool companies to work for easier]

But the number of available jobs is the issue here and I wasn't so much referring to established professionals as those who are just starting out and having a very tough time finding their first gig in the current US economy.

In Australia and NZ, the option to look abroad for work is on pretty much every graduate's list that I've met and I guess it's understandable due to our population sizes. I got my first development job in the UK and it was that critical "foot in the door" that I needed to get work when I came back home.

You're right that it was previously just Commonwealth countries, but I think US citizens were included as part of the US-Australia free trade agreement signed a few years back.

Also, I can't see any tertiary education requirement on the site (just secondary), but apparently you need to show you have access to $5000 on arrival.

The skills shortage is, apparently, acute.

When I finished my engineering degree and they had a jobs fair the Australian stand was huge - and the "package" of benefits (i.e. crazy tax breaks, free loan car etc.) was mad.

Do Americans have a strong reluctance to travel abroad for work? I haven't noticed one way or the other. When I graduated in 2001, my 'reluctance' was based on broke-ness. The difficulty affording even a $75 fee (for a background check to work for the local school district) meant that the thought of leaving all my connections and going several thousand dollars into debt for overseas relocation didn't even cross my mind.

Why the restrictive cutoff at age 30?

A link to github or a blog or something where I can see some of their work "in the wild" (not just a portfolio link) always gets them in the second pile as I find code a far better indicator of a good programmer than a good CV.

Was this written in the late 90's?

I follow job listing sites almost daily, and I'm just not seeing this. I'm also not seeing it in the volume of headhunters contacting me.

And thirdly, what job listings I do see, they have absurd ideas of what qualifications they require. Yesterday I saw a job listing for perl scripter for system automation tasks requiring a BSCS, MS preferred, and a little while ago I saw a sysadmin job requiring a BSCS.

I'm not in the middle of nowhere, I'm in the Boston/128 area.

So do I have the worst job hunting skills ever or is this guy living in a bubble?

Good companies don't care if you have a CS degree as long as you can code and think. That said, someone may have embellished the job requirements and if you think you'd be a good fit for a job it may be worth applying anyway.

I'm not sure what the situation is if you have no degree at all, or a degree with no scientific or technical element, but it helps to have evidence of your skills, and whatever your situation it really helps to know people who have a good impression of you and your abilities.

For better jobs boards, look at:

Stack Overflow Careers http://careers.stackoverflow.com/Jobs?searchTerm=&search...

HN Who's Hiring threads. Eg http://news.ycombinator.com/item?id=1659409

Also, check local user groups for whatever languages/technologies you're interested in.

One aspect is the theoretical foundation. You can of course get this by just reading yourself and a transcript doesn't actually prove you know anything but without a CS foundation, the onus is now on you know to prove somehow you're simply a "monkey see, monkey do" cut-and-paste coder.

The other important part is practical. Companies get a lot of CVs. For programming jobs, the most common filter is "has a degree". If you have one, you go in one pile, if you don't, you go in the other (which is often filed in the big circular filing cabinet). What's more, hiring managers may have their hands tied on this one: it could be HR policy or the hiring manager may not even see your CV because HR has already filtered it out (this happens a lot).

After I started working I went back and studied part time to get a degree. I'm glad I did, even if it's major use is to have one less barrier to being hired.

Stackoverflow careers? Seriously? "34 jobs found near boston". How many candidates are looking at these listings? Thousands?

Just imagine a sysadmin turning up with their laptop and demonstrating...

1. Provisioning of servers where they've created the *nix build, deployed a web app, mysql etc

2. They show off their system monitoring capability, take down a few services and then show off their e-mail alerts. Bonus points for twilio integration with SMS :)

3. They then show the backup process they have and how they verify their backups

4. The sysadmin then runs a series of security tests against a server and shows the results

I would hire that guy in an instant

In the case of a sysadmin job, this is how I would do it: start showing some expertise in configuring Linux virtual instances, discuss why and how you manage them, share tips and tricks you learned. That will do you a lot of good on your resume, help you land interviews, and help you convince during those interviews. Especially if you are competing with other college grads with 0 experience, you'll stand out.

Get out and contact the headhunters yourself and work with them and network with all the people you do know and hit them up for positions. They might not have anything at their work but its possible they or one of their colleagues has or knows someone who does have a position open.

Secondly you are taking the BSCS or MS lines in job ads at face value. When they say "Requires a BSCS" what they mean is "Requires a BSCS or experience".

My experience is in line with the author's. Finding a job has always been relatively easy (beginning at a certain point, which I will elaborate on) and I do not have a degree of any kind. It's my opinion that three factors are primarily responsible for my state of affairs.

1. I started working at a local ISP when I was 15 years old. This was around the time that 28.8kbps modems were all the rage. While I was very green I had unbounded enthusiasm and desire to learn whatever I could about technology. The ISP got a super cheap tech support person and I got paid to learn. After a year I got a chance to do UNIX sysadmin work, and my level of experience began to snowball.

The (fairly obvious) takeaway here is that I built experience. Businesses don't want to train you if they can help it. Not able to find a learn-on-the-job opportunity? Take the author's advice and contribute to an interesting open source project.

2. Befriending an employee of one of the largest ISPs in the United States ended up landing me a development position on a pretty large contract. I worked damn hard, and ended up contributing in a fairly visible way. Because the job was for a company in the Fortune 50 I've since been able to point to it as social proof that I at least have a vague idea of what I'm doing. Employers love this. This is when job hunting became dramatically easier.

You may think the takeaway here is to be lucky, but I disagree. The takeaway is to get to know people that you can develop mutually beneficial relationships with. To this day I still get contract work and referrals from people I worked with on that one job.

3. Location. Companies will sometimes relocate you, but I've never seen one that will do it without there being a very compelling reason to have you on staff (ie, experience and a proven track record). You have to go where the jobs are. Sometimes you have to suck it up, move away from your family and friends, become a nobody, and start pulling in a paycheck. Once you do you can start planning (and saving) for the luxury of living and working in a desirable place.

The takeaway here? Get away from the crowd. In my experience there are at least two good markets for developers, Denver/Boulder CO (Denver being easier than Boulder), and Kansas City MO/KS. I'm not a big fan of Kansas or Missouri (sorry natives, you're all great people), but Colorado is a beautiful place with lots to do outside your cube/apartment. The job markets in both those places are reasonable and you can be relatively well paid even with limited experience. How do they compare with SF/NYC? Not even close, but it's way easier to stand out from the crowd when there is no crowd. Being in the middle of nowhere can sometimes be a benefit.

All that said, good luck.

Why not start with a Python project or something more realistic?

Seeing your fixes shipped to you and your friends' browsers is an awesome motivational tool.

It's true that it's harder, but it seemed like a reasonable trade-off.

My main concern with picking a browser wasn't the difficulty it was the expense of having a good machine to work with. Sadly this applies to all browsers that I'm aware of. Building Mozilla is terrible. WebKit is probably the best; it just contains less code (you only build the rendering engine when you work on WebKit, not the browser).

Out of 1000 non-CS people who try to do this I'd be surprised if even 10 make it through to compiling the Chrome source, and I'll be stunned if even 1 makes it through to the end of your "5-step plan".

It's a noble aim, and the idea in general is right (learn to program and contribute to open-source software) (though I can't quite agree with considering their education a "sunk cost" - you need to build on what you have or you'll always be disadvantaged), but there are better, easier ways to achieve that objective than going straight from "I've never seen water in my life" to jumping into a pool infested with shark, mutant piranhas and man-eating giant squids.

Isn't that part of his goal, though? It's great to find people who are that passionate about the work. Somewhere out there a developer is drooling to work on a browser project and would be in heaven if they could prove themselves good enough to make the team.

Getting a job is what they are after right?

you should have tried building it in 1999. Last time i did it - in 2007 - it was a blast compare to 1999.

I suspect there are also plenty of bugs in Chromium et al which require non-trivial scripting to find and fix (who does exclusively manual testing any more?)

Now, in my current position, I wouldn't hire someone that didn't have a solid understanding of data structures already (unless they were an intern)... but at other places I've worked, I would hire you in a second. The thing that will make you stand out in an interview is a proven track record of writing software. Other stuff can be fixed later.

(A lot of people that work as "software engineers" cannot write or engineer software. They kind of open up the Eclipse project, click shit, write status reports, and call it a day. This is what I want to filter out in an interview.)

I agree here, which is why the author of the original post suggest contributing to open source projectors. The projects that he suggests require getting more than a surface knowledge of how data structures are implemented.

There are certainly programming jobs that don't require knowing data structures, but if you're a good programmer and you understand data structures and algorithm, the total pool of jobs open to you is much higher (and you're much less immune to being treated as a commodity, although in my experience that has more to do with the company and the industry rather than specific work).

But overall, seeing the software a candidate has contributed to (fixing bugs, implementing new features, starting new projects) is a much more reliable indicator than whether they can white board an algorithm to detect a loop in a linked list without using any additional storage. You can minimize false positives and false negatives, but you're going to get them.

I'm not a C/C++ bigot, my "favourite language" is currently a three-way tie between Scala, OCaml and Lisp. Plenty of real programming gets done in other languages (plenty of people also think that C is the secret sauce for performance, but that's not the case), but C is important for two reasons: it's the lingua franca of programming and it's a great language for learning how computers work. Pascal may have been another option twenty years ago, but there are hardly any interesting open source projects being done in it today.

(Though it is hard to avoid in Java; seems like everything useful takes a StringBuffer instead of a String. Java -- the high-level language with about as much abstraction as assembly.)

However, this is different than pass-by-reference. With pass-by-reference, if i assign a new value to the callee argument variable, that value also replaces the value in the caller. This is not true in java/python/ruby where it is termed "call by sharing" http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sha...

In agreement here, the state of the object changes according to a message passed to the object. In this case, the value we passed is a pointer to the object. We can't, however, change what object the pointer points to in Java, which is why I call it "pass by value". E.g., I can't do equiv of this Perl code.

sub bar { my $foo = Foo->new(a => "a"); foo(\$foo); }

sub foo { my $arg = shift; $$arg = Foo->new(a => "b"); }

On the other hand, in Perl even though I am passing a reference by value, I can still mutate the state of the object:

sub bar { my $foo = Foo->new(a => "a"); bar($foo); }

sub foo { my $foo = shift; $foo->set_a("b"); }

(Please excuse my Perl, I haven't written OO Perl in over a year now).

In any case, I think this is a pedantic point. Both of us agree that other than in few cases (algorithms/data structures that are difficult to express in a functional way), objects shouldn't be smashed by hammers: whether internal or external.

I also don't understand why Java's standard library authors didn't do what Scala did and provide both mutable and immutable versions of collections. Java 5+ added great lock free data, concurrent data structures, but much like they have a ConcurrentMap, they could have added a "ImmutableMap"/"ImmutableList" interfaces (especially given the fact that some data structures e.g., CopyOnWriteArrayList behave like this internally). I really like Scala's "functional objects": objects that upon receiving a messages, create new objects. In Java, an object may be final, but it will still (as you put it) "be smashed by a hammer" as long as the hammer smashing was invoked by a message. Same thing happens in C++ with const methods, in objects passed as const& references which contain objects that mutate their state upon a message being passed. Rich Hickey discusses this much better than I do in his famous talk: http://www.infoq.com/presentations/Value-Identity-State-Rich... (although I may not agree with all of his conclusions)

> seems like everything useful takes a StringBuffer instead of a String

That's a textbook example of premature optimization :-) The compiler will convert string concatenation to StringBuilder. See: https://gist.github.com/670577 It does makes sense to use a StringBuilder when you are doing concatenation inside a loop (and don't want the overhead of allocating a new StringBuilder inside), but otherwise there's no advantage to it.

(Oddly enough, in this example the default optimization level did not unroll the loop itself. OCaml, on the other hand, despite having a much more compiler-friendly type system than Java, doesn't perform the equivalent optimization on string concatenations with the '^' operator. I am pretty sure g++ will do both, despite C++ being lower-level and having weaker typing than OCaml and Java).

For another example of this kind of premature optimization, see people using inline in C++ code when the gcc/clang will have a much better idea than the developer on when to inline a function call and when not to :-)

I think this makes it about twice as difficult to get up and running in c++. Not saying it's better or worse or going to make you a better programmer or not, but I don't think anyone could argue that it's easier to learn C++ than python/ruby/php/etc.

Also see: http://www.joelonsoftware.com/articles/fog0000000006.html

This is not the sort of understanding you want people you're paying to write software to have.

(And yes, I do see this from time to time. "Do you know anything about programming!?" "Yes, just enough to be dangerous.")

Welcome to software development. :-) Seriously, I probably spend at least 10% of my time dealing with broken libraries, badly documented build processes, and other depressing obstacles.

If you can get past these kinds of problems—and more importantly, if you submit fixes to spare the next person the pain—then you'll make a great developer.

Sounds like a good idea to me, esp. for people working on a laptop.

Seriously, do you have to compile the whole program for every code change? I suspect that is not necessary?

Also a common way to speed up build times is to build in release mode.

Core i7, 12GB of RAM, 10k RPM HDDs.

The built executable worked first time too, which was impressive for a project of that size, given that it was the very latest bleeding edge trunk source code.

For comparison, I tried to build Mozilla three or four years ago, and gave up. The Chrome build environment setup instructions, while long and tedious (especially on Windows), are excellent.

This serves as a nice textbook example of why implementing things like menus and keyboard shortcuts by hardcoding keycodes in C++ is a horrible idea.

It's not merely a question of needing to be told that it's easy to contribute. That's not even the right way of looking at it. The question is whether it is easy at all, and I say no. If someone told me it was easy to contribute to open source software I'd know they were either lying or delusional.

I think the thing that people often miss is that getting a patch that works is really only 50% of the process of getting a bug fix/feature merged into an Open Source project.

In a company, the hiring process is an initial crap filter (or at least is supposed to be). In an Open Source project, the filters work very differently. You won't find a lot of (community driven) projects that spend a lot of effort putting together detailed documentation about how to build a project and submit patches. That's because figuring this out is the first level filter.

The second level filter is figuring out the architecture of the project. This can be difficult in a subtle way. In a company, you can usually sit in a conference room and have someone explain to you all of the details of the project such that you have a pretty good idea of how a patch or feature should be implemented.

In most Open Source projects, you generally have to code up an initial version of the feature and then you'll attract enough eyes that you'll get the feedback about how to do the feature properly. If you're a long term contributor, you skip most of these steps and the process is fast. If you've never contributed before, it's almost certainly going to take a lot of effort.

It's all about scalability. Open Source projects significantly reward people that are self motivated and can figure processes out without a lot of hand holding because that's the type of person you need to build a successful project when there aren't any managers, program managers, or formal architects.

I think that's probably the biggest value of the proposed plan. If someone has gotten 50 patches into a major project, it says a lot more about the individuals personality and motivation than it does about their programming skills.

Absolutely not. It's because it's boring and it's time for bed now so let's do that tomorrow. Eventually it does get done, though; all the big-name open source projects have this sort of documentation available.

(And now, thanks to Github and the implicit fork-and-pull-request model, so does almost everything else. Reuse++!)

If you are getting a lot of pushback on your changes ("it's not indented right"), there is probably something else that's wrong. And sometimes, there is administrative triva to deal with.

(The other day, someone sent me a patch for ibuffer-git via a github issue. I'd prefer a pull request, but fine, whatever, easy to apply anyway. The problem is that I need to keep a list of contributers in case I decide to contribute the extension to the emacs core. This person had no contact information, so I couldn't just apply his patch. I really needed the fork-and-pull-request so that the author information would be properly recorded. Annoying for a 2 line patch, but a necessary evil. And even then, the patch is applied in my repo, it's just not pushed yet :)

1. Employers are often focused on hiring very specific skills sets. Having fixed a C++ bug in Chromium should impress them, but if they need a Django expert they still see you as a novice. It can be hard to present yourself as a well-rounded candidate if all your experience is with one project.

2. In a couple of interviews I've had, I've noticed a distinct bias towards valuing paid work more than open source contributions. It's often hard to get interviewers to understand that something I've done for free is on the same scale (or greater) than things I've been paid for.

Last time I wrote a resume, I didn't have enough that I felt it was significant, so it went down as a relevant hobby, just like volunteering at the computer shop in and winning awards for computer knowledge high school.

If you have 2 or 3 projects to list, an "Open Source Contributions" section is fine with me. The main thing to avoid is fancy formatting. How you divide things up into sections is not a big deal.

I like this article because I got my job this way. :)

But the truth is that most people who try this will fail. Very few people have the right combination of aptitude and attitude to do this (especially considering that the intended audience is people without an IT background).

[edit] Perhaps the message to take away is that there is a low barrier to entry in our field, so it's worth giving it a shot.

There are better routes for new programmers IMHO.

Start at http://rubyonrails.org/ and build a website you find useful.

Learn SharePoint or BizTalk, those are boring but in very high demand now.

Even more boring, sing up for a cheap 6 month Cobol course in India.