The biggest challenge in building a great company is hiring great people that work well together. For most tech companies starting out, a great majority of people hired in the first few months is made up of engineers. Finding and hiring great people is hard enough in itself. Making them all productive and work together as a team makes company building almost insurmountable. While hiring a person, technical chops should be viewed purely in the context of how well they can be used to improve the team’s productivity given the personality traits of the engineer getting hired.
‘Of course’ you may say, ‘We look for attitude, teamwork, communication skills and cultural fit’. But these are clichés. It is very important to establish a set of traits that you want to evaluate each candidate on. I describe below some of the traits I normally look for. These are mostly empirical and although these are qualities that I’d like in most people, I describe them in the context of how they make engineers great.
First, let me tell you what an ideal engineer is like. For the Star Trek fans out there, this should already be obvious. Yes, I want Spock to be my coworker. You read that right. No emotions. Just objectivity. The moment he joins the company, I know he’s going to work out for the company because, being Spock, he wouldn’t waste time on something he doesn’t believe in. As long as he stays with the company, I know the business is getting the maximum productivity from him because he cannot, almost by definition of being a Vulcan and being able to suppress his emotions, be not working at full potential on what he believes in. A company will be a very successful business if it can find enough Spocks to fill all its positions. Alas, it’s only a fantasy. I do know a couple of folks who come very close to being Spock, though.
Knowing that I won’t be able to find Spocks for my company, what characteristics do I look for in engineers?
If I were to list the outstanding qualities of the most productive engineers I have ever worked with, humility is the most common word I see. What makes it a winning trait? A humble engineer does not assume he or she is superior to anybody else by default. That single assumption generates a bunch of nice side effects:
- While they are confident of their own abilities, they are not overconfident. Work is neither underestimated nor overestimated, resulting in your projects going very smoothly.
- They are inherently disposed to learning new things frequently as they are honest enough to admit to themselves that they don’t know everything
- They bubble up issues as they find them because if something is beyond them, they have no problem accepting it. When they come across something they don’t know about, they never think “I am supposed to know this”. Instead, it’s an objective “How can I find out more about it?”
Respect for others
Although this may sound like a byproduct of humility, I look for respect explicitly since a humble person may not always come across as respectful to others. A humble person assumes no superiority by default but he also needs to recognize great qualities in others. By carrying respect for their colleagues AND being humble, a great engineer is able to get things done QUICKLY in collaboration with his teammates. Humility and respect, together take teamwork to its full potential. To realize how important these two are in combination, think of exactly opposite qualities (ego and disrespect) and how those can ruin a project.
Focus and Purpose
Without the ability of engineers to stay on topic, you will see meetings where the starting agenda, the discussion and the conclusion are three completely different things. Without focus, your problem statements will remain problem statements after hours and hours of meetings. With focus, they get broken into smaller problems recursively until each of them is small enough to be solved. This applies in individual settings as well. The arrival of a new email doesn’t distract a great engineer. Yet an urgent question from the field gets answered immediately. His or her penchant for focus and an understanding of purpose brings out maximum productivity.
Patience and Self Control
Rome was not built in a day. While there are some software projects that were built over a weekend, I can assure you those were the results of a lot of skill that was acquired over a very long time. A good engineer has enough patience to learn a new technology, build something new using the technology, test it rigorously, debug and fix bugs relentlessly before claiming “it’s ready for beta”. A bad engineer learns about a new technology on Hacker News, builds a “product” “over a weekend”, claims “it’s done” and discovers all the bugs through users for the next three months. His impatience (in this case for recognition) results in short-term accolade and long-term grief to both him and the users of the product.
Urgency is something that comes out of purpose. If you are running a marathon, your first mile is as important to cover as your last mile. In the workplace, your miles are actions that can take you closer to a goal. Whether the deadline is today or two months from now, if the work is correctly estimated, the urgency of your current task remains the same. Bad engineers realize the urgency when the ratio of remaining work to remaining time goes very high. Good engineers realize it when the ratio is growing. Great engineers do things urgently and never let that ratio become big enough to make them stay longer at work. Not that they don’t stay longer if needed but that’s a completely separate topic.
Don’t mistake being communicative with chattiness or gossiping, which are in fact qualities that make me reject otherwise great engineers (although it’s very hard to find out in interviews). Being communicative is simply being proactive about telling your teammates about things like what you are working on, its dependencies, how much progress you have made and whether you are blocked on anybody else for your progress. This may sound very simple but I am surprised at how many people don’t do this effectively.
When someone refers to a project as “his baby”, think about what it actually means. If it’s your baby – I mean literally – you’d do anything to take care of his/her wellbeing. You feed him. You put him to sleep. You take him to his routine checkups. You even carry your baby to the hospital in the middle of the night without thinking twice about it. Anything for your baby. Right? A great engineer treats his project like it was his baby (this time, not literally). Well, nothing is as important as your baby but the sense ownership has similar effects as parenthood. Once a great engineer starts a project, you can be pretty sure it will be taken care of. Development schedule, deployment, production issues in the middle of the night – the engineer is there at the right time to take care of it. He might reach out to others in the team for help out but the team can have peace of mind about the health of the project.
While it’s easy to evaluate necessary technical chops in an interview setting, these qualities are very hard to assess in 30-45 minutes. That’s one of the reasons why hiring via referrals is usually favored over hiring an outsider. Are you a software engineer and want to work in a team that values these qualities? Reach out to me at rithal at netskope dot com.