Smart and Gets Things Done Are Not Enough

You can have the drone developers.

Once upon a time, hiring programmers began with making a list of things they needed to know. Actually, you can still see plenty of job descriptions today that read like a snooze-inspiring checklist.

Requirements: Bachelor’s Degree or Military experience — At least 12 years of experience with Enterprise application design and construction with an emphasis on web architectures — At least 7 years experience in SOA environments working with SOAP or at least 7 years of experience with RESTful web services- At least 7 years of -.NET (C#), ASP.NET- — At least 5 years of experience with UI Design — At least 5 years of experience with -HTML.

That is excerpted directly from an actual, live job posting. And it keeps droning on like that for several more paragraphs. Painful, no? Do you wonder how its authors decided that it should be 7 years of .net, but only 5 years of HTML? Should you really not apply if you have 7 years of HTML and 5 of .net? Do they really not want you if you are the author of a major open source library but don’t have a bachelor’s degree?

On the plus side, pretty much only big, ossified corporations think this way anymore, which means that they are missing out on smart, awesome people. Cue evil laugh and nefarious rubbing-together-of palms — this means lots more smart and awesome for the rest of us.

Way back in Y2K, when otherwise normal people were avoiding elevators and stockpiling canned chicken, Joel Spolsky wrote an incredibly influential article called The Guerrilla Guide to Interviewing. It is still well worth a read, but the biggest takeaway is: stop hiring for predefined skills. Instead, hire for two traits: Smart and Gets Things Done.

At ChefSteps, we take this advice seriously. You should hire smart people because they do smart things that make your products better. Smart developers write clean, concise, well-factored, reusable, tested, DRY, performant code. And you never have to give them the same feedback twice.

Smart is necessary but not sufficient. Your hires must also be people who get things done, because if they only sit around and theorize about smart things, you’ll never ship. And all that not-shipping is going to make you pretty darn stabby.

So where does experience come in? Great programmers pick up new stacks in short order. So it rarely makes sense to hire someone based on his or her familiarity with a particular language or tech stack. There are two exceptions to this rule. Actually, there is one full exception, and one half one.

First, the full exception: Sometimes, deep expertise just matters. Someone, for example, who has worked extensively on web-scale services — and wrestled with all of the SLAs and security issues they entail — just knows things on a visceral level. And that knowledge may well keep you from cutting yourself with very sharp objects. Sure, you can ask a great frontend developer to learn that stuff, but expect it will take them a year or more to be truly fluid at it. So when the stakes are high enough that stabby-ness is in play, go ahead and hire for expertise.

Onto the half exception. Let’s say you’ve got something absolutely urgent to do on a particular stack. Your iOS app is six weeks from shipping, and the critical new user onboarding experience isn’t done. Okay. This is not the time to bring in a phenomenal backend developer and get her up to speed on Swift. But if you find yourself with an immediate need, and don’t believe you will have an ongoing role for the person who can meet it, or know that hiring him means compromising your normal standards, you should use a contractor or agency to solve the problem. That solution has its own headaches, sure, but it’s better than forcing a lackluster hire on you and your team. Once the crisis is past, you probably should figure out how you got yourself in that mess in the first place.

So, Smart and Gets Things Done are great criteria for new hires. Let’s add a third: Not a Jerk. No matter how smart someone is, no matter how good his code or how fast he writes it, we’ve got no place for him on our team if he makes everyone else miserable. Frankly, I don’t care about the beer test or even the Sunday test. They can actually work actively against diversity and lead to a team of code bros. But if you find yourself interviewing the type of programmer who always has to be the smartest person in the room, or that gets his jollies from insulting coworkers, or — worst of all — shows himself to be ethically challenged, the door shouldn’t even have a chance to hit him on the way out.

The problem is: Smart, Gets Things Done, and Not a Jerk are table stakes. As competitive as the market is for engineers is these days, it is tempting to hire people who just hit those marks. But hire based on those criteria alone, and you may end up with a team of highly fungible, tremendously boring robots.

The context of your company or team matters a great deal. At ChefSteps, being part of a startup with a big vision means our hires need to gracefully embrace ambiguity and change. We are trying to reinvent the kitchen, not disrupt inventory management for janitorial supplies. If you expect to always have complete specs and perfect design docs before you build a feature, this isn’t the right place for you.

And you know what? I know myself as a manager and leader. If a developer is only productive when I hound her to keep her backlog organized and her bugs under control, and I can’t trust her to make important tradeoffs, we won’t work well together. My job is to help my team understand the overall context of what we are building as a company so our decisions are aligned. I do my best to make sure they have what they need to be successful, and shelter them from distraction. I find them awesome coworkers to execute with, and help them work through the inevitable human issues that pop up. I’m also super-excited to talk through technical issues, but I’m nowhere near smart enough or patient enough or in-enough-places-at-enough-times enough to coach anyone through her job on a daily basis. So to thrive here, engineers have to relish autonomy along with massive responsibility.

Beyond these fundamental requirements, every great engineer that I’ve worked with brings distinct additional strengths. Just to pick a few examples, they might:

• Know every line of a multi-million line codebase and be able to diagnose a bug without even looking at any code.
• Be unrelentingly optimistic and never give up on a goal, even if it takes years to come to fruition.
• Crush any obstacle that comes between them and done. Before lunch.
• Be a grizzled vet who has shipped so many things that they help the whole team make great tradeoffs…
• … or be relatively new, but so motivated that if you take a chance on them, they will repay it 10x.
• Bring a completely different perspective that changes how you think about a problem or a whole project.
• Reduce your stress level because you know that anything that lands in their lap is 100% handled.
• Make the team so fun that everyone can’t wait to get to work, or loves to hang out together outside of work.
• Have a knack for isolating and eliminating the nastiest, most difficult to reproduce bugs.
• Have the empathy and passion for education that makes them great at mentoring interns and less-experienced but promising newcomers.
• Be so incredibly committed to your product that they will stretch in unexpected ways to make it a massive success.
• Engage directly with users to turn them into evangelists and help the whole product team learn what they really need to build.
• See the big picture of the architecture you are building and save the team years of wandering the right way down the wrong paths.
• Be emotionally intelligent in a way that recognizes when colleagues need to talk about something difficult, or even initiate those conversations that would be easier to avoid.
• Be passionate about growing the team and help you identify and interview terrific candidates.
• Read all the blogs and be aware of the bleeding edge of tech. (Bonus points if they have enough taste and self control to know when to actually use the bleeding edge of tech).
• Challenge you and call you out — very publicly if need be — when you are being a jackass.
• Love to put on the headphones and knock out impossible features, impossibly fast.
• Have a sensitivity to user interface that allows them to collaborate unusually effectively with designers.
• Be a tool builder who will continually make your team more efficient.
• Communicate effectively to other technical and non-technical teams.
• Surprise you with futures and prototypes you’d have never thought of.

No candidate is going to bring all of these strengths to the table, but any great candidate will bring some of them. Ideally, your team will grow to include people with a diversity of them over time. To improve your odds, be sure to write job descriptions that communicate actual passion and the flavor of your company. Ask open-ended questions that invite candidates to show you their personality, follow-up about subjective skills in reference checks, and discuss them in your hiring decision meetings.

Now for the really subjective part. There is something else I look for in every hire, a proxy, of sorts, for that long list of soft skills: are the lights on in their eyes? There are plenty of candidates that I talk to that are … perfectly fine. They are solid programmers; they’ve shipped things; they are nice people. But certain people just have that spark, and when you see it, you know that you want to work with them because they are going to make your life and your team way better.

So, tell me, does all this jibe with your experience hiring engineers? Are there other things you look for in candidates? And how do you identify those subjective — but crucial — skills that will never show up on a checklist?

Michael Natkin has spent the last 30 years building movie dinosaurs, shrink-wrap software, cookbooks, and sous-vide cookers. He was mostly recently CTO of ChefSteps. He’s currently looking for his next role. He’s also written more words.