My Manager Readme

- 7 minutes read - 1378 words

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.

David Hansen on riddles

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.

  1. Tell what you expect
  2. Expect what you tell
  3. 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.

Conclusion

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)

Flatiron School is a dynamic and fast-growing company that believes that
technology has the ability to reshape the way that we learn, and Curriculum is
at the forefront of that mission.

Being a Curriculum Writer in the Full Stack Development Team at Flatiron School
is both a philosophical, technical, and creative position. You will create
lessons and labs that drive our students’ understanding forward. As a member in
this team you’ll truly live “Student for Life:” As an autodidact, you’ll read
developer-oriented documentation, strip it to its atoms, build toy applications
to confirm your understanding, and find the essence of the technology. With
your unique understanding of the essence, you’ll weave words, code samples,
clever jokes, and small challenges together. You’ll receive peer review on the
quality of your prose as well as your code. You’ll apply just enough humor and
.gifs to create transcendent moments of learning joy for our students.

You’ll be responsible for shipping the lessons and labs that compose our
“bricks” – small, modular, thematic experiences that can be composed into new
products.

The Successful Candidate...
Has a passion for language and writing that can’t be denied: blogs, tweets,
movie reviews. You beat your friends at word games and think you’d have a shot
at the win on “Jeopardy!” When people mispronounce words you notice it. You
care about grammar and usage and probably didn’t blink when you read
“autodidact” in the Job Summary

Is a self-starter who can point to pull requests, thoughtful feedback, etc.
that points to your taking the initiative to fix things without being asked.
We’re a small team and personal autonomy is demanded

Can follow a style guide / pre-existing voice.: Just like code, you don’t get
to rewrite everything you don’t like. You must be able to work within the
pre-existing voice and honor conventions that are declared in our style guide.
You treasure verbal minimalism: the only words that can’t be misinterpreted are
those that aren’t there. Those that are are rigorously seined until they simply
can’t be removed.

Can take constructive criticism of their writing and code

Is a philosopher of learning and code who has not only learned to make code
accomplish goals, they have seen through the syntax and sees the approach, the
methods, the design patterns underlying what’s presented to the end-developer.
You can muse about SOLID or design patterns (or want to learn about them!) and
use them to frame new developers’ growth plan. You see where a learner needs
intentional practice and why capability X must be taught before Y

Is precise: clear explanations, clearly written and conforming to official
documentation

Maintains Learner Empathy: When writing you keep the language as simple as
possible and can account for the learner’s capability and mindset: verbose and
slower 

Demonstrates Flatiron Values

Technical Skills Required
Master Level

Typing

60 wpm minimum

Editor

You use your editor as an extension of your will. While the particular editor
isn’t important, you realize that this tool is key to turning your ideas into
output

Git

You use git as a tool to accelerate your writing and to document your work. You
can stash, commit in patches, can cherry-pick (when needed), merge and rebase
(when appropriate) and can rewrite a branch’s history for clarity and purpose
so that your commit log is pretty much as good as a lesson in your coding
strategy.

Can work with branch-based development / collaboration via GitHub

Following the Rules

We are multiple people with very different ways of seeing the world. Our
products unite together to seem as if they were written by one person with
years of expertise. We use a style guide to do this and we require you to
follow it.

Ruby

Procedural

OO syntax 

JavaScript

DOM-based JavaScript Programming

OO syntax 

SQL

Queries, Table initialization

Intermediate Level

Ruby

Rack, Sinatra, Rails

RSpec Initialization

JavaScript

Context manipulation of this using bind(), call(), and apply()

Can implement mocha, chai, rspec on an untested codebase

Object Orientation Theory

Classes in collaboration

SOLID

Shell Usage / Configuration

Customized RC files

Capable of using the shell to do programming work e.g. process a CSV to derive
URLS and store in them in a CSV that can be integrated into a burndown sheet