Programming Stories
Whenever I go to interviews, there is one area where I always bomb: the programming stories. These are the stories of “obstacles” I have overcome, “problems of scale” that I solved, “interesting” programs or algorithms. I am no good at telling stories, probably because I’m no good at on-the-spot recollection. I’m nervous enough as it is, and now they want to hear an interesting, compelling story about my work life? Scary, I know.
One of the more common approaches interviewers take with this question is to focus it on specific technologies. They want to know what you’ve done that applies to the languages and technologies that they know.
So I’m going to list a few of my stories here categorized by language/technology, for posterity mostly, but also to help anybody else out who has had trouble listing their accomplishments on the spot.
Javascript
The Project:
Tables. Datagrids. Spreadsheets. Everybody needs to build something like this at some point in their programming careers. I had to build a student grading spreadsheet recently (June 2011) at NYU. There were some weird custom calculations in the spreadsheet I was replicating, and I was told that the spreadsheet changes year to year. Great. So this will make teachers’ lives easier while making my life hell each year as they start sending piecemeal update requests every year (and multiple times in between I’m sure).
My solution was to build a revisioning form-builder which generates a spreadsheet view for the graders to enter values. It made sense for me to build it from scratch since we have a customized PEAR-based framework, and all the PHP & Javascript DataGrid solutions were either overkill or would be harder to implement than a custom-made Table-based spreadsheet.
The Problem:
It was imperative that the columns be resizable. Name fields need to be bigger than grade fields, and the table can have unlimited columns, therefore there is no single optimal sizing algorithm. Plus, these people are used to resizing columns, which means if I can enable that function I don’t have to worry about doing anything too fancy with a column width algorithm.
Unfortunately, nobody seems to have thought of a super-simple column-resizing plugin for jQuery. It was either über-datagrid or nothing. I did however find a fantastic little javascript snippet at a russian website which offered a script which did exactly the two things I needed: simple column resizing from any <th> field and callbacks with the column widths accessible (though not easy to find in that spaghetti code).
The Solution:
While technically I could just import that .js file and call its methods ad-hoc, I decided that using the base code I could create my own jQuery plugin. I’ve been in the process of moving each of the methods into the plugin itself, as well as tinkering with how the callback with the column widths array is delivered. Currently, you have to bind a function to the onchange event of the table you are changing the column of, and it feels like there should be an easier way to do this.
Code available at https://github.com/workwithnano/jquery-resizeColumns
Objective-C
The Project:
Silent Shout, a “note-passing” app for iPhones.
Our ideal workflow had the “options” page be the first page a user sees, and one that they return to often, so it had to be easy-to-understand, fun, and fast. In it, a user selects what “font” they want to use, what background the text should display against, and what “style” of presentation they want (their text can scroll like a marquee or fill the screen).
We decided that making the options hyper-visual would be the best way to go. There would be three rows of options that could be swiped left or right to select the desired option. The user would hit the “Next” button at the bottom right to move on, and their option choices would be stored for future use.
The Problem:
This was my first UIKit app, and as resourceful as I am, I couldn’t find any UIKit objects that would help me out here. This type of option-selecting mechanism had never been done before! Yikes.
The Solution:
With the help of StackOverflow, I managed to discover some helpful “photo-swipe” code snippets which made for a great starting point in my journey.
Ultimately, I created a UIView subclass which when fed an array of images & descriptions, would generate a swipe-able options menu that would store its current selection in the app’s preferences to be used in the “Shout” mode.
Code available at https://github.com/workwithnano/silent_shout
CSS
The Project:
http://elfpond.com. A single-page site dedicated to a wonderful musical performance in my basement. Yes, one of my most memorable undergraduate evenings took place in a basement. Many of them did, in fact.
The Problem:
We were pretty excited about the possibility of exploiting some awesome CSS3 stuff. Especially drop shadows. We felt it was high time that we take advantage of the box-shadow property, something which would make our lives much easier. The thing was, we were using a very strict grid, and if we wanted our shadows to extend past the boundaries of a box aligned within the grid, it’s not like we could just apply a background-image to it. It would get cut off by the box! We’d have to put boxes within boxes and rejigger the grid to accommodate the oversized shadows, and our lives would just be terrible.
box-shadow to the rescue! It could extend past the boundaries of a box, no problem.
Oh wait, problem. When we implemented these huge shadows to these huge video boxes, scrolling the page became an exercise in patience. Patience is one thing we “web builders” know our users aren’t expected to have much of.
The Solution:
Back to background images, of course! But how to implement? Well, I realized we already had “boxes within boxes”, since each video box would be one element within a larger “section” box (also contained in that “section” box were mini-menus and descriptions and such). Then I also realized that in each “section” box, there was only a need for a single large drop-shadow.
So, I realized, since we were using a very strict grid which guaranteed vertical and horizontal positions for each element, I could reliably place a drop shadow image as a background image in the “section” box, positioned directly behind the video box. Scrolling was now unbelievably faster, which was pretty important since you weren’t going to get very far if you couldn’t scroll down.
This post was graciously edited by Marc Ubaldi