The Robot's Thoughts

Imagine this for a frustrating experience.

In an interview for a major corporation located in Redmond, WA. that is responsible for producing the O.S. that 90% of the world uses, you are asked a question in person that was also present on your email pre-screening.

"What are some of the differences between a pointer and a reference?"

Knowing both, but unsure how to make sure you get the "atta-boy" for explaning it properly, you use the C++ FAQ Lite online and double check. I assumed if they didn't want people to use Google, they would've said on the email pre-screening app NOT to use google.

Now imagine its you're sixth interview, and its been a long day. You're interviewing with a guy whose name, even having it pronounced three times, you have no idea how it would be spelled phonetically. Your last interview question is the above question.

So yeah, you repeat what you've learned to be true.

And then get told you're wrong.

Realizing after spending the day there, that you could consider this to be a future you would do well in, you do something out of character. You insist you're right, and that you know you're right.

That wasn't 100% appreciated. Especially since this guy makes a living writing new tools for the OS group. But again, you know you're right, and besides, when it really comes to passing a pointer or a reference, if the intended effect is changing the lvalue, there's not really a difference. As the C++ FAQ states, use references when you can, use pointers when you have to.

Fantastic, no?

He wouldn't budge, and I would't budge either. I wiggled a little. Finally, he seeing how I was so insistant that I was right, and compared to him I was still wet behind the ears, he said "What did you do, look it up?"

At this point, I wanted to do something: "Hell yeah I did. That's why I know I'm in the right, and you're in the wrong. And if you'd spend 30 seconds to google this, with me here in the room, you'd know you're wrong too. "

Instead I continued to writhe in the agony that is: Why do interviewers ask questions where they don't have the right answer for?

Now, for all intents and purposes, this company has an interpreted language that runs on a virtual machine that is just killer for both rich client applications and internet applications. Think Java in almost every way, but with that sweet, rich full flavor of being wholly owned by someone other then Sun Microsystems. This langauge also garbage collects, so pointers don't really exist. You only have references.

I guess the point of this post is two fold. One is a personal point, one is a more general, academic point. The first is that it really sticks in my craw when I'm right and that does nothing to contribute to a situation. Like when you get head to head in programmer jepordy with another narcissitic, arrogant console cowboy like yourself but can't really drive your point home for the win.

The second point is that everyone that codes really needs to get to know their memory models a hell of a lot better. Garbage collection has become essential because of the pressure for rapid time to market. But garbage collection cannot turn a flawed or bloated implementation into a flawless implementation. Garbage collection can only work as well as it is implemented, and each object-tracking system has its negatives, such as overhead. But when I look back at how the memory model is taught in academia, if its taught in academica (most schools are transitioning to Java, thinking that a more modern language will improve their CS program. My undergraduate education in CS at pitt would serve to demonstrate that CS programs should stick to what they actually know.) is poor at best.

In the basic classes, a student is taught about how an object has an address and a value, and both reside in memory. In more in-depth classes, ones regarding architecture, one traces through assembly code and learns the basics of placing a register value onto a stack. But there's a huge discconnect between initiating a new object and the low-level assembly. Somewhere in the CS programs today there should be a section where the student traces the execution of a program and actually draws the execution stack. Discusses what a function frame (or whatever its called nowadays) looks like. Pitt didn't really seem to have anything at all like that; but then again, I spent more of my time focusing on hardware design.

I feel though that a decent CS program can convey a solid "big picture" even though the field is increasingly broad, without simply giving you the bits and pieces because todays technology field often requires to be well versed in a variety of technologies. But I still feel the need to stress that a deeper understanding of the fundamentals can allow a student to learn other existing technologies faster and better then if they only understand the examples and practice quizzes.