Two years ago I wrote a series called Mining Jobmine that explored data from Waterloo's co-op job postings. It came as a surprise to find this analysis useful for myself. This post highlights how I used the results from that analysis to write our job posting, and how my startup Polychart hired our first two University of Waterloo co-op students.
What The Data Said
There were three main learnings from the Mining Jobmine analyses that were applicable. First is to keep job postings short, as data showed that shorter job postings attract a higher number of applicants. The second is to focus on describing the company and the role, rather than the ideal candidate. The third is to avoid using "ought" words. Both of these correlate to application levels.
What The Data Said
There were three main learnings from the Mining Jobmine analyses that were applicable. First is to keep job postings short, as data showed that shorter job postings attract a higher number of applicants. The second is to focus on describing the company and the role, rather than the ideal candidate. The third is to avoid using "ought" words. Both of these correlate to application levels.
Our Job Posting?
We kept our job posting to around 200 words. We described the company and the role, and while we did use some "ought" words -- well, I couldn't resist it. We also added a little bit of humour that ideal candidates would appreciate (but would confuse non-ideal candidates), and a link to our product and demo -- because who wouldn't love working on a slick product?
This was our job posting:
This was our job posting:
Polychart is a startup in the KW region building a really cool, drag-and-drop data visualization tool. We are looking for a software co-op to speed up our roadmap. See our website at http://polychart.com/ and our demo video at https://www.youtube.com/watch?v=tbvx90KDouY for what we have to date.How did we do? Well, although no one wanted to show us their social media profiles, we did receive 55 applications for 2 advertised positions. Compared to startups and companies our size, we've done very well.
You will be writing code (surprise, surprise!). This includes adding features to Polychart, testing said features, and releasing it to users. Because we're a startup, you will play an important role in the development team, have a huge impact on the company, and learn a TON.
The ideal candidate will have some non-school related experience in software development, preferably web development. Specific technologies we use include:
- the usual web stuff like HTML, less/CSS
- a ton of CoffeeScript/JavaScript, JQuery, Knockout, Raphael
- Python/Django/Tornado
- MySQL and likely other databases
- git and github
- linux
Bonus points if you have some experience in statistics, have an opinion on pie charts, and on vim vs emacs.
You should be able to reverse a linked list.
Please include in your resume your github account, twitter profile, and other relevant social media profiles. Also, please talk about projects you've done outside of school. Don't write a cover letter unless there is something not in your resume you'd like to talk about.
The Rest of the Hiring Process
First, we had to screen the 55 applicants. The goal of the first screening is to see if there's a chance an applicant can code. A whopping 25 of them did not appear to fit the bill -- these were sometimes students from other faculties with no programming background. We didn't discriminate against first and second years, and were more lenient on those with higher GPA's.
Those successfully passing the first screening received the following programming challenge:
The goal of this challenge is to find the index of a given word in a dictionary [alphabetically sorted listed of words]. The only way to interface with the dictionary is through a function `lookup(index)`, which either returns the word at that index, or `false` if the index is out of bounds. Words are represented as strings. The indices of the dictionary are a contiguous set of non-negative integers starting with 0.We chose this problem because it is short but difficult to find the solution through an online search. If you are able to google a solution then you probably know a thing or two about algorithms and will meet our requirements anyways. I advised applicants not to spend over an hour on it. Around 25 out of the 30 applicants responded with a solution. Less than half of them did reasonably well.
Please write your solution in either JavaScript or CoffeeScript, and include in your solution:
- The code
- A brief description of your solution, and why it is (or isn’t) the most efficient
- How you verified that your code is correct
- How much time you spent
While the puzzle helped to determine who did and did not know how to code, there were many candidates that had a plausible solution that had one or more areas of improvement. We probably weighed the code quality a little too much, since those without perfect solutions ended up doing just as well (or better!) in the interviews.
We only interviewed with 9 candidates to give each interview 40 minutes. This is to have ample time to sell the position to students, and to make sure not to run over time. We also advised students not to dress up for the interviews. We found out later that little gestures like that really helps students.
Because we already had students' solutions to puzzles, I wasn't sure whether asking additional technical questions was necessary. They were. Those with near perfect, textbook solutions to the puzzle tended not to do as well when asked to code quickly. (And yes, I brought a laptop for candidates to type on, again to make their lives easier.)
The end results were hires whose background and history either resonated with or complimented ours (diversity is very important). We're very excited to have both of them onboard!
Polychart is Hiring!
We are looking for a Director of Engineering to bring on as a partner -- a technologist who sees the potential in Polychart and wants to build a great company with us. Companies are built by people, and so a good way to judge how well a company will do is to look at their hiring process. This was ours. If you think Polychart will be a good fit, shoot me an email!
End of Entry
