I have some real qualms about hiring in the technical professions.
What does it say about this industry that it interviews people by asking them to code contrived, arbitrary gimmick questions like the following on a whiteboard:
Given a 10 by 10 array of letter tiles with Scrabble &tm; values, what’s the highest-valued word we can generate from seven touching tiles”
while those who pass this winnowing blade, after hire, are the ones that are storing passwords in an unencrypted state.
There’s a cynical calculus in filtering for false positives in this fashion. I think that this process is prone to the “like me” bias and is rejecting many people who don’t match the dominant paradigm. It’s probably also part of what keeps the sector so non-diverse.
I think there’s a better way and it involves transparency and clarity.
While I’m not hiring for an engineering team, the idea of being more clear and transparent has a lot of resonance for my team which still has a strong technical component. I’m trying this out for my next hire at The Flatiron School.
I think if we transparently offer the following, we’ll set a groundwork of productive, fruitful discussions and ensure respect and humanity throughout the entire process.
- Tell what you expect
- Expect what you tell
- Tell them what to expect
More on this after the jump.
Telling What We Expect
Here’s a job description for a curriculum writer on my team. The posting is “Tell What You Expect.” I first provide a list of character / behavior guidelines in the “The Successful Candidate” bloc.
Next, my team, as a technical team, has a few technical requirements that are non-negotiable. We’ve all seen posts that ask for everything there is, and a few things that don’t exist yet, and expect to pay $50,000 for it. We don’t do that. For technical skills, we list only the ones that we really care about.
We recognize different bands within those skills. What does a person need to know in order to not be a drag on others (beyond an appropriate mentorship level?). These are the skills that are too costly for us to teach. We list them as “Master Level.” We expect those to be solid before hire and “de-rusted” within the first two weeks of hire.
Other skills that can be “grown” during time in position represent the hire’s areas for growth in their first year or so.
What’s nice about this structure is that it’s very obvious what a senior version of this role would be: the Intermediate Level items would join the Master Level and new Intermediate- or Beginner-Level skills would come in (more abstract programming techniques, mentorship / leadership, management / influence, etc.)
Because of Telling What We Expect, hires can expect 1⁄1’s to be focused on delivery of / improvement in these functions. If I want to start evaluating an employee in a new metric, I have to open up the discussion, add that metric, and start monitoring it (more on that later). So we get Expect What We Tell for “free.”
In sum, I believe what I’ve communicated here will create a great feeling of comfort for both the employee and the manager.
Tell Them What to Expect
The asymmetry of information from the candidate’s perspective is especially daunting. Because of this, I’ve created a manager readme that describes what the working relationship between my hire and myself will look like.
I’m also keeping the README in GitHub so that a curious employee could always look to see what was so important I started with it and also see what I changed, and why. I think this is a great way to immediately sense my “default” priorities.
I’m also glad the README provides me a spot to forewarn on some of my more quixotic aspects so that they can see the human behind my role.
We’re still fielding candidates, but I’ll be sure to find out what the final hire thought of this process!
Job Posting (for posterity)