4 posts tagged “code”
When I was in highschool I wanted to be a newspaper journalist. When I graduated from college I wanted to be a school teacher. But at this point programming has clearly won out as my lifelong career.
Relatively speaking, I think I've had a lot of technical interviews for such a short career. Before joining my current company, I'm pretty sure I had at least 10 programmer related interviews, including Google (twice), IBM, Computer Sciences Corporation, two Seattle startups (BList.com and Billmonk.com), and a company that writes the embedded code that is probably streaming and decoding the digital data in your home's digital cable box as I type...
After the more challenging technical brain-bending interviews, I'm amazed at how much I actually LEARN. Interviews have single handedly kept me from forgetting the details of big-O complexity analysis, and what the standard complexity cases are for most data structures and search types. They have provided huge insight into the basic nature of different types of search and data-manipulation algorithms.
For example, I made the same mistake in two recursive routines of trying to carry an entire Array data structure with me, instead of marking a global structure and then peeling off the marks when the recursion rolls back up. (fixed).
I'd forgotten so much about the nature of binary trees. I'd forgotten skip lists. I'd forgotten exactly how to implement a Hash in C. I don't think I'd ever known merge-sort before interviews...
The insight of how to intersect two sorted sets of integers by just reading each off the top, which I learned in my very first google phone screen, has been invaluably applicable in a number of problems...
I think toying with complexity analysis in interviews has actually taught me how to determine something is O(n*log(n)) way better than my class ever did...
My advice is to practice and interview as much as possible...don't interview at your dream job first. Make sure to just relax, no interview is the end of the world. Search for patterns in the nature of your solutions that you can reuse later. And make sure you remember the simple facts that you look stupid not knowing. (What's the complexity when searching a sorted list? O(log(n))...you get an instant F IMHO if you don't know that, and exactly why it is so).
A framework is kind of like a boat, your two happiest days are the day you get it, and the day you get rid of it.
A framework is supposed to be empowering. It's supposed to act as a launchpad, from which you can build upward, and the sky's the limit. This is Obj-C/Cocoa, or .NET, or Ruby on Rails. They are empowering frameworks.
Instead of a launchpad, an internal corporate framework often becomes a box. Too specific, and too presumptuous. The box is tricked out with fancy toys to make your life easier, so long as you stay inside. But if you want to tread new ground, you have to knock down the door and drag the rubble with you along the way.
It's frustrating to be working on a project and reach a point where the framework has locked you in. Something in the framework outside your control is working unexpectedly and because you don't have ownership of it there's nothing you can do about it. You could go ask the person that wrote it, and maybe they'll be kind or smart enough to see the problem and help you work around it...but the person may be out sick that day. Or the person may be too busy with other things. Or they may simply tell you that's too hard and you need to pull back on your program's requirements and ambitions..
Then again, if an internal framework can actually be a launchpad, it can be really sweet...exactly how a person views a framework may depend heavily on the current task at hand. ;o)
I like to keep my code very distributed. Fine grained atomic structure allows for better refactoring and DRYing possibilities...I'd say 300 is about all the lines of code I like one file to have before I feel that it's grown too large...
