Here is a description of our hiring process. We write down our process to help us understand a baseline against which we can make improvements. It should also let us spread the interviewing burden while keeping a good degree of consistency.
We want to make sure that every candidate gets a timely response from Cumulus. It takes some organization to keep on top of the stream of incoming resumes.
We use structured interviewing. This means that we use the same interviewing method to assess each candidate applying for the same job. This lets us be more aware of how we work and gives us a baseline to improve on. Structured interviewing saves time. Here we have a standard to avoid excessively unproductive interviewing. Most importantly, structured interviewing allows us to better predict the performance of the candidate, so we can make better hiring decisions.
- Cumulus posts a job opening on our website and advertises it on Hacker News, LinkedIn, Stack Overflow, etc.
- Candidate sends a resume and perhaps a cover letter.
- Does the resume generally fit the opening?
- Is the cover letter well written? The candidate can make a positive impression for a well-written and effective cover letter.
- Invite the candidate for a half hour phone screen. Consider using Microsoft Teams to make it easier to manage the appointments.
- The candidate makes good impression following directions and calling at the correct time.
- During the phone screen, the interviewer take about 10 minutes to describe Cumulus. Use the remaining 30 to 35 minutes to learn about the candidate, their history and their objective.
- Is the candidate likely to fit the role?
- Schedule the "in-person" candidate demo followed by team interviews.
- The demo portion of the interview will be a 50-minute conversation about the candidate's approach to solving a problem and their code. Cumulus will provide prompts for the candidate to discuss their code. We may elect to not go on to the interview portion if the demo does not meet our standards.
- The in-person interview are 30-minute single-person interviews with at-least four different individuals.
- Following the demo and interview, the team will discuss fit and qualification for the role, making an assessment of the candidate's performance.
- Give the full-time offer. Yay!
Example of a good cover letter:
I saw your job posting on HN's who's-hiring thread looking for a remote software engineer for Cumulus, and I can help you.
I've been developing web applications since the early 2000s, focusing on full-stack JS with Node.js for the last six years, and working with various stacks (mostly LAMP) before that. I've built RESTful APIs in Node (express, sails, also without frameworks) and single-page JS UIs (React/Redux as well as others). I've worked with relational databases (PostgreSQL, MySQL), NoSQLs (MongoDB and Redis), and graph databases (Neo4j). I've done TDD and BDD, and provisioning in AWS and other cloud environments, and a lot of GIS-related work with Mapbox and Google Maps.
I have years of experience working with remote teams--full-time from May 2012 to May 2013 (for an angel-funded startup in LA) and for eight years consulting for customers in New York, Seattle, LA, and San Francisco from 2000 to the beginning of 2009. (I'm in EDT.) Most recently, I've been wrapping up a mobile research contract (in Flutter) with a Pittsburgh fintech incubator
A poor cover letter earns the candidate a good impression.
During the phone screen, the screener gives a ten-minute introduction to Cumulus, the Quality Execution Platform, and its major technologies. Give the candidate about ten minutes to talk about themselves. Finally, give the candidate five minutes to ask about Cumulus. Explain the steps of the interview process, if there is time. Phone screens should be strictly time-boxed. Take about 45 minutes for the call, leaving at least 5 minutes to take notes and prepare for the next call.
We evaluate the candidate's verbal communication skill and technical background. Most candidates will be able to give a useful discussion with little prompting beyond, "Now tell me about yourself". A few will stop talking unless you give more prompting (walk through their resume, or ask about their favorite project). I don't think that the need for additional prompting is a problem.
A candidate's public portfolio can give us some confidence in their skill before we ever meet them. Ask for a pointer to their best open-source project. At a minimum, new college graduates with a CS major should have some coursework posted on GitHub, GitLab or Bitbucket. Take a look at it, check the authors to make sure it was mainly written by the candidate. Give the candidate from -1 to 3 points based on the source code. Here are a few points:
- Does the candidate have a non-trivial code example?
- Is it well structured? Are functions understandable and the overall design generally solid?. Gigantic functions show poor taste and careless design.
- Does it have some unit test coverage?
This repo houses our candidate exercises intended to help demonstrate the mastery in your discipline.
The goal of these exercises is for it to serve the interviewee and the interview team as a conversation starter, so that you may get to know your future teammates. It is a take home assignment, and you should spend no more than a few hours on it. It is not meant to be 100% polished and ready for customers, it is meant to serve as a way of illustrating the way you think about problem solving.
Index of Exercises