Navigating the Challenges of Hiring a "Messy Coder"
Written on
Chapter 1: The Hiring Experience
Recently, our software engineering team welcomed a new member, despite some reservations that emerged during the interview process. Unfortunately, it appears that things are not progressing as hoped. Here’s the account of how we ended up hiring a coder with a messy approach.
Our interview process has its flaws, which sometimes results in hiring developers who may not meet our expectations. In this instance, we brought on board a software engineer whose coding skills were not up to par.
Section 1.1: Interview Insights
During the front-end interview, we engaged in a relaxed conversation with several team members, followed by a live coding task (or as close to live as screen-sharing allows). The interviewers noted a couple of concerns regarding the candidate's performance:
- They seemed to rush through the coding task.
- There appeared to be a lack of pre-planning before diving into coding.
While these comments alone are not necessarily alarming, one particular observation has lingered in my mind. A senior team member labeled the candidate a "messy coder."
Subsection 1.1.1: Understanding the Term "Messy Coder"
This label can be misleading. A "messy coder" doesn’t imply that the individual produces poor quality code. Often, this designation stems from a coder working outside their primary language or hurrying due to significant pressure.
Section 1.2: The Rationale Behind the Hire
In an interview context, the reasoning behind less-than-ideal coding should ideally be irrelevant. However, it raises an important question: why would we choose to employ someone whose coding falls short of our standards?
Currently, we aim to bring in higher-quality permanent staff, as opposed to relying on an army of contractors who prioritize immediate problem-solving without considering future code maintainability. This shift has created an urgency to hire anyone who can produce code.
Chapter 2: The Reality of the Situation
As I interview candidates, I envision an ideal developer—not necessarily the fastest or the most skilled, but someone whose work is reliable and requires no further intervention. A proficient coder may take longer to finish tasks, but their output functions seamlessly without the need for revisions.
In stark contrast, our new hire is quick but frequently delivers flawed work. The repercussions of their carelessness have become evident: colleagues are voicing frustrations over prolonged code review processes due to the complexity and size of their tickets. Working with this developer is taxing for the team, leading to a sentiment that it might not be worth the effort.
My Concerns
I've witnessed similar scenarios in the past, and I'm worried about the team dynamics. The potential outcomes include:
- Team members becoming frustrated with our messy coder.
- The coder losing confidence in their abilities.
- The coder potentially leaving the team or being placed on a performance improvement plan, eventually leading to their departure.
This situation is disheartening and incurs both time and financial costs, draining the energy of the entire team. Frankly, I just want to focus on my own work without these complications.
Conclusion: A Missed Opportunity
In an ideal situation, I would advocate for the development of this coder through tailored training and clear expectations, ultimately nurturing them into a valuable team member. However, that is not the reality we are facing.
About The Author
Professional Software Developer “The Secret Developer” can be found on Twitter @TheSDeveloper and regularly publishes articles through Medium.com.