I interview prospective developers for my company almost every week, and over time have developed a bit of a sixth sense for sussing out talent. Here are a couple of the hallmarks that I look out for during an interview.

Low ego

Our company is made up of approximately 95% technical minded folk, from graduate level programmers all the way up to senior greybeard level programmers with over 20 years of experience. This creates an awesome diverse environment where youngsters can learn from the experience of the battled hardened, and (sometimes more importantly) the oldies can be shown a thing-or-two by the young guns. We have absolutely no draconian overlords or chain of command when it comes to technical knowledge - every single individual must be in a state of constant learning, and this is the kind of environment that we nurture and protect.

The natural enemy to this open and learning culture is ego (and I mean the "self-importance" definition, not the "self-awareness" definition). Being able to learn means being able to listen, and being able to surrender the fact that you may not know everything. If you work as a developer today and believe that you will one-day know everything - then guess what, you are delusional. Catch a wake up. Open your ears, dump the ego and stop trying to prove to the world that you know everything. You don't.

More here (via travisandco.com)

No sociopaths

Openness, honesty, transparency, empathy, professionalism, accountability and integrity. These are +1. The sociopath personality undermines all of these things in order to benefit personally at the cost of the company culture and team dynamic. We simply cannot afford to hire even one of these profile individuals.

How to Spot a Sociopath (via wikihow.com)

Does not believe in magic

"Any sufficiently advanced technology is indistinguishable from magic" -Arthur C. Clark

All program behaviour can be traced back to some line of code, given that we can continue to remove and inspect layers as we move down the call stack. I've met too many greenhorn developers that simply give up once they cannot explain why something occurs because they are too afraid to dig one layer deeper. The assumption that there is a magical spell one level below that simply cannot be understood is complete FUD - and we MUST dive deeper if we are to become proficient programmers.

In the "old days" of C/C++ running in unprotected memory, magic was a bit more real - and as programmers we had to work really hard to track down errant memory writes that could introduce complete nonsensical behaviour as return addresses were overwritten, etc. But even then, there were great tools (such as valgrind and friends) that worked as powerful counter-spells - you just needed a fellow greybeard to point you in the right direction.

Today, however, there is no such excuse. Languages enforce types and protect memory, garbage collect, automatically dereference, even allow you to protect regions of code for thread safety. Code is more deterministic than ever before and that's awesome. What that means is that we should have absolutely no excuses for diving a level deeper whenever we need to. Dig into the AngularJS injector code! Go read the nginx http proxy module source code! Figure out how kubernetes integrates with AWS! No magic, just normal run-of-the-mill code. Written by humans. Not wizards. I promise.

Can speak through a problem

Instead of simply blurting out a few early guesses (be they wrong or right). I like a person who initially says "I'm not sure", and then takes a bit of a think and then starts asking some leading questions to guide them to an answer. Realize that good interviewers really couldn't care if you have memorized what HTTP, DI, CICD or YACC stands for - but rather what these things are and for what reason they exist. It is not correct to say that "HTTP is the opposite of HTTPS" - come now. Show that you understand this stuff, or admit that you don't.

Is not a one-trick pony

Having the ability and desire to learn a new language, and being adept enough to do this quickly and intuitively. The fact that a developer has spent his or her entire life in Java and can recite every possible system API is great, but doesn't help much when they are deployed into a nodejs project and expected to hit the ground running. Although it's vital that one can go deep when needed, it's more important to be able to go wide and be able to look around at other languages, be able to juxtapose them, understand why they exist and how best they should be used. The ability to find the API docs counts for more than the ability to recite the API docs. Google beats brain for memorizing stuff. Everytime.

Other notable one-trick ponies:

  • Object orientation is the only programming paradigm worth using
  • Threading is how you achieve concurrency
  • Scalability is achieved by optimizing your code

Is a team player

"The whole is greater than the sum of its parts" -Aristotle

We don't do single-man projects. All of our teams, are TEAMS. Teams need to self-coordinate, collaborate and align to the same goals in order to deliver at the highest levels. I always imagine myself locked in a room with the prospective candidate, and role-play "Would I be able to work with this person for an extended project?". I'm not looking for someone who is necessarily a follower nor a leader, but someone who is a collaborator. Someone who can follow and lead at the same time. Filling in the gaps left open by other team mates. If I can only imagine having to work really hard at collaborating with the candidate I'm probably not going to bother eventually, and either step away and let them run the show, or deliver the entire thing myself. Either option is bad and defeats the multiplier effect of the team.

Anything I've missed and you think should be added? Drop me a comment below.