Want a Job? Show Me Your Code.

2011-09-18T08:43:00-04:00

Want to get a programming job? The most important thing during the interview process is not a resume; it's the code you've written.

I've been conducting interviews for a handful of companies including thoughtbot and a handful of our clients. The first thing I do to gauge a developer isn't look on his resume for where he went to school or his previous employment, and I definitely don't look to see what languages or technologies in which he says he's proficient. I look for code. I look for Ruby gems he's authored, a Github account, contributions to open-source, or a development blog.

Mind you, the code could be sub-par, the gems completely unuseful to me, or the blog posts written for beginners, but that's besides the point. All of these are ways that demonstrate passion. If a developer really cares about his craft and really loves programming, no matter what sort of social obligations he has, he will write code outside of a job or outside of school. If he contributes to open-source software, it not only means that he probably uses what he's contributing to, but he's also aware of shortfalls of the tool and wants to improve it. Passion - that's what I look for when I'm looking to hire someone.

Obviously code quality, programming practices, personality, and a slew of other aspects come into play when hiring developers, but having publicly-available code is about the simplest litmus test I do. Without that, I'll typically not even consider the developer.

Structuring CSS Intelligently

2011-09-13T00:18:00-04:00

Signal vs Noise just did a writeup about CSS, the cascade, and some of their latest and greatest styling notes. Although some of the advice is sound (SCSS is great), recommending that the CSS explicitly mimic the DOM structure is a horrible mistake.

As Jason points out, one great thing about CSS (and also the part that can shoot you in the foot) is the fact that styles cascade. This (apart from the box model) is, in my opinion, one of the hardest things to grasp about CSS. If you don't understand how selectors work, how to manage specificity, and how to maintain a structured set of CSS rules, it becomes a giant pain to manage a relatively small site.

In the end, I think the key here is to use modularity to your advantage. Programmers do this all the time - we break up various pieces of code that behave the same and abstract them out into a single reusable piece that can be reused throughout the application. Markup (and subsequently CSS) can be thought of in a similar manner. If you have a chunk of content that follows a certain set of guidelines (content with a header, possible sub-header, and one or many paragraphs), and that style is used in a couple of different spots (maybe with an unordered list instead of a paragraph), start to recognize a structure and build styles on reusable containers of code.

Suggesting that the CSS mimic the markup is virtually as bad as inlining the CSS. Instead, use a semantic class name describing the content and style that one chunk of markup in the manner you'd like.

I personally try and stick with simple selectors (one class name, maybe two at the most) and never go more than four or five levels deep. This helps keep the selectors themselves from getting way too long (html body div.container header#page-header h1.welcome, anyone?) and makes things much easier to maintain.