How to hire a bootcamp graduate properly

So you want to hire a junior developer. A rockstar beginner who you know you can unleash, but who you know will need some mentorship. Maybe you’re rewarding someone who wants to get into management with someone they can manage.

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.

An example:

I’m in contact with a potential developer named Jane. She’s been developing in Python but mostly in Javascript for about a year. She’s used Django before, as well as Flask. She’s never worked on a super complex webapp, because she’s mostly been in the front-end for awhile. I need someone to do some work in the back-end, so I don’t know if Jane will be a good fit, but she’s expressed strong interest in doing more server-side work. I’ve brought her in for a culture interview, and she gets along famously with the team. I’ve decided to bring her in for a pairing interview.
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:

Hi Jane,

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.

Second, I was clear about what we’d be doing, and why. Many candidates that complete coding challenges or whiteboarding problems don’t know what you’re looking for. Other interviews with other companies, friends and colleagues are giving this person advice about what to accentuate and show you — this advice may or may not be correct. You might be looking for a front-end developer but not care about their UX skills, what you want to see is performant code. When they lay on thick with the transitions and sparkly colors but don’t bother to optimize, you’ll pass on someone who is normally good, but just got out of a process with another company who wanted clean lines, not clean code. In a normal workplace situation, you’d be able to give feedback and get what you want. Why not do it in an interview?

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.

Other Tactics

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.

Another example

An example job posting for a mid-level web developer at a python shop that would appeal to most people 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.
• Enough Javascript to manipulate the DOM
• 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.]

Perks:

• Market Salaries / Standard benefits
• Catered Lunch *
• Commuter stipend *
• Equity
• 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 *

That’s a lot of perks, I marked the ones that women and married men tend to prioritize more than young bachelors. This posting talks about what you actually need to know and the proficiency level, rather than a laundry list of buzzwords. This will also get you fewer emails from recruiters, who tend to only be able to produce laundry-list candidates. Focusing on what it would actually be like to work there helps candidates that would fit in well actually be able to imagine themselves working there, which increases the chances they’ll be able to do well in the interview.

What you actually want is more people, who feel more empowered, to do more work. You want to output the best product or service you can, and so enabling someone from the very first time you talk to them is crucial. Hiring itself is emotional labor, because what you’re doing is seeking to understand someone, not testing them. You’re trying to bring someone into the fold, not put them through a trial by fire and then expect them to be able to trust you. Software engineering is probably 60% learning, and 40% problem solving. Learning requires vulnerability — don’t force your talent to do 60% of their job away from you, because they can’t be vulnerable around you. They won’t learn what you need them to, and they won’t ever really feel appreciated in their job. Having a process that begins by taking candidates and their time seriously sets a tone that the right candidates will match. Fits will be more obvious than ever, and your culture will improve. You’ll also end up with the right mix of diversity that will help you innovate.

Originally published at lizthedeveloper.com.