What Characteristics Can Be Used to Predict Software Engineering Success?

This question has occupied much time in my thoughts over the past several years as I’ve continued to flesh out ideas around my three-dimensional approach to assessing talent (skills, competencies, characteristics), I’ve wondered about the distinction between competencies and characteristics. Are they the same? Are they different? Is the distinction important? At times, I’ve considered them as part of the same category. However, though the distinction is subtle, the two are not the same.

‘What’ vs. ‘How’ vs. ‘Why’

I finally had an epiphany that helped me understand the difference. I realized that skills are used to accomplish the ‘what’. Competencies influence ‘how’ we accomplish what we do. And characteristics help define ‘why’ we do what we do.

(Skills, Competencies, Characteristics) = (What, How, Why)

Does it matters whether we know why an engineer does what they do? It not only matters, but is vital to predicting their success in the role. When surveying engineers, you’ll find some love the challenges provided by their career choice, others hate it, and the rest are anywhere on the spectrum between these two extremes. It should come as no surprise that the best engineers love their job and have the requisite competencies needed for excellence.

I first formulated the three-dimensional approach to talent assessment while working for a large banking organization. To say this approach is unique wouldn’t be entirely accurate, as most organizations employ some sort of behavioral assessment during the interview process. These behavioral interviews incorporate both characteristic and competency assessments. However, there were two things that I did differently which significantly improved the interview process.

• I incorporated this three-dimensional assessment into the technical phone screen. During the phone screen, along with the requisite screening of technical skills, I would dig deep into the technical competencies and characteristics that identify great engineers. By incorporating these dimensions into the beginning of the interview process, I was able to significantly improve the offer rate of candidates who progressed to onsite interview. In our division, prior to employing this approach, the offer rate for candidates coming onsite was less than 15%. However, candidates screened by me were offered positions 95% of the time when coming onsite. This was because I’d already weeded out those who would perform poorly during the behavioral interviews. Because of the stark difference between my performance and the other phone screeners, I was asked to train all interviewers on this three dimensional approach.
• I created questions and scorecards that specifically addressed necessary components of each dimension. Typically, phone screens in our division were 30 minutes long and consisted of questions focused on technical skills. However, when it comes to talent assessment, skills are the easiest to acquire, and the least important when determining an engineer’s potential to be productive. I created a set of questions which I used to discover specific characteristics and competencies. Each phone screen was 60 minutes long. Each candidate received all the same questions. This created a consistent candidate experience, and made it easier to compare one candidate against another. The questions were designed to elicit conversation. This conversation painted a picture of a candidate’s overall skills and experience, but more importantly, told a story of their competencies and characteristics. What was their level of intrinsic motivation? What was their aptitude for learning? Were they able to articulate and communicate complex technical concepts? Each of these questions was designed to assess various competencies and characteristics. The candidate was then scored on each of their responses. A dashboard was used to tell a story of how a candidate fared along each dimension of skills, competencies, and characteristics.

The sections below describe the characteristics I’ve found to be critical in predicting great software engineering talent. Each section also contains a link that describes each area in much greater detail, and also includes a number of questions that can be used to assess each of these characteristics.

---

Expert Problem Solver

A software engineer’s primary responsibility involves solving problems. For each problem encountered, there’s a set of real or artificially imposed constraints that make the solution difficult. It is critical for an engineer to use analytics, logic, and reason to draw meaningful conclusions from ambiguous data. Constraints are imposed from a wide variety of sources. They may be in the form of cost, performance, customer, deadline, quality, environmental, etc.

Assessing Problem-Solving Capabilities in Software Engineers

---

Intrinsically Motivated

The work of a software engineer frequently involves the need for long periods of intense mental focus and concentration. Whether it’s designing a new platform, implementing a new framework, fixing a complicated production issue, or learning a new programming language, a software developer is under constant mental taxation. The fast-paced environment can be stressful for many engineers and the rate of employee burnout in the technology industry tends to be quite high. Intrinsically motivated engineers are drawn to the profession because they love to solve challenging problems, they enjoy learning new things, and they are fueled by the numerous opportunities to increase their knowledge and skills.

Assessing Intrinsic Motivation in Software Engineers

---

Aptitude for Learning

A software engineer’s context changes extremely rapidly. New technologies and frameworks are introduced continually. Developers must devote significant time and energy to learning activities just to stay relevant. Because the pace of change is so rapid, engineers who are learn quickly are better equipped to leverage the changing context.

Assessing Learning Aptitude in Software Engineers

---

Humble Team-First Attitude

There’s a silent killer on the loose. It’s the killer of productivity which results from low team morale. It takes on many shapes and it’s often reincarnated in the form a self-serving team member who puts individual needs and desires before the needs of the team. It knows not the boundaries of gender, race, religion, nationality, or technical competency.

Assessing Humble Team-First Attitude in Software Engineers

---

Accomplishments of Increasing Impact

The story of a software engineer’s motivation, aptitude, and desires can often be played out between the lines of their resume. While it frequently requires some digging, buried between the wood fibers and ink is a tale of successes, failures, accomplishments, and disappointments.

Increasingly significant accomplishments over time showcase a motivated engineer who loves learning and has the aptitude to take on progressively more complicated tasks and responsibilities. These accomplishments demonstrate not only technical aptitude, but leadership and influence, and often result in significant organizational impact.

Accomplishments of Increasing Impact in Software Engineers

---

Lucid and Articulate Communicator

The practice of software development frequently requires complex thoughts to be conveyed from one engineer to another. Transforming a concept into a design, and then a working implementation requires that multiple developers share their ideas in ways that are easily understood.

Engineers must effectively communicate with all audiences. As technology provides development teams with exponentially expanding volumes of information, the ability to filter, distill, decipher, and convey information becomes increasingly important. Those who lack communication skills will be forced to improve, or risk becoming irrelevant or obsolete.

Assessing Communication and Articulation Capabilities in Software Engineers

---

Great Judgment and Context Awareness

Every day, engineers make decisions that can significantly affect the success of a product. It is important for them to fully understand the context in which they are making these decisions. This includes the technology landscape, the customer needs, the problem space, the constraints, the risk, and the potential opportunities. Judgment calls frequently need to be made, and without the appropriate context, the likelihood of a poor decision increases significantly.

Assessing Judgment and Context-Awareness in Software Engineers

---

Coachable and Accountable

The operation of a software team is a fluid situation. Technologies become obsolete, frameworks come and go, and process methodologies are continually changing. This environment creates numerous coaching opportunities for both teams and individuals. The willingness to accept coaching is a key characteristic of any great engineer.

Assessing Coachability and Accountability in Software Engineers

---

Software Craftsman

Software Craftsmanship is the art of knowing what is beautiful, and caring enough to make it so. Problem-solving abilities don’t necessarily equate to craftsmanship. Code that has been crafted by an engineer who cares is much more maintainable, readable, less convoluted, more easily understand, and significantly more pleasurable to work with.

Assessing a Software Engineer's Propensity for Software Crafsmanship

---

Related Posts

---

Do You Lead a Software Team?