GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS

We’ve been super busy lately - so we knew the time was ripe to bring a few more people onto the team.

We’re very fortunate to have found three excellent new people to add to the team, two new designers and a developer: Kyle Fiedler, Chad Mazzola, and Harold Giménez.

Adding two designers doubled the size of the design team and really increased our ability to get stuff done there.  It’s been fun integrating them into the team.

Harold’s first day is today, and we’re really excited for him to get started.

We’re still actively hiring developers and interns.  If you’re interested, please get in touch, instructions and more info are on our jobs page.

On a personal note, some of you may know that 3 years ago I moved from Boston to Philly.  While we’ve managed the maintain the long distance relationship, its with great enthusiasm that I’ll be moving back to Boston on May 1st.

Also, Nick Quaranto will be graduating and joining us full time in Boston in June.

It’s an exciting time of transitions and new additions for the team, and we’re definitely looking forward to the future.

Our hiring process has been continually refined over the 7 years we’ve been in business to reflect the needs of our team, the lessons we learned along the way, and the changes in the candidates we see.

In this post I’ll go through our hiring process, note places where we’ve seen changes, and hopefully answer some common questions.

It’s worth noting that we’re currently actively searching for both a new Designer and Developer.  If you’re interested, I hope you’ll get in touch.

The History

When we first started out, we were smaller and we didn’t focus exclusively on Ruby on Rails.  So our decision-making process for hiring new people was necessarily different.

At first, I’d basically talk to people a few times, meet them in person, and make the decision about whether to hire or not largely on my own, with consultation from Jon when he was available or when I thought it was particularly necessary.

Now that we’re a bit larger and have a well qualified team we involve the rest of the team in the decision making process to ensure that the people we’re hiring have been agreed to by the team.

We do this because having a cohesive team is incredibly important to our overall culture and attitude.  We want to make sure that everyone will work well together to uphold our high standards.

Also, because we used to use a variety of different technologies our requirements were in some ways more loose, and in some ways more strict.  For example, we didn’t use Java on every project, but that meant that if you were being hired as a Java programmer you’d be working with particular clients on particular projects.  You needed to be able to perform well on those specific projects as well as just demonstrate a technical aptitude.

Back then, we also didn’t have the standards and practices we do now.  We didn’t write automated tests, we used many different frameworks, and we weren’t as particular about the projects we took or the kinds of people we hired.

When we switched to Rails, that was our chance to push the reset button on our standards, including our hiring process.

We established that we would do test driven development, run continuous integration, more strictly follow agile methodologies and hold ourselves to a higher standard.  Necessarily, our hiring practices needed to change to match this.

The Current Process

We ask all development candidates to provide us with information about them and a code sample as part of the initial contact.

After reviewing the code sample and their resume and cover letter, we decide whether we’ll do an initial interview with them.

We used to only ask for a code sample after the initial interview and before the second, technical interview was already scheduled.  However, after a few candidates who would have never gotten through to the technical interview had we seen their code first got through, we decided to ask for this and evaluate it up front.

The initial interview is either by phone, video chat, or in person based on their capability and location.  This initial conversation isn’t technical at all.  Its a chance for us to hear in their own words what their experience is and for us to give some insight into thoughtbot, how we operate and where we’re going as a company.

If this initial interview goes well, then we’ll ask the candidate to do a technical interview with other members of the team (same for design candidates).

The technical interview is usually with two people, we review the sample code (or designs) ask them questions on that, and also ask a series of more technical questions.

We have some technical questions that we’ve come up with and revised over time.  With these questions we try to judge core technical competency rather than just being up to date on the latest plugin or buzz-word (though those are also things we consider).

For candidates who we think might be a good fit after the technical interview, we then invite them to come and work in our office for a week, for which we pay them for their time.

This week-long trial, particularly for remote candidates, is as much for us as it is for them.  We want to make sure that everyone involved is a good fit before the big decision.

During this week-long trial we try to get them interacting with each member of the team and try to give them as accurate a picture as possible of what its like to work at thoughtbot.

Things We Can Improve

As with any process, this one continues to evolve, and there are certainly areas that we can improve.

We used to do a really terrible job of keeping track of potential candidates throughout the process, particularly in notifying people of a no-hire decision.  We now do a less terrible job by using Wufoo to take submissions in a standardized form and Highrise to keep track of people, but we could stand to do an even better job with this.

As I mentioned above, our technical interview questions try to strike a balance and identify strong core technical competency rather than just being able to spout of the latest buzzwords or familiarity with a specific plugin.  However, our questions could probably try to work with more practical knowledge rather than computer science topics.  We’ve recently made some changes here already, and focus more on the sample code they’ve submitted, but we continue to refine.

Like all things we do, we also don’t want our hiring process to be a burden.  We are a small team with lots of responsibilities.  If anything we do becomes a burden on anyone involved it’s not working.

One problem we were having was that the number of low quality candidates we were receiving took a lot of time to screen.  To help with this problem, we’ve started to avoid posting to job boards right away.  Instead, we’ve focused more on trying to find qualified candidates through networking and directed advertising to more focused groups.  Then, if  we haven’t found someone through those circles, doing a broader search.

Our goal for our hiring process is to find people that will be a good fit with the team and who will do a great job with the kind of work we do.  Our process has been honed over time to hopefully become a useful tool in identifying the right kinds of people for us.

I’d love to hear what you’ve liked or disliked about either side of the hiring table you’ve been on.

The simple fact of the matter is that we care too much about the quality of what we do and the environment in which we do it in.  That’s why, for a few years now, we have not subcontracted for other people and we have not subcontracted out any of our work.

Subcontracting for other people

After a few failures working in a situation where we are subcontracting for somone else we realized that because we didn’t have a direct responsibility to the end customer, and very often no direct lines of communication, we were not able to properly introduce them to our way of working and to properly set expectations.  When we were left to communicate through someone else in order to ask questions, talk about deadlines, etc. there is the danger that it’s not being told like it needs to be told in order to properly set expectations.

In addition, in a subcontracting situation, you are often beholden to a third party for invoicing and collection.  We invoice our clients on a weekly basis, with Net 15 terms.  All too often, when we didn’t have direct access to the end customer we were left waiting for our invoices to be paid while the person we were subcontracting for waited for their client to pay them.

We are in the business of working on successful software projects. We are tenacious about identifying things that aren’t working for us and stopping doing them.  Every once in a while, we identify something like this that becomes a real core principle to the way we work.  These principles, or rules, stand as guidelines to remind us what we need to do in order to ensure success.

Subcontracting out work to others

We also had several instances where subcontracting out work to others didn’t quite work out, and so have stopped doing it.  Everyone who works for thoughtbot is an employee and we don’t subcontract any work out.

One of the main reasons why we don’t do this is that we found it difficult to maintain our high level of expertise and quality when we were subcontracting.  Additionally, we care very much about the environment and comraderie among the team.  In cases where the expertise may have been great, its still hard to integrate that person into the culture of the team, and the contractor is ultimately always an outsider.

I know many firms find themselves subcontracting work that is not their core area of expertise out to other firms so that they aren’t turning away work.  I’d rather turn away work than take projects which aren’t a good fit for us.  If there is a component which isn’t quite right for us, we assist the client in making a relationship directly with someone else to do the work above, for the same reason that we don’t subcontract for people.

Also, working within our core expertise has allowed us to become experts at what we do, which has so many more benefits than the extra revenue we may get by being able to take on and subcontract Flash work.

Breaking the Law

Because these rules are there to guide us, of course there may be situations where we might subcontract for someone or subcontract to someone (there hasn’t been in quite some time) if we try to make the relationship directly with the end customer and subcontracting is the only way we can work, but we think the project might be good anyway.  The rule causes us to remember why we created it in the first place: 1) lack of direct access to the client 2) dependency on a third party for invoicing and collection 3) inability to integrate subcontractor onto the team 4) problem maintaining high level of quality.  If we can subcontract and still work around those key sticking points, then so be it.  However, at least we are then making the active decision. We’ve thought it through and decided that the project can be successful in spite of it, rather than just blindly taking any and every project and praying for success.

thoughtbot is hosting the Great American Hackathon at our Boston office today and tomorrow. The focus of our group is on transportation data from the Massachusetts Bay Transportation Authority (MBTA).

Like many other government agencies, the public loves to trash the MBTA for its actual and perceived failures while simultaneously taking advantage of its services at levels of about 400 million riders a year. In response, the agency’s knee-jerk reaction has been to historically be less transparent.

I believe it is important as application developers to support an effort underway by the agency to reverse that trend. We have a window of about a year (until November, 2010) to show government officials what is possible when they provide open data to the public.

Here’s my current understanding of the lay of the land and some ideas of things to hack on.

who’s who?

MassDOT was created November, 2009. It combines almost all transportation departments in Massachusetts, such as:

• Registry of Motor Vehicles
• Highways
• FastLANE

The T (MBTA) still has a complicated legal relationship with MassDOT. They are kind of semi-private. I imagine them as similar to the Federal Reserve or The Pentavirate.

The main real-time data provider is a vendor the government has hired, NextBus.

outreach

The main resource for developers is the MassDOT Developers Page. There’s also a Twitter account, regular monthly meetings with developers, and occasional contests:

This was the winning visualization from a contest last month.

the pilot program

For our purposes, the main thing we care about is real-time XML feed they are providing as part of a one year pilot program. It is possible that feed will be turned off November, 2010 if developers don’t create anything interesting or Those Fatcats don’t see value in transparency.

Legally, they are required to follow a particular procurement system.

Cannot change length of the procurement process but developers and the press can push for more lines to open up.

what data is available?

There’s static data and real-time data.

static data

The static data is available on the MassDOT Developers page. The current zip file is from December 2:

The data is in Google Transit Feed Spec (GTFS) format, for interesting reasons. The Federal Transit Administration been holding meetings about standard data formats for a long time, then Google came along and just did it. Now pretty much every agency (the MBTA in Boston, the MTA in New York, etc.) can export into GTFS.

Some of the other data such as station locations and routes is in Keyhole Markup Language (KML) files.

Perhaps the best way to explore this data is through danchoi/openmbta, an open source Rails app and iPhone app. Some of things it contains are:

• stops for vehicles (“Alewife Station”, “Broadway Station”, “Cleveland Circle”, etc.)
• data for subways, buses, ferries, commuter rails

The app is live at OpenMBTA.org.

real-time data

Real-time data is what everyone is interested in.

MassDOT Highways have a daily XML feed for planned construction events, answering the question, “which roads are closed?”.

The Registry of Motor Vehicles has a branch wait-time XML feed.

The MBTA has a services advisory and updates RSS feed.

The Granddaddy feed everyone is excited about, however, is the MBTA real-time XML feed.

The trial feed includes data for bus route 39 which serves Jamaica Plain, the Longwood Medical Area, and Back Bay in Boston; and bus routes 111, 114, 116, and 117 which serve Haymarket Station, East Boston, Chelsea, and Revere.

example vehicle location request/response

Request:

http://webservices.nextbus.com/service/publicXMLFeed?command=vehicleLocations&a=mbta&r=39&t=1258125794429

Response:

what apps are people building?

Wait time prediction. This one works but it’s interface is… not good. This Mac OS X widget looks better but it’s… a Mac OS X widget.

Currently, a major problem as I see it with this kind of app is that NextBus is a vendor with a patented, proprietary system for calculating the wait time. If the MBTA switches vendor or this genius system turns out to suck, customers of a wait time app will be pissed.

I’d like to see this data supplemented with user-generated content (was the train late or on time?) or see people write their own, open source algorithms based on lat/long, stops, times, rush hour traffic, whatever.

Vehicle location. This one is nice & simple. We haven’t seen the ultimate interface for this, however. The cream of the crop is currently the CTA Bus Tracker in Chicago.

what other apps could be built?

Tap out. Unlike, say, the London Tube, the T is a “tap in” system. Riders don’t have to tap out to leave the system. Therefore, developers and trend analysts are limited in their data sets of how people are using the T. A mobile app could be built that allows riders to “tap out”, simply there to built up the data sets.

Between stops API. A very simple API could be layered on the real-time NextBus data that says which stops the next vehicle is between. This could turn out to be a more accurate prediction for certain riders, particularly commuters who are familiar with the line.

Demographics. One thing that isn’t clear for application developers is: who is the customer?. For something as broad as public transportation, there is a wide variety of users, such as:

• college students
• the eldery
• the handicapped
• daily commuters
• tourists

They all could have very different needs. A simple user-generated application to build demographics associated with each line could be very useful for developers of future applications. For example, I ride the Red Line and the 1 bus. I know when commuters to downtown Boston ride it, when MIT and Harvard students ride it, etc.

where to go next

Sign up for the MassDOTDevelopers Google Group.

Talk to local news stations like WBZ, NECN, WBUR, Fox 25, and boston.com. They already add value to the government data by flying helicopters, watching traffic cameras, and passing that along to their customers. There’s potentially more data at those businesses that could be added to the mix. A company called Smart Route Systems is often the point company for those news stations.

Join us today and tomorrow at our Boston office as we hack together an app or two!