Three Traits I Look for in Software Hires That Have Never Failed Me

In my career, I’ve interviewed countless software development engineers and software development engineers in test (SDET). At one point, I was involved in the hiring decision of over 50 people across the span of 18 months. I’ve worked at tiny start-ups like Movaris, to companies that went public like Saba. More recently, I’ve held roles at eBay, Netflix, and now Upwork. Through it all, I’ve discovered three traits to screen for that have never resulted in a bad hire for me. In this article, I want to share with you what they are.

Self awareness: How accurately do you identify your strengths and weaknesses?

When vetting candidates, I’m not looking for someone who knows everything. Instead, I’m on the hunt for someone who is self-aware enough to be able to identify what she does know and what she doesn’t, and to accurately gauge her own strengths and weaknesses. I like to ask candidates to identify something they know well and as well as something they are familiar with but not expert in. For a software engineering position, for example, I’ll ask for their strongest programming language as well as a good-but-not-great language. I’ll then ask them a specific but basic question against their strengths and their weakness.

For example, one question I ask .Net developers who claim they are strong in .Net, is whether or not a virtual machine is used to interpret their code. While different developers may interpret what is meant by the term virtual machine, a .Net developer that doesn’t mention bytecode and assumes .Net is an interpreted language would demonstrate poor mastery of the topic.

As this chart shows, this question helps me get a bead on candidates’ self awareness: on how well they are able to pinpoint their real strengths and weaknesses:

In my book, owning up to what you don’t know is a feather in your candidacy cap, not a foible. By contrast, not having as strong of a grasp on what you do and don’t know gives me cause for pause. Overconfidence can lead to production problems when team members optimistically underestimate timelines. Underconfident employees may not work up to their potential.

Evidence of deliberate practice: Do you invest time and energy in practicing what you are not good at?

Deliberate practice means breaking a skill into its component parts and working toward mastery of each of those parts, often by seeking feedback from a coach or other expert along the way. Deliberate practice requires both time and tweaking: you’ve got to put in the hours, and you also need to constantly evaluate and adjust your practice to get better. Studies suggest that practicing deliberately can be a precondition for becoming an expert. As Dr. K. Anders Ericsson explains, “the differences between expert performers and normal adults reflect a life-long period of deliberate effort to improve performance in a specific domain.” 
Self-aware job candidates who know what they are good at and what they are not good at who can use deliberate practice to expand their repertoires of needed skills have everything they need to get the job done, regardless of changes in their jobs or in the field. In the always-evolving world of technology, self awareness alongside deliberate practice is a particularly powerful one-two punch.

Grit: How do you respond when things don’t go well?

To wrap up an interview, I like to throw what might look like a curve ball. My final assessment involves a work simulation — one either impossible to complete in the time allotted or requiring the candidate to seek help. For software engineers, the task requires building a website or an app from scratch using a pre-configured computer that the candidate requests or using their own machine. For SDETs, the work simulation involves using homegrown tools or testing builds known to have specific defects. Either way, the exercises simulate real work with real pitfalls.

These challenge-laden work simulations test a candidate’s grit. Ira Glass describes grit in the words of wisdom he offers to newbie writers:

Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit. Most people I know who do interesting, creative work went through years of this. We know our work doesn’t have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know its normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions. And I took longer to figure out how to do this than anyone I’ve ever met. It’s gonna take awhile. It’s normal to take awhile. You’ve just gotta fight your way through.

Like writing, software engineering is creative work. And like great writing, great code doesn’t come naturally. But self awareness, deliberate practice, and grit can put you on the road to coding better and interviewing better.