I'm guessing you're reading this post because you've got a problem. Your problem is, you can't seem to hire any women. No matter how many events for women in tech you have, no matter how many women you get into the pipeline, you never end up with as many as you want getting through. You might be aware of other problems with your hiring process, maybe a friend you know wasn't able to make it through, despite being smart and capable. Maybe you give out a lot of offers, but despite them being generous offers, few are taken. Maybe you're interested in a candidate with a non-traditional background, but you know your interview process will grill them on things they are weakest at, robbing you of the talent you need. Maybe you just hate whiteboarding, which sounds like an enhanced interrogation technique.
So what is there to do? After all, there's a shortage of talent, but no shortage of pretenders to software engineering. Candidates that can't code fizz buzz are rampant, and new grads from nearby colleges are whisked away quickly by Facebook or the Department Of Defense. You don't want to waste your company's resources on someone who proves down the line to be incapable of doing the work, 2 months of salary and a bunch of onboarding time down the drain. The question is, how can you tell the difference?
First, let's talk about the information you're actually after. What kind of information do you actually need to know, in order to know you want to hire someone?
What do you actually need?
For me, I need to know someone can learn fast (ie, is smart) and communicate well. No one starts a job knowing the whole tech stack, and many people start without the requisite language experience. Really just being able to pick things up without being told over and over again is a good indicator. I also need to know that they'll communicate well, and tell me when they don't know something. Pairing with someone can show me both of these things, and can give me another insight as well. I typically expect a developer to be able to research things and learn things by themselves, not just when I'm sitting there spoon-feeding them. So, giving the interviewee advance notice that you'll be pairing, and what technologies you'll be using gives them a chance to prepare. As a senior developer who mentors a lot of junior developers, it's much simpler for me to show up to help them if they have already prepared, and can demonstrate to me where they're stuck.
The main things I want to test are her knowledge of server-side web development. In particular, we have a lot of asynchronous processes that run to integrate our application with other services. The nitty-gritty details aren't important, I want to test Jane's thinking style, and know whether or not she'll be able to understand and work on these kinds of problems.
I'll send Jane this email:
I wanted to drop you a line and see if you'd be interested in coming in to do a pairing interview. You got along so well with our team, they wanted me to bring you in for a second round.
Because you've been mostly a front-end developer for awhile, I'd like to focus on your back-end skills. We'll be creating a small Flask app that serves JSON, but we'll also be using Celery to schedule data processing tasks. We'll be creating an app that allows a user to sign up with Facebook or Twitter. That user will then be put in a queue of users to be processed. We're going to try to find people they're connected with that also use our app, and then notify them that they have friends using the application. It will probably take us all day to get this done, so plan on a full day of coding with me. Also, take a look at Flask, Celery, the python-twitter module, and the python-fb module. Let me know if you have a preferred editor or any tools that will make you more effective.
I'd like to give you some time to prepare, so does a week from now sound good? I have Wednesday and Thursday next week available for this, or the week following on Tuesday.
Thanks, and let me know if you have any questions before then.
In this email, I made sure to do a number of things. First, I made sure she understood we were interested in her. Many candidates, especially women, have serious problems with impostor syndrome. They might be sure of their code, but aren't sure of themselves. They don't know where they stand, and this weakens their resolve. Starting from a place where they can feel confident will help them perform at their best.
Third, I told her what to familiarize with, and I made it clear I expected her to prepare. Too many times we've been judged because we didn't know a command-line tool, a common module, or something someone has decided we absolutely need to know in order to program properly. Given the diversity of applications of a given language, how could we possibly have a canonical set of tools or modules?
Preparation isn't something that will cause you to receive fake signals. In an actual job situation, you'd have time to prepare and research any given solution before you begin programming. This doesn't mean you never have to think on your feet, and during my 4-to-8 hour session with Jane, there will be many opportunities for me to make her think on her feet, and show me her just-in-time learning and problem-solving skills. Doing the search of the graph, for instance, or intelligently processing a queue of users will be great examples of her having to learn a new way of doing things. There are also enough things for her to learn that she probably won't end up finishing them all by the time we pair. It will give me a chance to know if she's a preparer or a procrastinator, and it allows me to do it in a friendly setting.
This example is one of many tactics to use. Contracting is also a valuable and useful solution to not knowing whether or not someone will fit in with the team, or be able to do the work. Depending on your company, you might have a backlog of bugfixes, support emails that require doing research in your codebase, or a mystery to solve due to an intermittent error. Exposing someone to your actual code, or watching someone solve a problem on a computer rather than an arbitrary environment will help you know whether they're a problem-solver, not a syntax-memorizer. If you want to use contracting as a means to interview someone, keep a developer environment set up for this purpose. Having something ready decreases that day-long setup process that most developer environments take to setup, and you don't want to pay someone to watch things install.
The main thing here is removal of as much intimidation as possible. You want a working environment where people trust one another, where we feel we can ask questions, both because we don't know, or because we've found a better solution. Fear, and problem-solving in the face of fear isn't a useful metric to judge any person by - how does it help to know how someone does under the worst possible circumstances?
On Attracting Talent
Hiring is often approached at the 50,000 foot view. "Smart and scrappy" is great at that height, but in order to actually hire you have to connect on a human level. You have to zoom down 48,994 feet. Once you've said "I need the smartest people in the industry", you've applied a filter, and it's not the filter you believe you've applied. Most of the best programmers are humble. The more you understand about software engineering, the less likely you believe you're the "best". Overconfident engineers move fast and break things, yes, but they tend to break the build too. Women, as everyone's brought up, tend to have impostor syndrome. We don't think of ourselves as the best in the industry, nearly ever, despite the reality of the situation. If you'd like to attract more "A" level talent, be clear about what constitutes "A" level. Qualities, over qualifications. Ability over identity. Be clear about what kind of person you'd actually want to hire, and how much growth you'll want while they're in that role. Focus on what they'll do, not a checklist of skills. Being clear about what you'll actually accept is going to get you people who are honest about their talents.
An example job posting for a mid-level web developer at a python shop that would appeal to most women I know is this:
We're looking for an engineer with 2 or more years of experience to draw on. This person needs to have the learning mindset, someone who wants to pick up new skills and research new ways of doing things often.
You're expected to know these things:
- What happens when you type "www.example.com" into a web browser.
- Any scripting language, though some experience with Python would be good.
- Know the box model with respect to CSS, and understand HTML to the point where you could knock together a reasonable bootstrapped site.
- Understand how to build a basic API with any web framework
- Understand how to schedule tasks to do data processing, in any language.
- Know some SQL, and know how to use any ORM. Know what an ORM is.
If you know at least 80% of that list, go ahead and apply. Our office is in San Francisco, on Market street. We use Python, Django, RabbitMQ, NGINX, Redis, Postgres, some Node.js, and a smattering of other technologies. Our team is comprised of a lot of young entrepreneurial types, as well as industry veterans. We have a lot of fun at work, and our culture runs heavy on the nerdy side. A picture of our office:
[put a picture here.]
- Market Salaries / Standard benefits
- Catered Lunch *
- Commuter stipend *
- Bike parking on-site *
- Gym memberships *
- Lots of beer in the fridge
- Tech talks / continuing education incentives *
- Travel if you want to / Don't if you don't *
- Work from home whenever *
- Bring your dog to work on M / W / F *
- Wellness stipend *
- 2 months maternity / paternity leave *
- Childcare subsidy *