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: Slow Down to Speed Up

  • submit to reddit
Finding and hiring talent in the technology industry has been ongoing for decades. One might assume early stumbling blocks have been identified and rectified, right? Unfortunately, hiring development talent is still a difficult area for many employers. Why is this? Most do not recognize the monumental task ahead of them. Having successful, productive employees isn't about hiring the right person. That's secondary. The first step is finding the right kind of people. These individuals are highly skilled and share the core values of a company. They need to shine bright in a team or individual setting. These people are commonly called "A" players or a "10" (rating talent on a 1-10 scale). Good programmers are worth their weight in gold! To clarify, one should be looking for 10s or individuals with the potential to be a 10. Even the most gifted minds don't start their career as a 10, but they have a key attribute in common "potential." A hasty hiring process can lead to hiring 7s or 5s. This is a very slippery slope. So, what's wrong with hiring a few 7s and 8s?

Hiring unqualified talent creates two problems. Without proper guidance most individuals tend to hire others who are similar to them. In other words, 7s don't hire 10s. They hire 5s and 7s. This can spiral into a vicious cycle of mediocrity. Mediocrity is a common enemy of every business. No one wants to have an average product/service or acceptable staff. They want to be the market leader with highly exceptional talent. The second problem: 5s drive away 10s. High caliber talent appreciates working with similar talent. These individuals collectively increase their abilities through challenging one another. This is where "iron sharpens iron." They can also effect potential 10s through osmosis.

Identifying great talent starts with slowing down. Finding the right talent and finding Mr. Right should be viewed in the same vain. It's a marriage and from that union should flow a prosperous outcome. The following is a list of recommendations for hiring 10s:
  • Don't interview in a vacuum. Engage all potential team members in the evaluation process. Other relevant employees might also provide interesting insight.
  • Encourage the natural instincts of those involved. If something doesn't feel right, dig deeper to reveal the underlying reason. Everyone should be encouraged to speak openly and freely.
  • Seek unanimous agreement by all members. If there are any reservations, they should be discussed. It should be a no-brainer.
  • Maintain a mindset of finding the "right fit" and not the "right now fit." Don't be afraid to keep looking.
  • Look for 10s and potential 10s. This can be accomplished in a plethora of ways including personal/phone interviews, multiple visits, personality evaluation, tech screening, programming tests, etc.
  • Identify individuals who adapt well to change. This is a common trait of highly effective people.
  • Seek out candidates who can have well versed dialog about topics. They should display enough knowledge to show exceptional proficiency.
  • Don't hire "yes" men. Look for people who can articulate opinions but are open to constructive dialog.
Although most companies cringe at the concept, they should continuously look for programming talent. Even a passive approach is better than jumping in and out of the market. Good talent is hard to find and most already have jobs. Some don't even make it to the market as potential companies lure candidates away. But when they do enter the market, they are snatched up fast.
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.)


Lund Wolfe replied on Sat, 2013/06/08 - 2:27pm

Totally agree with the "it takes one to know one".  It is apparently very hard to identify a "10" even when one is right under your nose.  At least make sure you have your own developers at the interview and give them advance notice to prepare questions or even review the candidate resume.

It is common to ask little or no technical questions in an interview, which is a huge mistake.  Even a trivial programming exercise is useful, too.  Candidates can be confident and happy but completely lacking in technical competence.  Ask questions at the level of the position or need.  You'll be wasting your time if you ask senior level questions of a junior or mid-level candidate.  Don't ask junior level questions if you need a senior level position.  That said, not every position needs to be a "10".  Some projects have little risk and any semi competent developer can deliver so pick someone you like, a good fit.

Don't settle for a candidate who seems "good enough" or the best of the lot.  Continue interviewing or wait and try again later.

Developer Dude replied on Mon, 2013/06/10 - 6:30pm

Sure, keep on looking. I have seen more than one org that looked, and looked, and looked, and was still looking more than two years after the initial posting. To be fair, I don't think they were looking for a "10", they were looking for a "perfect fit" to their artificial criteria - there is a difference; a "10" may not have 5 years of experience with the WebSphere, instead having only 1 month with WebSphere and maybe 7 years with Tomcat, but that "10" could certainly get up to speed on WebSphere quick enough to be productive.

As for a "10" knowing another "10"; if you think you are a "10" you probably aren't - probably more like a "5"; google "Dunning Kruger effect". Also, not every position requires a "10", and being a "10" in a position where they are working on "5" tasks will have that "10" looking for a job elsewhere pretty quick.

I have worked with people who were smarter than I am, and I thoroughly enjoyed it. It was an opportunity to learn. When I interview I look for people people as smart or smarter than I am, and while I might not be a "10" (I doubt it since I *know* a lot of people that are better devs than I am), I continually improve and more importantly I can recognize smarter people, who I would anticipate can also recognize smarter people yet - so I dispute your assertion that only "10"s can recognize "10"s.

Mark Unknown replied on Wed, 2013/06/12 - 5:04pm

I agree mostly with the other commenters.

I would add that you cannot just hire smart people. You have to hire people with ability and more importantly capability. I have worked with plenty of smart people who were not very good at their job because they didn't have capability in the right areas.

Also, in addition to asking senior questions to senior people (and etc) you have to ask questions appropriate to the role and job. If you are hiring an architect, you should be asking architect questions - not have they memorized and API. If you need business app developer, don't ask them "engineering" questions.  You do NOT want someone who is good at algorithms (and thus things like search engines) writing business apps. (i.e. look at the recent post here on dzone from the guy who started Mono. He did a good job on Mono but he seems pretty clueless on building business apps).

Robert Carter replied on Wed, 2013/06/19 - 9:29am

Not to point out the obvious, but a lot of companies want potential and existing 10's but only want to pay them the salary of a 5 or 7.

A company cannot attract and keep good talent and yet pay them below market... but too many companies these days think they are getting something better for less... You get what you pay for.

Lund Wolfe replied on Sat, 2013/06/22 - 6:07pm in response to: Developer Dude

In response to both comments, I think we are talking about ability (usually backed by intelligence).  We'll just call the role Java Developer, but interview questions and problems should be directly related to what is needed on a day-to-day basis for that position in that company.  Don't be good, be good for something.

Sometimes a company does need a specialist/expert in SQL Server performance tuning or an expert tool user, like Websphere or something, and they should target hiring for that skill, but usually they should hire someone able to build quality applications.  Hiring enough experts to cover all the technologies and tools you use or plan on using is no guarantee that you'll build quality applications.  That kind of thinking is very scary.

Mark Unknown replied on Sat, 2013/06/22 - 7:39pm in response to: Lund Wolfe

+1 Lund. I totally agree.  If one is hiring by using the standard acedemic questions , logic questions and coding tests, one is not doing what you are saying. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.