3 posts tagged “programming”

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).

From my way of looking at it, there are 3 major "languages" in play on the client-side of websites.  The server-side can have about 400trillion variants, but the client side is much more limited.  We gots HTML, CSS, and Javascript.  Those 3 technologies combined make up all the webpage content on every page on the web (minus proprietary plugins that are themselves just scaffolded in html, such as flash/virtools/flex etc...and maybe some old vbscript lying around (shudder)).

I'm gonna cruise right past 2 of them, because in my opinion they are adequate.  HTML and CSS.  HTML has been relegated to a fairly simple scaffolding role, and CSS is sweet (if browsers would fuckin implement properly).

That leaves one ugly duckling: Javascript.  I'm sure the committee that first made EcmaScript never dreamed it would transform into such a poorly-named, disparate and ugly mess.

Javascript needs a successor, or an overhaul, or to be taken out back and shot (works for me).  Javascript fills in what i'd call the "logic" part of the client-side controller/view layer. (the controller layer i think is split across the net now...some on server, some on client...i'll write about that later).

Of the logic your browser is performing, there's 3 (the little 3) aspects that I think are fundamental.  There's the language itself (Javascript), the method to communicate with the server, (AJAX), and the interface to control the CSS/HTML on the page on the fly (DOM).  The point of all 3 are really to make things happen in the browser without having to travel across the web and fetch a whole new page from the server.

We need a new 3.  Javascript/AJAX/DOM won't do.  We need options.  These 3 all suck.  They are not filling their role nearly as elegantly and CSS/HTML.

There's lots of ugly crap in browsers.  And all that ugly inconsistent crap certainly slows down developers and makes life hard, but it's not insurmountable.

The one truly insurmountable and heavily limiting fact of browsers revolves around security (or implicitly, trust).  When I want to get you (as the "client" computer), to interpret my code and display my "program", you are extremely persnickety in what you'll let me do.  You might trust me COMPLETELY, I might be your brother, but your browser is still going to distrust my code...the best you can do is maybe let it enable pop-ups. ;o)

Basically, code can't read from, or write to your operating system.  It can eat up 100% of your cpu, but touching the FS is a no-no (except for the very limited environment for cookies (or flash's "shared-objects", which i bet are treated as cookies under the hood).  Also, code can't run unless it's javascript, and code can't execute other apps already on your computer.

These are the fundamentals limitations that come from a lack of trust.  Why not enable the user to say, "look, i'm not an idiot, i KNOW this site isn't going to screw me over, so let's trust it completely"...we basically say that same thing all the time when we download shareware applications and try them out...we are completely trusting the developer not to trash our system...

This would really open up the door to Rich Internet Applications.  There'd be so many new options I hardly know where to begin...(beer time, maybe more later).