What did I do this past week? I just finished up my onsite interviews with Dropbox, at their San Francisco office! Wow!

What’s in my way? There’s an OOP exam next week that I’m a little afraid of, since there’s so much to study for. I also have part of a Compilers project due. And of course, the regular weekly assigned readings.

What will I do next week? Writing a very long study guide for this first exam. I need to catch up on Friday’s notes with a friend, since I missed class that day for my interview.

Here I am, sitting in the San Francisco Twitch.tv office visiting a friend, writting a blog post for my OOP class, after completing some on-site interviews at Dropbox. I’ve never had the fly-out-and-interview experience before, and it’s been quite an adventure. San Francisco is an incredibly packed city, with a lot of stuff to see and do and eat, though many of those things come with a high price tag - fortunately, the company pays for most of it! While part of me misses Austin already, I’d love to spend at least one summer in SF to see all the sights and sounds. The interviews went well, well enough, I hope. I’ll find out soon!

Often times this class makes me nostalgic for C. Good old C. In class this week, we covered some of the intricacies of C++’s operator overloading features that can be applied to user defined types. On one hand, I’m impressed how much code can be abstracted away through the use of common operators like assignment = and comparison ==, which, in Java, are normally exclusive to the primitive types. On the other hand, it bothers me that those operators have implementations that are abstracted away!

For example, consider the bitshifting operators << and >>. Most of the time, they’re used for bit manipulation. From a novice perspective then, who could have guessed that those operators are also used for writing and reading from streams? The programmer is required to trust that these operators work “as expected” and “as described”, and that scares me a litte. Trust, but verify, as Reagan used to say, but I won’t always have the time to verify.

One could make the same argument for object methods - they’re abstractions that hide the underlying implementation and effects of a class’ behavior, and we programmers need to trust them when we use them. Still, at least methods like .compareTo or .equals are explicitly functions, and functions can execute all the statements they want to, so I’m okay with them being user defined and possibly complicated. Plus, they have names, so they’re more, uh, human friendly. See, I like my operators simple and want them to do simple things.

C enforces simple. I like C.

Tip of the Week: When preparing for technical interviews, try solving practice problems by hand, on paper, without reference materials. This will not only test your immediate knowledge of the material, but limits the rate at which you can write and rewrite code, forcing you to plan ahead and be more careful as you go. Then check to see if your code “compiles” and runs, also by hand, so you can view the program state at every step of execution. You’ll catch more bugs, no duck required!