Exactly correct! An article claiming to explain how to answer questions involving run-time complexity shouldn't have such obvious mistakes in its analysis of run-time complexity.

(Yes, constant-time can be achieved by preallocating a fixed hash table, but that's not the same as using an arbitrary set insert/retrieve and since it permits collisions and is inherently bounded. It solves only a subset of the described problems.)

Mostly the dice article illustrates how the author is a poor person to look to for advice in that type of interview.

I was also going to recommend cubesat.org and smallsat.org. The mailing list at cubesat@cubesat.org is active with numerous ongoing projects, mostly university-based. There are ITAR issues with American citizens participating in open projects, but there is a one-man korean satellite/art project at http://opensat.cc/about.html that has scheduled a launch.

Another collaborative effort is the GENSO organization, attempting to coordinate a federation of volunteer ground stations to expand telemetry coverage.

It's true that small satellites are built from off-the-shelf components and that a 500km orbit is generally self-cleaning due to atmospheric drag, but there are still some significant engineering challenges involved.

I'm a hobbyist-level engineer with an MS CS; my thesis focused on methods of software reliability for satellites in low-Earth orbit. Here are a few of the things that I consider to be "difficult" parts of a cubesat:
- RF communication on a very small power budget. Expensive (for a hobbyist) commercial solutions exist.
- Power management and design. Expensive (for a hobbyist) commercial solutions exist.
- Attitude determination and control.
- Passing the specific thermal/vibration testing requirements for a specific launch provider
- Surviving radiation-induced errors. A significant fraction of student-built failed satellites are lumped into "Command and Data Handling Failure" that could be attributed to the wrong bit flipped at the wrong time

There are a few happy coincidences that make it easier:
- most orbits result in alternating sun/shadow exposure, every 90 minutes. This just happens to make the temperature of the typical picosatellite oscillate between -20-80F-ish (very, very -ish) such that electronic components keep working with a minimum of thermal engineering.
- low-earth orbit has enough atmospheric drag that you don't have to build an active deorbit mechanism to avoid becoming hazardous space junk
- the radiation energy levels at low-earth orbit are enough to cause single-event-upsets (flipped bits) in RAM, but NOT enough to damage typical FLASH memory, so an appropriate reset mechanism is usually sufficient. (A NASA engineer summarized it as "Restarting from a known good state")

Also, WOW, there's a lot of ignorant posts here on slashdot. I don't remember the signal-to-noise being this bad, but I could be biased by nostalgia.