A Case For Hiring Malleable Junior Developers

TL;DR

Some of the risks that are associated with hiring junior developers can be managed by selecting for personality traits. One of the important traits, Adaptability, manifests differently in junior developers. By identifying it in the hiring process, you may be able to mitigate some of your risks.

Intro

It is a tragedy that many junior developers have difficulty securing jobs. I have met many people who have earned their proper credentials and have an excellent grasp of technologies, but who cannot find their first job.

I have interviewed, mentored and hired junior developers with no experience. I have also hired boot camp graduates, computer science interns, and self-taught developers. And along the way, I have encountered a universal apprehension around hiring junior developers based on the assumption that they will break stuff, need hand-holding or they will leave early. However, I have found that junior developers are not a homogenous group and each developer comes with a unique risk profiles based on his or her personality.

My experience has convinced me that junior developers, if given the opportunity, can provide significant business value, and can occasionally outperform senior developers — often in unexpected ways. I speculate that one of the contributing factors is the quality of adaptability. Hiring team can mitigate the common fears that are associated with hiring juniors by selecting for moderate adaptability in their candidates.

What is a Junior Developer?

In my field, web development, seniority is disproportionately influenced by a single metric: the cumulative number of years of experience in a specific technology or role. The classification is vague, and varies depending on the company, but in general I have observed that people with two years of experience or less are considered junior, while people with seven years or more are considered senior. Everyone else falls somewhere in between the two.

For the purpose of this article, I will define “junior” as anyone with less than two years of professional work experience. This includes self-taught developers, interns, CS graduates, coding boot camp graduates, and those who are just starting out.

Some Concerns With Hiring Juniors

These are some of the common objections raised against hiring junior developers:

Net Negative Outcomes

Juniors can cause more harm than good.

Many companies operate with fragile systems and without proper safeguards. As a result, they fear that a junior developer might accidentally commit a “rookie mistake” that can bring down the production environment and cost many expensive hours of debugging.

But a responsible software company that has solid processes — such as code reviews, automated tests with reasonable code coverage, QA, etc. — would withstand any chaos introduced by inexperienced developers.

Tip: Hiring a junior developer would reveal the weakness of such systems and encourage robust development practices.

Guidance Overhead

Juniors need excessive hand-holding.

In many companies, documentation is lacking, as there is an assumption that code and architecture should be self-documenting. There is a concern that junior developers may steal productive hours from senior members by asking “obvious” questions.

But a responsible software company would consider documentation a requirement and would allocate time and budget for ensuring documentation maintenance.

Tip: Hiring a junior developer could reveal where documentation is lacking.

High Turnover Rate

Juniors will leave after a few years. Given the high demand for talent, a junior developer may leave the company for a more lucrative offer after investing so much in them.

But a responsible software company has a healthy flow of new and old employees. If your employees outgrow their positions, it means you are doing something right — and more employees will be attracted to you. The average turnover rate in the tech industry is actually lower for juniors than for seniors.

Tip: The average turnover rate in the software industry is very high. For the reasons mentioned in this article, juniors are less employable than more senior engineers. Perhaps, it seems riskier only because of the perceived loss of initial investment in training them.

Many of these problems are not caused by the addition of junior developers to a team. Rather, they reveal pre-existing systemic issues within the processes of a company. A responsible software company should be able to rotate staff without major interruptions to the product.

What is Malleability?

The qualities that are needed for a job depend largely on the size and culture of the company, the company’s short-term and long-term business goals, and the reason for hiring in the first place. For these reasons, it’s challenging to create a broad definition of “quality” for developers that is applicable for all teams and companies.

In my experience, the criteria have varied as follows:

• I have worked at companies that hired junior developers based mostly on their academic credentials, by evaluating either the prestige of their school or their standardized scores.
• I have also worked at companies that completely bypassed the standard HR process and only required that the applicant submit an essay about solving technical problems.
• A recent employer had a policy against hiring archetypal “brilliant jerks,” so we turned down highly technically-qualified candidates because their personality was not compatible with the ethos of the organization

Over the last 10 years, I have interviewed, mentored, and hired junior developers. And I have found that the quality that contributed most to their performance was neither their crystallized technical knowledge nor their intelligence, but rather their adaptability.

Adaptability is the ability to provide consistent performance in a changing environment. Extremely adaptable developers have the most career mobility but are rare and hard to retain. Inadaptable developers stagnate in a comfortable position in their career ladder and become outdated quickly. However, developers with average to above-average adaptability tend to do well in organizations.

I will focus on what I speculate is a major contributor to the general trait of adaptability: an individual’s openness to change.

Openness to Change

“Openness to change refers to an individual’s level of acceptance and conscious awareness of the possibility that change may be needed across a range of situations and scenarios, together with the appetite or drive to enact that change.” — Oxford Review:

Developers who are highly open to change thrive in a rapidly changing environment, and those who are less open to change thrive in a stable and predictable environment.

I am not aware of any personality test that evaluates this quality. The Big 5’s openness to experience may have some correlation with this trait, but I shy away from making an explicit connection. I speculate that this trait is normally distributed in the population. I’ve roughly divided the continuum into 3 broad categories: Dynamic developers who are highly open to change, Malleable developers who are moderately open to change and Static developers who are resistant to change.

Dynamic Developers

There are some really impressive developers who have many mastered technologies under their belt. These outliers generally do not have trouble finding jobs. Their abundance of extra-curricular research, side projects and open-source projects makes them attractive. Many of them also have the innate advantage of temperament: a knack for problem solving, creativity, and strong abstraction that helps them outperform their peers. And they usually progress up the career ladder quickly as a result. They are novelty-seeking, consistently self-educating, and have a genuine love for their work.

A possible disadvantage is that they tend to get bored easily and their productivity may decrease if the work they’re asked to perform is not particularly stimulating. They have high turnover rates, and many venture into consulting or entrepreneurship after a few years. Their archetypal challenge is wearing all hats on a single head; they are jacks-of-all trades and masters of many. I call them dynamic developers.

Static Developers

There is another group of developers I call static developers. They are generally attracted to job security and are able to work in specific technologies for a very long period of time. They tend to follow a predictable academic and career progression, and learn best through structured processes. Many of them become masters of a specific technology over many years, and establish a safe niche within an organization.

The distinguishing characteristic of this group is rigidity; they perform reliably within a fixed set of environmental parameters (for example, technologies or processes) but are slow to adapt to novel problems and spaces. Teams with many static developers find it easier to outsource projects to third parties or hire additional talent rather than train these developers. These developers are masters of one.

Malleable Developers

And then there is the final group of developers, who are what I call malleable developers. They are somewhere between static developers and dynamic developers in their openness to change. Like dynamic developers, they can improvise in novel problem spaces when needed and provide adequate solutions. But they also possess the same ability to find reward in stable, conscientious output that many static developers possess. Their mercurial nature makes them very desirable for startups and R&D teams, where requirements can shift unexpectedly and quick adaptation is a necessity. They are jacks-of-all-trades.

The Underlying Reward Mechanism

Each of these types also finds reward in different aspects of the job.

Dynamic developers are process-oriented and find reward in novelty and intellectual stimulation. They are content as long as they are presented with a stream of challenging tasks.

Static developers find pleasure in doing things slowly and correctly. They are goal-oriented and strive to acquire deep mastery over a specific technology. They are comfortable with a steady and predictable path. They find intrinsic reward in becoming a domain expert.

Malleable developers enjoy getting things done. They are results-oriented and enjoy solving external problems (be they simple bugs or business needs). They are comfortable performing both routine and challenging tasks to solve problems. They find reward in solving problems for stakeholders.

The Junior Manifestation

Now that I’ve established a general profile of these archetypes, let’s explore how they manifest in junior developers.

Junior + Dynamic

Dynamic junior developers initially present with more breadth than depth.

They are stimulated by learning new frameworks and acquiring new skills. They know the latest tools and frameworks, and even know upcoming features before they are released. They have many side projects and a full portfolio with various stacks and frameworks. In addition, they maintain a queue of articles, languages, challenges, etc… They are always learning during their free time.

It is likely that they are as impressive in-person as on paper. They can provide an intuitive explanation for solutions, despite not knowing the answer. Independence of mind provides the flexibility to make optimizations, unhindered by stiff thinking, while being framework agnostic. This adds a wider experience to draw on when suggesting creative ideas for improvement.

However, once hired, they may be easily bored by the menial tasks of coding.

Sifting through thousands of lines of old code to fix bugs seems like a daunting task. They may feel tempted by the impulse to re-write/re-factor a module the correct way, or even re-write a project using a more modern approach. After a while, they could begin to miss the “fun” of working on exciting public-facing projects, and may find themselves pigeon-holed.

If a dynamic junior developer is fortunate, managers will place them on interesting projects that keep them engaged. If not, they may become disillusioned and use the opportunity only as a stepping stone to a more senior position.

The archetypal vice for this type of dynamic junior developer is impatience.

They will rightly feel that the tasks given to them are beneath them, and may thus have trouble completing some of them. Even though their frustrations may be sound, they lack the relevant concrete experience to prioritize the issue with the needs of the business in mind. In addition, they may neglect to see the value of practices like testing, documentation, error handling, and logging, and instead focus only on the fun parts. As a result, overconfidence can introduce breaking changes, and some decisions may be myopic or too optimistic.

They will make the greatest contribution by suggesting ideas for improvements, introducing new processes, and doing peripheral projects in their own way. Since they naturally enjoy the challenge of learning, they will be content with a stream of challenging projects — as long as there is enough variety and stimulation.

Risk of breaking things: High

Need for hand-holding: Low

Risk of turnover: High

Junior + Static

The static junior developer is probably the most abundant type of junior developer.

They have usually completed some sort of structured training program, and have a typical portfolio. Since they tend to be perfectionists, their portfolios will feature only their best work (per objective standards) and may seem sparse. Even at the junior level, they may show an impressive level of understanding of a specific library or framework, but their breadth will be limited.

They go by the books and are generally technically comfortable with the roles for which they apply. Most impressive about them is their meta-awareness of what they know and what they don’t know. In interviews, they usually either give very lengthy academic answers or honestly admit that they don’t know something.

The static junior developer excels in team hierarchies where there is a chain of command and they know who to ask for help. They are comfortable starting out with fixing small bugs, writing documentation, testing, and other areas where their thoroughness provides value (and where they can experience progressive stages of mastery). They thrive in well-defined problem spaces where they are aware of what is expected of them.

Examples of web development tasks where static junior developers excel include: Fixing cross-browser compatibility issues, writing HTML email templates, adding unit tests, improving code coverage, fixing well-documented bugs, and translating designs into pixel-perfect CSS.

The archetypal challenge for these developers is stagnation. Unlike dynamic developers, they fear change and avoid the unknown. If they are thrown into a chaotic situation or are forced to improvise, they will stall or recuse themselves unless they are confident that they can contribute value.

Once a static junior developer knows that they are valued and sees a clear path of career progression, they become fiercely-loyal employees. As such, their turnover risk is low.

Risk of breaking things: Low

Need for hand-holding: High

Risk of turnover: Low

Junior + Malleable

Malleable junior developers resemble static developers in many ways. Given the limited years entailed by their junior status, they may not have had enough opportunities to exercise their dynamic side, so they may even be indistinguishable from static developers on paper. They may even appear less impressive than their static counterparts because they generally lack thematic coherence of tech skills (thus seeming like dilettantes).

However, they can be very impressive in interviews as they tend to display a remarkable technology agnosticism. Their willingness to bend to fit the problem makes them open to learning or using whatever is necessary to get the job done. This gives them the advantage of being able to separate the abstract problem definition from a particular technology implementation.

Malleable junior developers have the work ethic of static developers and the resourcefulness of dynamic developers. They often gravitate towards cross-functional roles, even early in their careers. They may even pick up non-technical tasks like data entry or customer support just to get things done. Given enough time, they learn new skills at a reasonable pace and can improvise with incomplete requirements.

The tragedy of the malleable junior developers is that they often grow to be the Swiss army knife of a team. Because of their flexibility and general willingness to do any work, they are often handed tasks indiscriminately which they will complete diligently. However, their selfless lack of preference, while beneficial to the team, can make them masters of none. With proper support and guidance, they can become highly-functional employees with an interesting mix of soft and hard skills.

Risk of breaking things: Low-Medium

Need for hand-holding: Low-Medium

Risk of turnover: Low-Medium

Identifying the Types

Once you have decided which type of junior developer your team needs, you have to identify the trait in your candidates. Unlike the Big5, MBTI, DISC… and other instruments, the personality theory I’ve presented lacks an empirical foundation (aside from my anecdotes). Therefore, there is not (yet) an objective tool to discern between these types.

However, there are some speech and thought pattern “tell-tale” signs that can be seen in interviews.

In Interviews

The dynamic developer, owing to their lateral thinking tendency will infinitely expand possibilities (breadth) if given the time while the static developer will reduce possibilities to a few certain outcomes (depth). The malleable developer will reconcile these opposing tendencies within his or herself by making heavy use of abstractions.

Here’s an example:

Question: For project ACME, how would you persist the data given the following constraints? [Constraints]

Dynamic: Depending on [factors], I would use either this set of NoSQL databases [a long impressive list] or one of these RDBMS [another long impressive list] because they offer XYZ. However, I’m only familiar with Mongo… although I’ve also dabbled a bit in CouchDB and Redis. I’m really comfortable using any database. Did you hear about the new Neo4J feature that lets you…

Static: I would write a MySQL query, first making sure the data is sanitized and ensuring the syntax is compatible with MySQL 5.7. I would use ABC ORM and do it as [such and such]. I am familiar with most of the SQL syntax of MySQL, as well as the recent changes in 5.7. I don’t really know about other databases. I plan to take a course on other databases in a few months.

Malleable: Depending on the [factors], I would use your supported database engine with the needed features and work with your existing ORM to persist the data. I am familiar with some RDBMS and NoSQL databases, but I am willing to learn other type of databases if needed.

The Case for the Malleable Junior Developer

A malleable junior developer can provide the immediate value that a dynamic developer provides, without the high risk of turnover.

A malleable junior developer can also provide the productivity that a static developer provides, without the need for hand-holding, stagnation or becoming outdated.

For these reasons, I argue that hiring a junior developer with moderate openness to change provides a balanced long-term outcome.

The Case for the Other Types

Your immediate needs and the nature of your company should determine which type of developer your hire as there is a specific niche where each type excels.

For example,

If your team requires highly specialized knowledge in a specific well-defined area, a static developer can provide strong business value given that you allocate time to train them.

If you work in a highly volatile environment or have a lot of quick ephemeral projects (prototypes, MVPs, internal tools), a dynamic developer will get you there given that you give them creative freedom and autonomy.