Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Learn from NO

DZone's Guide to

Learn from NO

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

Dear Reader,

Most companies have some variation of this process for interviewing developers.

  • Email discussion
  • Phone Screen
  • In-person interview
  • Job Offer
  • Successful hire

Between each bullet point is a decision point on the part of both your company and the candidate whether to move to the next step. Don’t assume that just because you have a job, the candidate will be willing to move forward at each step. Some candidates will excuse themselves from the process for a variety of reasons.

  • Salary range
  • On-site vs. remote
  • Industry is not acceptable to them
  • culture of the team is not acceptable to them
  • etc..

There are a myriad of reasons for the candidate to say No. The important thing is for you to learn from their NO.

Just like when a potential customer decides not to do business with you, when a candidate decides to break it off, find out why. Don’t be rude, don’t be surly, and certainly don’t be arrogant. Finding out why may help you in the future. Sometimes, it’s as simple as they aren’t interested in the work your team is doing. There’s not much you can do about that. You just have to accept it.

No doesn’t have to mean No.

Unlike other areas of life, when it comes to interviewing a candidate for a job, no doesn’t have to mean no. No could simply mean, not now. These are soft NOs. For whatever reason, the timing just wasn’t right.

If a candidate breaks off talks because of bad timing, then hang onto the candidates information, and all of your notes. Chances are real good that this won’t be the only time you are looking to hire. You’ve already done the research, you know that you are interested in this candidate and that they are not opposed to working with you. Start a file of these candidates – candidates that for one reason or another just did not work out. Once a quarter, review the file. Check up on the candidate and see if they are still at their job. You may want to go so far as to ping them and just say hi. You do not know what is going on with them. Keeping lines of communication open will keep you in the back of the mind of the candidate in case things do change.

When No does actually mean no, learn from the No

If the candidate broke things off because of something they saw or heard in the interview process – things like salary range, or “on-site vs. remote” – make a note of that. Those candidates are different from the ones that broke off discussions and gave you a soft NO. These candidates have given you a hard NO. They are ont interested in what you are offering. You may or may not want to keep in touch with candidates that give you a hard NO. The thing you want to do is make good notes as to why the candidate sad no.

Set aside some time in your schedule soon after the break, but not immediately after – to contemplate why. Yes, this is largely navel gazing but it is important navel gazing. Did they see something in your team that you can correct? Is there a problem you can work on? Not every NO will be something you can fix, or even your fault, but make sure you spend a little time thinking about it.

Depending on why the candidate gave you a hard NO, you may still want to keep in touch. If they said no because of the salary range, and you change the range, make sure and reach out to them to see if they are now interested in talking more. Regardless of whether the NO is a hard NO or a soft NO, never throw out your notes on a candidate. Even a firm NO is something you can learn from. You may not ever want to contact them again, but you will want to review your notes from time to time to remind yourself why they said no, and to see if you can avoid their reason for a NO in the future.

Hiring developers is easy, hiring good developers is hard. It takes a lot of work, an investment of time, and even then, there is no guarantee YES, just because you have an open position. If you are open to it though, you can learn from every NO.

Until next time,
I <3 |<
=C=

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

Topics:

Published at DZone with permission of Cal Evans, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}