Applying for a job? What we like to see

By Matt Daum | Leave a Comment on Applying for a job? What we like to see

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 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!

WordPress: Modify Native Calendar Widget for Event Post Types

By Jared Clapp | 7 Comments on WordPress: Modify Native Calendar Widget for Event Post Types

Recently I was working on WordPress website  and the client’s theme had an existing “Event” custom post type. The client wanted a way to calendarize the event start date and display with a widget.

There is a calendar widget built into WordPress; however, it has a couple shortcomings for what the client was trying to do. First, it calendarises all posts regardless of type (and in this case all we want is event posts). Secondly, it also calendarises posts based on date posted rather than a field such as event date.  As an added constraint, the non-profit client did not have a budget for building a custom plugin from scratch to fill the need.

So I went digging through the PHP script that powers the native calendar widget and found a way to modify the plugin while only having to bill about a half hour of custom development. It actually took me longer to write this post!

It’s not the most ideal or elegant solution but it saved the client a bunch of money by spending almost no time on this.  Couple drawbacks without further modifications 1) the widget won’t display multi-day events properly 2) The calendar widget now only works with event post types (i.e., can’t calendarize post dates of normal blog posts).

Here’s what it ends up looking like:

The Code

PHP

The file I had to modify is located in the WordPress 3.5 installation in wordpressroot>wp-includes>general-template.php

In order to know which days on the calendar to highlight as links to posts, the WordPress devlopers built a query that pulls the day numbers of the posts that were posted in the current month.

There’s a couple issues here as it relates to getting this to work for events as opposed to regular posts. First, the query is pulling post_type equal to “post” so we’ll need to change that “event” so only events are being pulled. Secondly, the original query is selecting posts based on post date in the current month.   For events, when we’re looking at a calendar, we don’t care when it was posted, but rather the start date of the event.

To deal with these issues, I had to rewrite the query. Unfortunately, the event start date field was one of the custom fields added for the event post type so it resides in the `wp_postmeta` table as opposed to `wp_posts so you have to join the `wp_posts` and `wp_postmeta` tables to get access to all the required fields.  The query returns the event start day of the month (dom) , post id (post_id) , url of the event (guid) and event title (post_title).  You’ll see soon why I pulled more fields than just the day numbers like before. Also, I changed the return value to an array of objects instead of numerical array per my own preferences. The new query looks something like this:

The next block of the original code (see gist below) executes a second query almost identical to the first, but instead of pulling just day numbers like before, it pulls the post id, post titles and day numbers. The block following the query goes through each post and puts the titles into an associative array indexed by the day of the month. The array of post titles ($ak_titles_for_day) will used to display the post titles on their corresponding day cell in the calendar when it builds out the calendar table.

Use of two queries seemed a bit duplicative to me since they are so similar so I got rid of the second one and pulled the additional fields in the first query.  Next I modified the foreach to record both the event title and event page url for every event post (this is so we can display a list of event links when a user hovers over a calendar day). I also consolidated the foreach code with the loop that follows the first query.  Based on the results form the first query, two arrays are built.  The first array, $dayswithpost, is simply an array containing all the day numbers of the month that have events to be used when building out the calendar table. The $ak_titles_for_day array, as mentioned above, is an associative array indexed by day numbers. It stores the event title and event url under the corresponding day number index and will be used to display to the user when they hover over a day number on the calendar that has event starting dates.

Lastly, the  code to build out the table/calendar had to be modified.  The original block of code compares the day number of the calendar cell being generated to the $dayswithposts array to determine if any posts are listed for that day.  If the day number has corresponding posts in the $dayswithposts array, an anchor tag is wrapped around the day number and href generated using the built in WordPress function get_day_link(). This function returns the url of an archive page for all posts on a given day. This works nicely for days with multiple posts because you can see all the posts by navigating to that daily archive url which is a built in WordPress template. The post title(s) for days with posts are also inserted into the title attribute of the day number link from the values stored in the $ak_titles_for_day array so the user will see the post titles when they hover over a calendar day link.

For events, a single anchor wrapped around the calendar day number would not work because clicking on the day would just take you to the archive page for events posted on that day not the start date of actual event day.  Therefore the code needs to be modified so that a user is able to click on each individual event title and have it link to the events page url instead of an archive page.

Instead of wrapping the day number in an anchor tag, I switched it to a span so it can be selected later by css/js.  Also, I created a <div> containing event titles and links for all the events for a given day and inserted it after the calendar number </span>.  In the CSS, I set the <div> to display:none, and position:absolute and positioned it relative to the <td> it resides in.  Then using jQuery I set a hover on both the <span> and the <div> so when a user hovers over a day with posts, you can display the <div> with the event links and titles.

JS and CSS

Tech: The 3 mistakes that doomed the Facebook Platform

By Ashish Datta | Leave a Comment on Tech: The 3 mistakes that doomed the Facebook Platform

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.

PHP: Does “big-o” complexity really matter?

By Ashish Datta | 8 Comments on PHP: Does “big-o” complexity really matter?

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.