_cbsz

objdump doesn't give you the pretty "graph view," showing the basic block structure of the code. (In particular, this is really nice for switches and other jump tables.) It doesn't make it trivially easy to see where certain rather important-looking strings are referenced in the code. It doesn't show strings that are being referenced right next to the assembly instruction that references them, like changing

    push   0x8049808

    push offset aD        ; "%d"

    mov eax, [ebp-0x4]

    mov eax, [ebp-first_number_I_entered]

In addition, the Hex-Rays decompiler (http://www.hex-rays.com/decompiler.shtml) produces C-like output. I don't have a license for it, but I imagine it would make short work of the bomb lab.

EDIT: to try to answer my own calculation on the back of the envelope...

We're going to need n^2 space and n^3 time, where n is the number of nodes. There are about 3.5 million articles (http://en.wikipedia.org/wiki/Wikipedia:Size_of_Wikipedia), and if we assume that the diameter of the Wikipedia graph is 255 or less, we need 1 byte * 3.5 million * 3.5 million = 12.25 TB just to store path lengths for all pairs. It's also going to take a while because locality is going to be hosed. You might be able to do something smarter, like do the all-pairs solutions for something that will fit in memory (top 30000 pages or so), and hope that queries match a long-tail distribution...

Front-end: "vote counted!"

Back-end: vote redirected to /dev/null!

It's not immediately obvious to me how to make such a system transparent enough to convince the losers that they lost honestly. Cryptographic schemes may be able to solve it, but I think it's an open question whether they'll be convincing and secure in practice.

(I will not go into Ruby's disadvantages nor direct language comparison because I don't want this thread to devolve into a language flamewar.)

    assert l is not None and len(l) == 1

Next question.

These throwback OSes are cute, but there would be hell to pay if they ever took off.

2) Include everything relevant without being too verbose. Education, Experience, Skills. Probably relevant coursework in the Education section. Don't put anything in Skills that you wouldn't be comfortable being asked about in an interview; it's appropriate to differentiate between "strong experience" and "experience".

By the way, I am not a recruiter, but my student resume landed me interviews for internships with Microsoft and Google, among others. If my experience is any guide, your first resume will suck, but getting the content out there is a good first step, and then you can improve. Spend several short sessions on it.