Agile Zone is brought to you in partnership with:

Software Developer, Mentor, Architect and UX/UI craftsman. Also, a psychology nut that loves curling. Zac is a DZone MVB and is not an employee of DZone and has posted 66 posts at DZone. You can read more from them at their website. View Full User Profile

Hiring Developers: How to Avoid Buyer's Remorse

10.28.2013
| 14987 views |
  • submit to reddit
The time has finally come. The budget has been approved and the request for more resources has the green light. This leaves one remaining step between the project and more productivity. Simply hire another developer and productivity increases, right? The math of more developers equals more output is a debate for the ages. But that conversation is based on the assumption that the additional developer will add value. Ask a group of developers about incorrect hires they've witnessed. The atmosphere will quickly turn into a fireside, war story discussion where developers compare the scars of their unfavorable interactions. Hiring the right programmer for the job can be a daunting task. Why is that? Are there common pitfalls that can be avoided? Let's dig in!


Before jumping in too deep, please note the words "incorrect hire" from the previous paragraph. This was intentional. Many use the words "bad hire" in an attempt to summarize a situation. The word "bad" has a broader definition that is less accurate. In Jim Collins book, "Good to Great," he discusses the concept of seats on a bus. If someone was not the right fit for a role, they might have been in the wrong seat and/or bus. Every person has different qualities, traits, and abilities.
Most hiring issues can be broken down into one of three categories: constraining factors, improper vetting, or lack of awareness. The following sections outline the problems found within each.

Constraining Factors
  • Hiring for a position often comes with a "hire by" date. Requesting an expedient hiring process is understandable, but enforcing a time line can lead to mediocrity.
  • Some feel the pressure to fill positions in an attempt to move the needle of progress. While this is commendable, guarding against unreasonable pressure must maintain a higher importance.
  • Budget constraints are a common hiring hurdle. One must pick his/her battles in this arena. Additionally, any disparity between the skills required and the salary allowed must be red flagged.
  • Some companies adopt a hasty evaluation process in an attempt to fill positions. Take time to call out these situations and challenge those on the impact of improper hires and their ripple effect.

Improper Vetting
  • Never hire in a vacuum. Include a variety of people in the process and encourage each of them to ask questions and provide a recommendation. Having a variety of opinions helps avoid "groupthink."
  • Don't overestimate a resume. Like a display window at a clothing store, resumes are built to draw people in. They are a conversation starter. Use them as a tool during the vetting process, but recognize their limited purpose.
  • Individuals who are naturally personable can have a calming effect on people. This can cause people to loose focus, lessen vetting efforts, and provide unsubstantiated recommendations.
  • Always test the abilities of a programmer. Although the difficulty and breadth of a test can vary, it's important to validate a developer can apply his/her skills.

Lack of Awareness
  • In situations where the hiring process takes an extensive amount of time or effort, fatigue can set in. This can inadvertently lead to a lowering of standards and disconnectedness.
  • Don't go into an interview without a clear understanding of the job requirements. Without this knowledge, recommendations may be offered under false assumptions.
  • During the hiring process, impatience is common. It can manifest in interviewers, managers, or other stakeholders. Be aware and stay on top of this as it can create unnecessary ground swells.
Published at DZone with permission of Zac Gery, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)