Skip to content

Can I Afford This Job?

Money by Andrew MagillDear Reader,

Here is a quote job post I saw recently.

They are offering competitive salaries, benefits (vacation, medical, dental, vision), a 401k plan, as well as a fun collaborative working environment (catered food truck lunches, theme park outings, big charity events and more).

Sounds interesting right? If I am a Junior developer making squat or near squat, I am interested. However, if I am a Mid-range developer, Senior developer, or a System Architect – or if I am a developer with a family that depends on my salary and I have a minimum salary requirement – I’m conflicted.

Do I bother to apply? Are there other signals I can use to deduce whether this will be a waste of my time or not? What is “competitive salaries”? Who are they competing with? If they are competing with fast food restaurants, that’s going to be a different number than if they are competing with investment banking companies.

As a hiring manager you haven’t done your job. You have told me how great the job is, but you’ve not answered the question “Can I afford to take this job?”.

As my friend Sean Coats pointed out in the comments of “The secret to writing a job post to attract PHP developers”, salary is important when deciding whether to apply for a job.

Help developers pre-qualify themselves for your positions. Save yourself the time and aggravation of interviewing someone only to find that they can’t afford to take the job. Help developers answer the question “Can I afford this job?”. Put a salary range on your job post.

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

Photo Credit: Money by Andrew Magill
Used under CC license

Learn from NO

NO by Nathan GibbsDear 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 candidate’s 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 not 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 said 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 guaranteed 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=

 

Photo Credit:No by Nathan Gibbs

 

Don’t Hire PHP Community Members!

Dear Reader,

It is no secret that I spend a lot of time promoting the PHP Community. It is a vibrant, helpful and friendly community and I’ve said before that I believe it to be one of the most important assets of the PHP language.

I’m also a realist though; I’ve built teams and I’ve hired developers. I know what it takes to put together good teams, I’ve even written down my thoughts on hiring and managing developers elsewhere. I have experience in this area and I have strong opinions. I am going to share one of those opinions with you right now.

Don’t hire developers who are active members of the PHP Community.

PHP community members solve problems

Active members of the PHP community solve problems. I mean they get their hands dirty in code – theirs or someone else’s – and solve problems. They are used to collaborating with other PHP community members to solve real world problem for themselves, their employers, or other community members who need their help. They spend time helping friends on IRC solve problems; problems that they may eventually face in their day job. They don’t do it because they were paid to; they solved the problem because they could.

If they can’t solve a problem, they usually know who can

Active members of the PHP community not only share what they know, they build up a list of others who are willing to share with them. Most of the time it doesn’t matter if the problem is for a project they contribute to or part of their day job, if there is a problem to be solved, members of the PHP community know who to call to get help. Since they help others, they have a cache of good will that they can use to get problems solved at work.

They love to show off

PHP community members love to show off and they do so by helping others. You can often find them showing other teammates something new they learned while working on a project they contribute to in their off-hours. They organize User Groups just so they can show off to others. It’s why they love to speak at conferences, so they can show off stuff they have learned.

They make their employers look good at conferences.

Active PHP community members love to speak at conferences and they will want you to help pay for it. Their speaking is nothing more than showing off. It doesn’t matter that their presenting makes your company a thought leader and makes it easier for you to attract other developers. All you get as a return on your investment is a smarter, better connected, inspired and rejuvenated developer. Trust me, I understand, you’ve got deadlines to meet and can’t have a developer out for a week showing off and finding solutions to the difficult problems they are working on for you. It doesn’t matter that they come back energized and inspired. It probably doesn’t even matter that they burn off all this new-found energy solving problems, and building solutions faster and better. All that matters is they weren’t in their cube for a week, right?

They work for free

No, not for you, don’t be stupid; but most active members of the PHP community contribute to one or more open source projects on their own time. This means that even when they aren’t paid to do so, they are coding; learning, honing their skills that they then come back and use for you.

Conclusion

In short, no, don’t hire active PHP community members. Hire the developers that are happy to punch in at 9 and out at 5, go home and tinker in their workshop. Honestly, there are enough teams out their vying for active members of the PHP community because they recognize them as the cream of the crop as far as developers go. They want them on their team and are counting on you to to pass over all active PHP community members because you think they they are too high maintenance. You keep thinking that, just hope your competition does too.

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

Update:

I’ve had several people tweet to me asking if I was being serious or sarcastic. (“You serious, Clarke?“) This post is of course, tongue-in-cheek. Active members of the PHP community are some of the best developers you can hire and are a sought after commodity. If you are lucky enough to hire one, take care of them and hold onto them.

How do I find good PHP developers?

Dear Reader,

Twice this week I got asked a similar question, “How do I find good PHP developers to hire?” The first one was a recruiter who had originally tried to hire me because she “read my resume”. (Obviously, she skipped over the part where I’ve not written any serious code in several years) Since she didn’t bother to really read my resume to begin with, I’m pretty sure she won’t bother to read this post.

The second one, however, was a just someone trying to find PHP developers for his team. Since he wrote me a nice email asking advice, I decided to reply in kind. Three pages and one thousand words later, he had my answer. (Honestly, I didn’t expect it to be this long) I share it here with you – slightly edited to remove some geographically specific advice that probably won’t apply to you – in hopes that when you are in the same position you can get a head start in finding good developers.
(more…)

Two Rules for Hiring/Retaining Developers

Dear Reader,

Most of you know, but some of you may not know, that one of the consulting services I provide is helping people identify and hire quality PHP programmers. I’ve been hiring developers for a long time now and inevitably, someone will ask me in a conversation, “How can I find good programmers?” Since I assume they know that I charge people to do this, I always refrain from the obvious answer, hire me.

However, after having a variation of this conversation for the then thousandth time recently, I decided to lay my cards out on the table and tell everybody the secret. Feel free to use this without hiring me but remember that if you get stuck, I’m here for you.

Looking back over the 200+ developers I’ve hired in my career as a manager, I can honestly say that hiring and retaining good developers can be boiled down to two rules. Everything else that goes into the process is just details. (And I do want to apologize to my friend Leslie who is in HR. I do not mean to minimize your job by saying you are a detail!) :)

Developer Hiring Rule: Only hire developers you trust.

I’ve laid out elsewhere my process for hiring developers, those are the details. The decision though as to who gets hired and who doesn’t comes down to a matter of trust. To put it a little more bluntly, trust your gut/instinct. As with any hiring manager, I’ve made bad decisions, in all but one case that I can think of though, bad decisions were made because I did not trust my instinct on a person.

This is an especially important rule for small businesses. You may only hire one or two IT people for your entire company. Make sure you really feel that the person is a good fit, both skill wise and personality wise.

Developer Retention Rule: Trust your developers.

If you followed the advice of rule #1 then this one should come easily. I’m not advocating handing a new hire the keys to the company but your developers, more than anyone outside of your management team, will know the inner workings of your company. If you are not a software company then your IT staff will have access to a number of important facts not known to others in the company. If you followed Rule #1 then you’ve got people you trust…now trust them to do their job.

If you are a software development company this is especially important. As a matter of fact, if your company makes any part of it’s revenue stream from software development or from providing services built by developers, and you personally do not write code, you company’s fate is in somebody else’s hands. You want to make sure that you followed Rule #1 and hire people you feel you can trust and that you then follow Rule #2 and trust them to do their job.

What to do when either rule fails you.

Actually, the better question is what can you do when you failed to follow one of the rules. One of the greatest bosses I ever had gave me some sagely advice. “A sharp knife cuts clean.” If you’ve got a developer on staff that you cannot trust, get rid of them and do it quickly and unambiguously. (local labor laws not withstanding)

The #1 task is to get rid of the developer before they become a problem. The second task though is to let the rest of the team know exactly what went down, why the developer is not there and reassure them that their jobs are not in jeopardy. It always astounds me when people suddenly disappear form a corporate org chart without explanation. Does upper management (C-Level usually) think that nobody will notice? Do they think not saying anything is actually better for morale than being open and honest with their employees? remember, you’ve hired people you can trust…trust them to be smart enough to be able to handle the information.

So there you have it. If you don’t want to hire me to help you build your PHP development team, those are the two rules I use to hire and retain good developers.

Until next time,
(l)(k)(bunny)
=C=