March 2007 - Posts
Looking back at my previous posts, I decided to revisit a few with the perspective of some time gone by.
Back in February, I compared and contrasted the eMusic and Urge music services. eMusic came out ahead and after another 2 months of use, I am still really happy with it. I've discovered a couple of great new bands and the website continues to impress me with its usability.
I just encountered my first issue yesterday when I went to use my latest batch of downloads. The previous month I had downloaded Bloc Party's latest album and wanted to get the previous one. However, these albums were now no longer available to download. A victim of their own success? I sent an email to eMusic to find out what's going on, so we'll see if then can top Urge's painfully slow response rate.
Earlier this month, I referenced the FizzBuzz test, used in interviews to quickly assess a candidate's basic level of programming skill. With a rare comment posted asking for more, here's the description and a solution:
Description:
Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".
Possible Solution (in a Python interpreter):
def FizzBuzzFunc(x):
if (x % 5 == 0 and x % 3 == 0):
print "FizzBuzz"
elif (x % 5 == 0):
print "Buzz"
elif (x % 3 == 0):
print "Fizz"
else:
print x
[FizzBuzzFunc(x) for x in range(1,101)]
This is probably not the cleanest / most Pythonic way to do it, but it seems to work.
The first part is just a function definition, the form of which should look pretty familiar even if you don't know any Python.
The second part is a list comprehension, which translated into pseudo code says:
For every value "x" in the range defined from 1 to 101 (not including 101), execute the function FizzBuzzFunc with "x" as an argument,
If you've been following my blog at all, you know that I have previously mentioned some fiddling around I've done with Ruby. Well that never really took off, so next on the list was Python. The reasons for ditching Ruby and going to Python are too long to include in this post, but perhaps sometime in the future.
After a trip to New York City and a little break from blogging, I compiled a couple of items that caught my attention online:
1. USB Monitors
Samsung was showing off USB monitors at the CeBIT conference. Yes, USB; so your CPU does the graphics processing and you hook up the monitor to an open USB port. So multiple monitors without multiple DVI ports or multiple video cards. CPU power is comparatively cheap now, so why not? Looks like it will only work on XP (via special drivers) and eventually Vista. Who knows how it would handle graphically intense applications like games, but if you just want to add another monitor for your system for coding/work functions it should do fine. For more details: http://crunchgear.com/2007/03/16/samsung-ubisync-usb-monitor/, also http://www.engadget.com/2007/03/15/samsungs-ubisync-monitor-rig-all-usb-all-the-time/
2. The Comments on Coding Horror
Jeff Atwood's recently posted about the growing complexity of web UI's and how they compare to desktop/fat client UI's, Are Web Interface's Good Enough?. That's a great topic on its own, but I encourage you to read through the comments. Sometimes comments can just be flame wars and are easy to ignore, but these comments are full of good arguments and were a humbling reminder of how many different technologies are out there vying for our attention.
3. Putting Them on the Record
Via Tim O'Reilly's post on Radar, http://radar.oreilly.com/archives/2007/03/dear_speaker_ca.html, I learned about the efforts of Carl Malamud to record the streaming video from various Congressional committees and hearings. Carl describes his efforts in an open letter to Speaker of the House Pelosi, http://public.resource.org/dear_speaker.html.
I don't think video of congressional hearings will overtake American Idol anytime soon in popularity, but it seems like fundamentally good information to have around. From a technology perspective is satisfying to see an individual (albeit a highly qualified one) so effectively bury the "it can't be done" excuse. Like I said earlier, you got to put those extra CPU cycles to use.
*For good NFL news and the inspiration for this title, check out Peter King's Monday Morning Quarterback, http://sportsillustrated.cnn.com/writers/peter_king/archive/index.html.
Jeff Atwood, of Coding Horror, posted (link) recently on the surprising results of administering small coding tests while interviewing developers for job. You can check out his post for the details, but the gist of it was that most people, in fact a shocking percentage of applicants, could not code a solution to the problem.
This got me to thinking about my own experiences going through interviews and the curveball questions I've encountered. So here are some of my most memorable interview moments:
The Oregon Trail (Do you want to ford the river?)
Curve Rating: Barry Zito 12 to 6 Slow Curve
Setup: Further demonstrating the ill effects of too much Diet Coke on memory, I cannot remember when I encountered this question. The premise was that there was a group of survivors on an island and they need to cross a river. There were more of them than could fit on the raft, so multiple trips were necessary. I had to allocate people on the raft based on a series of rules such as Rob and Kimberly have to stay together, Jack hates Sawyer, etc. And the fierce island natives would attack the survivors if it took too long.
Making Contact? At first glance this problem looked like it could be trouble. However, like that 12 to 6 slow curve, if you recognize it, you can make good contact. After I concentrated for a bit to identify and map all the rules, the rest was plug and churn. I actually really enjoyed solving this one.
My Strings are Better Than Your Strings
Curve Rating: Randy Johnson Backdoor Slider
Setup: I tackled this one during college for an entry level programming job. The task was easy to describe: write a method to compare two strings for equality (character by character) in C.
Making Contact? This was the question were I really learned that you should be prepared to talk about anything you put on your resume. Most of my CS classes were in C, but by my senior year I was coding mostly in Java and taking a lot of design classes, so I was a little rusty. By the time I got my head back into my C mindset, it was already too late, my time was up. I had an off by one error and did something wrong with the zero terminator. So like a fastball speed curve, I only got a weak swing in on it.
A Train Leaves Boston at 1pm Going 50 mph, Another Train...
Curve Rating: Matsuzaka Gryoball
Setup: I faced this question during an interview for a summer internship with Microsoft while I was in college. The basic setup was 2 runners on a race track. One starts ahead of the other and in inside position, the other is a little bit faster. When do they catch each other?
Making Contact? Much like the mythical Gryoball, this question was unhittable for me. I was not prepared for a question like this and despite taking differential equations in college, I just never liked or really got trigonometry. I tried in vain to remember the sine, cosine, etc. formulas that would have made solving this possible. Right before I ran out of time I started just trying to get a ballpark approximation by throwing out some guesses.
NOTE: My apologies to fans of baseball who may have been both strangely attracted and repulsed by my forced analogies. Also, the string question in C is roughly analogous to Jeff's FizzBuzz problem, but I like the FizzBuzz version a lot better. Seems to me to be a more pure test of programming than the C one which is highly dependent on the vagaries of C syntax and behavior (which if you want a C guru is really important, but otherwise is just annoying).