5 Attributes of the Engineer I Want to Hire

3221301604_70c55d65ce_z 

I was giving another technical software interview yesterday. I hate giving them. I believe it’s extremely difficult to learn much about a candidate using these types of interviews.

I also hate taking them, and I hate thinking about them.

They have never come easy to me. I even started another project to keep myself sharp.

I got through the Google wringer once, and I failed another time. I’ve passed plenty of interviews, but I’ve also failed ones I shouldn’t have failed. In the course of giving interviews, I’ve probably rejected people who were perfectly good, only because I didn’t have enough data to go off of.

As software engineers, we complain about the interview process. In no other field, are people required to re-present the basic skills they learned in college, when those skills have little application to the daily job.

But we don’t have a choice. There’s no formal accreditation process in software engineering. I’m glad there isn’t, but that means it’s exceptionally hard to tell good engineers from bad ones.

Despite reports to the contrary, I believe the technical interview is here to stay. Unless the underlying environment of our field changes, the technical interview will stick around. We just don’t have a better way.

But, here are some of the things I wish I could interview people for. They’re what I believe makes a decent employee. Take my words with a grain of salt – I’m probably not the best employee, having an entrepreneurial bent and all. That being said, these observations are based on people I’ve witnessed in the workplace who have done well.

  1. Adds Value without Direction.
  2. Responds to Feedback
  3. Doesn’t write Bad Code.
  4. Isn’t a Negative Time Suck.
  5. Willing to Put in Hours.

Notice that the technical software interview only tests #3, and even then, it does it poorly.

 

1) Adds Value without Direction

This is a person who sees exactly what the team needs and goes and does it. Nobody has to assign the task to them, they just have an intuitive understanding of what could make everyone more productive.

Let me give you an example: on a web team I was on recently, a buddy of mine took it upon himself to automate the release process.

Before that, we had a long, complicated process that consisted of 10-12 manual steps. It was awful. Every time we deployed someone would make a mistake because the process was so complicated. What was worse, because of the custom infrastructure we were using at the time, it wasn’t easy to automate.

To get automation to work, we had to switch off of the custom infrastructure.

You could argue that it would be up to the team manager to prioritize this automation task, but many times that doesn’t happen. Especially with infrastructure, when you have competing priorities and new features constantly being rolled out, infrastructure often takes the back burner.

My friend did a bunch of the work to get us off the custom infrastructure and to get us directly on to AWS. The team now has a one script deploy, the old class of mistakes never happen anymore, and they can deploy much more frequently. What’s more, it doesn’t take an entire half day of an engineer’s time to finish a deploy.

He did most of this work without any direction from our manager. He just intuitively understood the value it would have for our team, and he went and did it. That team will benefit from the new release process for years to come.

2) Responds to Feedback

What I mean by “feedback” isn’t the traditional “peer feedback” that many companies include in a performance review cycle, although it certainly could mean that.

What I mean instead is responding to design and architectural feedback while you implement code. Some of the most difficult people I’ve ever worked with suffered from not being able to do this.

They’d have 2-3 people telling them their design was wrong, or they should possibly do it another way, and they would relentlessly push back or ignore the feedback. Eventually, most of us would give up, and let that person do whatever they wanted, paying the cost for a substandard design in the process.

I understand that code reviews can be tough. On numerous occasions at Google, I spent a day or two writing code, only to be told by my reviewer to revert it. That sucks. It makes you feel stupid.

But if you can step aside from your emotions and be humble enough to realize you don’t really suck just because you screw code up every once in awhile, you’ll be a dramatically easier person to work with.

3) Doesn’t Write Bad Code

This is the only skill that’s tested in software engineering interviews, and even then, it’s not tested well. I know several people who have made it through hard engineering interviews, but then were disasters to work with.

What is “bad code?”

Unfortunately, it’s a nebulous definition. You know it when you see it.

Some of the symptoms of it are:

  • Failure to separate concerns. Faulty abstractions.
  • Leaky encapsulation.
  • Terrible performance penalties.

We all fall into these sometimes, but as long as you’re willing to accept feedback, you can avoid most of them with the help of a co-worker.

It’s usually where someone consistently writes substandard code AND refuses to accept feedback that the team runs into trouble.

 4) Isn’t a negative Time Suck.

I’m sure you know this person. He seems to exist on most software engineering teams. He can’t seem to get anything done without significant help from other people. The result is that it winds up costing the time of 2 to 3 people to do a single person’s job, and your whole team is less productive as a result.

I discuss this more here.

What’s more is these people are usually very nice and friendly. Part of why they do what they do is because they really enjoy socializing, but too much, and to the detriment of everyone’s time.

5) Willing to Put in Hours

I’ve seen many posts recently bemoaning “workaholics.” Some engineering companies talk about how they don’t want to hire them because it will ruin their company culture.

Let’s break this down.

Balance is extremely important, don’t get me wrong, but most of the people I’ve seen at the top of their fields came dangerously close to burning out at one point. They might have a balance today, but what got them to where they are was an almost maniacal obsession with whatever they were doing.

So most of the really good people I’ve worked with, at one point or another, would have been called ‘workaholics’. It’s the reason they got so good.

So I’m not sure if being a workaholic is a good or a bad thing. At times in my life, I’ve worked far too much to be healthy, and that took a toll on me. But, I’ve probably been more valuable to my employer because of the hours I put in.

When you start a new job, learning the code, the developer tools, the new technologies all take time. They take hours of time. Someone who’s willing to put in extra hours, especially until they get up to speed is much more valuable than someone who won’t.


That’s it. Those are some of the characteristics I wish I could hire for. Unfortunately, most are impossible to test in a 45 minute technical interview.

What’s more, if someone was a mediocre coder, who scored say a 50% during an interview, but had all of the above attributes, I would hire her in a heart beat.

The problem is that you have no guarantee that the person has any of those attributes.

Photo Credit: Alex France