Smart, capable developers differentiate themselves. That’s one of the things that makes them smart.
But there’s a catch. When we’re thinking about how to set ourselves apart, we’re obviously biased in favor of… ourselves. The things that we like most about ourselves will be the ones we emphasize in an interview—whether or not the company values them.
So let’s focus on differentiators in a more global sense. What traits are admirable in a developer because they enable him or her to build great products?
We have identified nine traits that we like to see.
Love of Learning
At Clear Function we look for learners.
We get excited when we talk to a job candidate who has a pronounced passion for finding and learning new things. We’re not talking about knowledge junkies who binge on Wikipedia and neglect meaningful, productive work. We instead value an openness to learn and assimilate things from different domains.
Broad reading promotes lateral thinking. Lateral thinking, in turn, helps developers solve problems in innovative ways. From Elon Musk’s first principles to the consummate expert-generalist Charlie Munger, we can find brilliant examples of how curiosity about a diversity of topics, industries, and domains enables some people to reach the upper echelon in their respective industries.
Systematic Approach to Problem-Solving
We also like seeing candidates take a systematic approach to problem solving, debugging, and theory building. There’s a “failure mode” that certain developers, particularly less experienced ones, enter when they cannot solve a problem quickly with known solutions. They, in essence, shuffle papers, push things around, and retry the same ineffective sequence of steps, hoping to get lucky.
This helter skelter approach has no place in smart software development. It is akin to rolling the dice.
“Look! Problem solved.” Not really.
Software products are really just a collection of logical relationships. Moving on without a full understanding of why a certain sequence of steps finally produced the desired result means that chance has replaced logic. Remove the logic, the sequential, if-this-then-that foundation, and coding becomes a game of craps. “Let’s hope this works.”
We can’t build a reputation selling products that might work, so neither can we build a team of gamblers.
We like to see developers who are methodical about isolating variables, testing one at a time and tracking the results, and inevitably pushing towards a solution by process of elimination.
The person who works more slowly to produce more predictable code is a winner. More process, less improvisation, please. Speed can be learned.
One of the most obvious differences between a talented junior developer and a talented senior developer is speed.
Experienced devs always are pretty quick to identify their next step. They never hit a roadblock and just throw their hands up. They know what to do next. They reach into their bag of tricks, and try another test, cross off another suspect, narrow down the list of suspects. Slowly but surely, they zero in on a solution.
Less skilled or experienced developers have fewer tricks. They try one or two things, then give up. They’re not sure what to do next.
Experience equips a developer with a map showing all the different routes that can lead to the same destination. If one has a roadblock, then they backtrack and try the next most convenient route. They will get there come hell or high water.
Passion drives so much of development. In fact passion powers the three traits already mentioned.
Though passion doesn’t make a good developer good, you won’t find a really, really good developer who isn’t passionate.
We are always happy to see somebody who is really excited about his tools; his arsenal assembled over the course of a passionate quest and after much experimentation with the effectiveness of each piece.
His favorite tools may not be ours, but our mutual pursuit of mastery and excellence is more important than shared preferences. After all, a well-matched couple don’t always order the same meal on dates.
A passion for coding typically also manifests as a voracious appetite for tech news. Even those with families or young children (and little leisure time) tend to sacrifice other hobbies in order to stay abreast of the latest happenings in tech. Mid- or senior-level developers acquire and consume a lot of information, which enables them to discover new solutions and give valuable input on product direction.
Depending on the role for which you’re hiring, you may find it helpful to look at the person’s life outside of professional context.
A stable personal life will ensure more consistency month over month, year over year.
Some companies do a credit check as a proxy: Can we depend on this person or is he going to have a flame out every six months? In the latter case, the candidate may not be worth your investment. As you work through interviews and live coding sessions with each candidate, get a pulse for their level of contentment and stability:
- Do they look like they’re keeping it together?
- Do they show concern for others?
- Do they seem reasonably happy?
- Do they have interests outside of work?
- Do they have a supportive family and community?
We’re always excited and impressed by developers who go out of their way to find other developers and talk shop after hours. So a good candidate’s outside interests might include meetups, conferences, and other professional meetings where they share their experiences and learn new tips and tricks.
Of course, every developer doesn’t need to meet that bar—say, 40 hours in the office and 10 hours of networking each week—but clear investment and participation in the broader development community is a good sign. It is a proxy for passion. Developers don’t use their own disposable time if they don’t care.
On the other hand, going to twenty conferences a year will make it difficult for your developers to keep up with their day jobs.
You want someone who cares about coding and community.
Most development teams have a handful of hardcore technologists. If you call them developers, they will correct you: “I’m a software architect.” Okay, then.
Software architects, software engineers, programmers, coders, developers, computer scientists—there’s a whole litany of names. The title that we prefer says more about our personalities and areas of interest than the work itself.
Some developers enjoy the business side of things. Others don’t. Their passion revolves around building servers and deployments. They want to focus full-time on technology.
What does this mean for small companies with small teams?
You’ll want to hire well-rounded individuals who will be in sync with your business. For your developers to understand the rationale and business objectives behind and beyond the coding will enable them to make better decisions.
And if you manage a fairly small team in a consulting environment, then you won’t have much room for junior developers. Early in their careers, they will have marketable skill at only one or two things. To gain serious technical prowess in web development, backend server development, databases, Windows system administration, or Unix administration will take them several more jobs and several more years.
Once you get past three or four people, your senior developers can devote a fraction of their time to training their juniors. But your first couple of hires should have senior-level experience and business savvy.
They must have enough experience to be able to solve their own problems!
Specialization isn’t bad, but extreme specialization gets really tricky if you’re not in a large team all the time.
The larger the team is, the more that you can treat it like an assembly line. You can put specific people on specific jobs—database or front-end work—and for their part, the developers enjoy working in their primary area of expertise. For example, Facebook or Google want world-class specialists who know how to do one or two things really, really well.
But smaller teams, you need versatile developers who have enough familiarity with the different components to step in at a moment’s notice.
The good news is that generalists are more common because the jobs that enable specialists to focus on the one thing they do so well aren’t.
Some people are competent developers. They know good architecture and write clean code. But they may have an x-factor; they may be catalysts who push the rest of the team to be significantly better.
- They remove roadblocks.
- They set architectural decisions in the right direction.
- They just have a knack for doing the right things.
- They build consensus.
- They inspire confidence.
They find ways to make everyone more confident at both the macro and micro levels, and they make everyone better as a result.
This form of leadership is a specialization in its own right, and what is ironic about these individuals is that they often aren’t the obvious choice on paper. The Catalyst probably won’t be the right choice for your first hire, but she might be the fourth hire who rounds out your team.
One Last Trait We Like…
Before we land this plane, we’d want to point out one last trait: being opinionated.
We want our developers to have strong preferences and opinions, but we also pay close attention to how they approach those opinions.
Most every engineering decision comes with multiple variables, considerations, and tradeoffs. Smart developers will set aside their opinions and preferences when they face an unfamiliar problem or context. They will be open-minded because they view technology as a toolbox.
The toolbox mentality instead causes them to go looking for the right tool even if it isn’t their favorite tool. That’s definitely the way your developers should approach technology. You don’t want developers who treat their preferred tools like golden hammers. Whether it looks like a nail or a screw, they will smack it with the same golden hammer.
What traits do you look for? Hit us up on Twitter: https://twitter.com/clearfunction.