Category: General

We recently just finished hiring another engineer for our team (welcome Jared!), during which we’ve seen quite a few different applications and it also led to http://shout.setfive.com/2013/05/07/recruiters-before-you-call-do-a-little-research/">my previous post about what we’d like to see recruiters do before contacting us.

While I am certainly no hiring expert, I think some of the following points may help people applying for a job out.

Read the Full Posting

Many job postings, including ours, will include details about what they want to see from any potential candidate. I've seen everything from a simple put in the subject "XYZ" to answer the following programming questions. On some of our job postings we include something like include your favorite beer, the best place you've vacationed, etc.. These questions aren't only used to weed out spam, but we like to see what people come up with and to see if they are a good fit. Regardless of what the posting request is, it's important to fully read it and apply properly. Several potential candidates didn't read ours in full and didn't follow the simple application instructions. If you don't follow the instructions it can reflect poorly as it may indicate you aren't able to pay attention to details.

Shorter Can Be Better

I remember back in college when working on resumes many advocated "keep it to a single page"; I can't agree more now. I've received some resumes that are over 6 pages long. A resume, in my point of view, should be something that bullet points your skills, experience, and education. Most of the time, you can fit all this information on to a single page. Being clear and concise pays its dividends. I'm much more interested in the resumes that I could briefly look at and get a good feeling about the candidate. The long resumes often spent a half page to page summarizing some activity at a previous job; it's much easier to inquire about a specific experience you have if I don't understand it.

Keep Programming Languages Short

One thing I saw on an alarming number of resumes was that someone would list 10+ programming languages as their core languages. I'm all for having basic knowledge in multiple languages, but I wouldn't list all the languages I've ever worked on as my core language.

The long lists (java,python,php,ruby, perl, c++, c# and scala), more often on recent graduates, seemed more like a list of languages the candidate knew existed. Understandably, right out school you may not have a specific language that you have an in-depth knowledge of. In this case, I recommend looking up what language the job position that you are applying for is, and list that and one or two others that compliment it (such as PHP, Javascript, SQL) rather than listing everything you’ve ever worked in. I gave much more attention to candidates who applied with fewer languages and then listed a few projects/concepts they did within each language.

Past Projects, Not Classwork

One of the last points I want to touch on is when people want to know past projects you've worked on. What I'm looking for is something to just show that you can put all the programming concepts you've learned together to form some sort of project. Whether this is a simple side project you had or something you worked on at your last job, it shows you are able to take some theory and apply it to realistic applications. Often at career fairs I'd get 30 resumes all which list the exact same project, which was an assignment from class. While coming straight from college you may not have many side projects, have at least one (or make one), and list it first. By having at least one side project that you've built (or been a major part of), it shows that you're able to take what you've learned in theory and apply it. Classroom assignments are often "fill in the blank" or too rigid, follow these exact instructions, to demonstrate your full capabilities.

While these are only some of the points I look for on incoming applicants, they are extremely important. Let me now if you think I’ve missed a few!

Good luck on applying to your next job!

Yesterday afternoon, PandoDaily’s Hamish McKenzie published a post titled Move fast, break things: The sad story of Platform, Facebook’s gigantic missed opportunity. The post outlined the lofty expectations and ultimate failures of the Facebook Platform. Central to Hamish’s piece was the thesis that a series of missteps by Facebook alienated developers and eventually pushed the platform into obscurity.

With the benefit of hindsight, I’d argue there were actually only three major mistakes that ended up dooming the Facebook Platform.

Lack of payments

Hamish mentions this, but I think the lack of payments across the platform was the source of many of its problems. With no seamless way to charge users for either "installs" themselves or "in-app purchases", developers were forced to play the eyeball game and as a consequence were left clinging to the "viral loop". Facebook Credits ended up being a non-starter and as the Zynga spat demonstrated, the 30% haircut was intractable. In a world where Facebook launched "card on file" style micropayments with the Platform, maybe we'd be exchanging "Facebook Credits" at Christmas.

No sponsored feed placements

Without on platform payments, developers were essentially left chasing Facebook's "viral loop" to drive new users, eyeballs, and hopefully eventually revenues. Developers eventually started gaming the system, generating what users perceived as spam, and ultimately forcing Facebook to change notifications. I'd argue that had developers originally had some way to pay for sponsored feed placements they would have been less likely to chase virility. Along with the functionality to sponsor feed posts, Facebook undoubtedly would of ended up building rate limits and other spam fighting measures in order to protect the "sponsored post" product and ultimately helped the platform.

Everything tied to Connect

Even today, one of the most popular components of the Facebook Platform is the Connect single sign on piece. The problem was, and to some extent still is today, was that everything was tied to Connect. Even if you were just logging into a site with Connect, it still had access to your entire Facebook account. Facebook eventually fixed this, but it opened the floodgates of every site posting unwanted updates, breaching user trust, and hurting the credibility of the entire platform.

The PandoDaily piece has a deeper exploration of what drove the decline of the Facebook Platform but I think lack of payments, sponsored feed posts, and the tie in with Connect put the platform in a difficult position from day one.

Last week, a client of ours as us to look at some code that was running particularly slowly. The code was powering an autocompleter that searched a list of high schools in the US and returned the schools that matched and an identifying code. We took a look at the code, and it turns out the original developers had implemented a naivete solution that was choking up since the list had gotten to ~45k elements and I imagine they had only tested with a dozen or so. During the process of implementing a slicker solution, we decided to benchmark a couple of different approaches to see how much the differences in “big-o” complexity really mattered.

The Problem

What we were looking at was the following:

• There is a CSV file that looks something like:

ID, STATE, SCHOOL NAME
2,NMSC DEPT OF ED & SVCS,IL
3,MY SCHOOL IS NOT LISTED DOMEST,NY
4,MY SCHOOL IS NOT LISTED-INTRNT,NY
8,DISTRICT COUNCIL 37 AFSCME,NY
20,AMERICAN SAMOA CMTY COLLEGE,AS
81,LANDMARK COLLEGE,VT

With data for about 45k schools.

• On the frontend, there was a vanilla jQuery UI autocompleter that passed a state as well as “school name part” to the backend to retrieve autocomplete results.
• The endpoint basically takes the state and school part, parses the available data, and returns the results as a JSON array.
• So as an example, the function accepts something like {state: “MA”, query: “New”} and returns:

[
  {name: "New School", code: 1234}.
  {name: "Newton South", code: 1234},
  {name: "Newtown High", code: 1234},
]

The Solutions

In the name of science, we put together a couple of solutions, benchmarked them by running them 1000 times and calculating the min/max/average times, and those values are graphed below. Each of the solutions is briefly described below along with how they’re referenced in the graph.

The initial solution that our client had been running read the entire CSV into a PHP array, then searched the PHP array for schools that matched the query. (readMemoryScan)

A slightly better approach is doing the search “in-place” without actually reading the entire file into memory. (unsortedTableScan)

But can we take advantage of how the data is structured? Turns out we can. Since we’re looking for schools in a specific state whose name’s start with a search string we can sort the file by STATE then SCHOOL NAME which will let us abort the search early. (sortedTableScan)

Since we’re always searching by STATE and SCHOOL NAME can we exploit this to cut down on the number of elements that need to be searched even further?

Turns out we can by transforming the CSV file into a PHP array indexed by state and then writing that out as a serialized PHP object. Another detail we can exploit is that the autocompleter has a minimum search length of 3 characters so we can actually build sub-arrays inside the list of schools keyed on the first 3 letters of their name (serializednFileScan).

So the data structure we’d end up creating looks something like:

{
...
  "MA": {
  ...
   "AME": [...list of schools in MA starting with AME...],
   "NEW": [...list of schools in MA starting with NEW...],
  ...
  },
  "NJ": {
  ...
   "AME": [...list of schools in NJ starting with AME...],
   "NEW": [...list of schools in NJ starting with NEW...],
  ...
  },
  "CA": {
  ...
   "AME": [...list of schools in CA starting with AME...],
   "NEW": [...list of schools in CAA starting with NEW...],
  ...
  },
...
}

The results

Running each function 1000 times, recording the elapsed time between results, and calculating the min / max / and average times we ended up with these numbers:

test_name	min (sec.)	max (sec.)	average (sec.)
readMemoryScan	.662	.690	.673
unsortedTableScan	.532	.547	.536
sortedTableScan	.260	.276	.264
serializednFileScan	.149	.171	.154

And then graphing the averages gets you a graphic that looks like:

The most interesting metric is how the different autocompleters actually “feel” when you use them. We setup a demo at http://symf.setfive.com/autocomplete_test/ Turns out, a few hundred milliseconds makes a huge difference

The conclusion

Looking at our numbers, even with relatively small data sets (<100k elements), the complexity of your algorithms matter. Even though the actual number differences are small, the responsiveness of the autocompleter between the three implementations varies dramatically.

Anyway, so long story short? Pay attention in algorithms class.

Hope everyone is having a fantastic 4th of July. Make sure to drink some brews and eat some BBQ!

We’ve been using CSS preprocessors for some time now but it wasn’t until recently that the reasons for using them really started coalescing for me. CSS preprocessors, like LESS or Sass, basically allow you to write CSS in a more powerful intermediate language which is then compiled down to normal CSS. Like a lot of developers, when I first started using LESS I had some reservations about introducing another layer of abstraction to our development stack. However, after developing a few reasonably sized projects with LESS I’m convinced that using a preprocessor is probably a great idea for many types of projects.

Avoiding the LESS vs. Sass discussion and looking at preprocessors as a class of tools, the clearest benefits are more expressiveness and better reusability.

More expressiveness

As a language, CSS is amazingly straightforward, it basically consists of selectors and rules which are written in flat, plain text files and then combine to style your HTML. Since there are no constructs for variables, conditionals, or functions writing CSS is simple - just fire up and editor and start making changes. The ease of writing and understanding CSS is certainly a benefit but it comes at the price of sacrificing how expressive the language can be.

Using selector specificity as an example, the benefits of the preprocessed files are clear.

Using regular CSS you might end up having rules that look like:

/* From http://lesscss.org/#-nested-rules */

#header { color: black; }
#header .navigation {
  font-size: 12px;
}
#header .logo {
  width: 300px;
}
#header .logo:hover {
  text-decoration: none;
}

Versus the corresponding LESS:

/* http://lesscss.org/#-nested-rules */

#header {
  color: black;

  .navigation {
    font-size: 12px;
  }
  .logo {
    width: 300px;
    &:hover { text-decoration: none }
  }
}

Looking at the two examples, the LESS uses its structure to express how the nesting rules work and because of this has a higher information density than the regular CSS.

Another common issue where increased expressiveness is helpful is in writing semantically meaningful CSS class names. With regular CSS, the tendency was to normally end up with CSS rules that end up looking like:

.btn-blue {
  color: #fafafa;
  background-color: linear-gradient(top, #1e5799 0%, #2989d8 50%, #207cca 51%, #7db9e8 100%);
  border: 1px solid #2F3DA8;
  padding: 5px;  
}

.btn-red {
  color: #000;
  background-color: linear-gradient(top, #a90329 0%, #8f0222 44%, #6d0019 100%);
  border: 1px solid #2F3DA8;
  padding: 5px;  
}

The trouble of course being that the CSS class names are tied to their physical appearance as opposed to what they actually mean in your app. Although its possible to write semantic class names in vanilla CSS, the difficulty arises when you’re trying to uniformly apply things like colors, padding, and borders across a range of elements. Without variables and mixins it becomes significantly harder to manage or change these semantically named classes. Looking at how Twitter Bootstrap defines buttons, its clear how much more expressive the declarations are by keeping the colors in easily changed variables:

/* https://github.com/twitter/bootstrap/blob/master/less/buttons.less */

.btn-primary {
  .buttonBackground(@btnPrimaryBackground, @btnPrimaryBackgroundHighlight);
}

// Warning appears are orange
.btn-warning {
  .buttonBackground(@btnWarningBackground, @btnWarningBackgroundHighlight);
}

// Danger and error appear as red
.btn-danger {
  .buttonBackground(@btnDangerBackground, @btnDangerBackgroundHighlight);
}

Better reusability

Another benefit which preprocessors introduce is better code reusability. Although CSS has imports, the amount of code which you can functionally reuse is pretty limited since existing rules can’t be included into new ones. The best you can really hope for is being able to reuse a common stylesheet across projects. Comparatively, preprocessed CSS offers mixins and functions both of which foster more reuse.

Some of the best real world examples of this are in the Twitter Bootstrap mixins.less file which includes mixins used throughout the framework. Additionally, projects that build upon the Bootstrap framework would also be able to leverage any functions or mixins Bootstrap defines further increasing reuse.

Anyway, looking at the benefits compared to the overhead of involving a preprocessor I think for any reasonably sized project you’d almost always be better of developing with one. It’s obviously going to come down to the specific project but I’d be interested in hearing everyone else’s opinion.