As you successfully source good candidates, whether locally or online, and start to narrow down the pool, your role will shift from prospector to detective. You are no longer panning for gold. You are instead looking for clues that this developer won’t be a good fit.
Your primary goal at this phase in the hiring process is not to qualify candidates but to disqualify them as quickly as possible. Don’t put on your rose-tinted glasses quite yet. Software development is too expensive to risk being lax with your requirements.
With that in mind, take a phased approach to hiring:
- You may ask them to fill out an initial questionnaire.
- You may schedule an initial phone call.
- You may meet a candidate for coffee.
- You may hop on Skype for a video chat and code review.
Phases prevent you from making snap judgments and overly hasty decisions. As you get to know your best candidates across multiple platforms, you give them a chance to throw up red flags and yourself a chance to notice them.
Your questionnaire or first phone call should revolve around the obvious disqualifiers:
- Availability – The developer didn’t have enough availability.
- Location – The developer was unwilling to move or unable to work remotely.
- Skills – S/he had the wrong ones.
- Level of Experience – S/he lacked the breadth and depth of experience that your project demands.
- Salary Expectations – The developer was too expensive.
Sidenote about Budget – Don’t be afraid to introduce the money conversation early. You don’t have time to waste on a bad fit, and neither should they. You can save yourself (and the developers) a lot of time by learning in the first 10 minutes whether your budget can accommodate this candidate.
Once you’ve shortened your list, you can progress to the more subtle red flags.
Red Flag #1 – Missed Appointments & Phone Calls
Let’s start with initial back-and-forth communication. When you’re trying to set up a phone call or meeting, some developers will go dark. Even if they reappear later brimming over with apologies, you don’t always want to continue the conversation.
Sloppy or inconsistent communication often indicates a bad habit, not a random slip. Barring a family emergency or natural disaster, inconsistent communication represents a huge barrier to healthy workflow, particularly with freelancers and contractors.
On the other hand, if you’re looking to hire someone who will be full-time and co-located, then give the candidate a second chance. She may have been busy entertaining others offers, which is a good sign. You don’t notify your applicants right away, and the most desirable applicants may not respond to your communications right away.
So cut them some slack.
Now you understand why it’s tricky to know how much weight to give missed appointments and phone calls. Here’s our advice: Make note of poor communication. Proceed with caution. True red flags will beget other red flags before too long.
Red Flag #2 – Level of Interest
How curious is the candidate about the job?
If the applicant waits for you to answer all of the questions, he or she may just be bird-dogging a paycheck. Ambivalence, however, is a bad sign.
You want a developer who cares about the work environment and current projects. You want someone who displays knowledge and enthusiasm.
The best candidates will engage you with specific questions because they know who you are and what your company does. They want reassurance that they can do a good job for you. Like most people, they prefer to work on interesting projects!
The questions each developer asks will depend on his or her experience. Whereas mid-level developers might ask about your company’s development methodology, workflow, and pet technologies, new Computer Science grads may still be starstruck. Senior devs will ask fewer but more probing questions, and they’ll have the lay of the land sorted out inside of five minutes.
Red Flag #3 – Misaligned Passions
The types of questions that candidates bring to the table is even more telling than the questions themselves.
For example, one candidate may fixate on one specific aspect of your development process. The natural response to a negative past experience is to self-protect against similar experiences in the future. For that candidate to get hung up on one little piece is a yellow flag.
Ask indirect questions to figure out what’s going on there. Let’s say, for example, that the candidate insists that a certain method of continuous deployment is the best. Anything else is the worst. (We developers tend to be devout in our beliefs in specific methodologies.)
Passion is good. Passion we can work with. But a single close-minded individual can slow down development and poison an otherwise healthy team dynamic.
Yellow flags can become either green flags or red flags. Gauge each candidate’s areas of interests, their more pointed passions, and determine if those interests align with your work environment and team dynamic.
Red Flag #4 – Personal Issues
When you meet face-to-face or in a Skype video chat, you want to get personal.
Why is this important? Because people bring home to work with them. Ask open-ended questions, and most candidates will give you insight into their home life.
What are the things you’re looking for in an employer and future teammate?
What are the things that you would consider red flags that you try to avoid in future work and teammates?
In what kind of work environment do you thrive?
Their answers will reveal their concerns, and those concerns in turn will be a red flag or green flag. Here are some questions you want to ask yourself after the call:
Will this person get along with the rest of your team?
Do you see the tell-tale signs of landmines?
Did the candidate have a positive outlook on life?
Don’t forget to avoid any probing questions about protected legal statuses – it’s one thing if a candidate offers interesting information on their work style, quite another if you explicitly ask illegal questions.
Red Flag #5 – Unclear Communication
Some developers have the head knowledge. They can write the code. They can execute. But they can’t talk to me or to anyone else about their internal problem-solving rationale. Maybe nervousness caused them to freeze, in which case you make a joke or two. And when they loosen up, maybe their communication improves.
Regardless, you want a developer who can translate abstract thoughts, such as the functionality of an algorithm, into accessible language.
When team members can quickly lay out options, discuss the pros and cons of each, and come to a consensus, then that team can work efficiently. But take away that core skill of putting words to abstract thoughts, along with group problem-solving, and the team simply cannot perform at the same level.
Red Flag #6 – Wrong Personality for the Role
Different personality types fit different roles.
You may need someone to interface with clients on a daily or weekly basis; or someone to code seven hours a day; or a leader to coach and manage other developers. A client-facing engineer may need sales and negotiation skills, but an internal-facing engineer will need the technical know-how to lead projects.
You may find a brilliant, extroverted candidate who would thrive in one position but not the other. Make sure that you hire based for your needs not for charisma.
Red Flag #7 – Knowledge Gaps & Coding Mistakes
Eventually you will ask for a coding sample. You might even do some live coding or collaborative debugging with a candidate.
What are you looking for with this type of test? Openness.
You want developers who are transparent about what they do and don’t know. A general confidence comes from experience. You have seen ugly problems and tall challenges and have successfully surmounted them. Experience also brings humility. The more a developer has been through, the more likely he is to admit his weaknesses.
So you’re looking for experience, yes, but might also be trying to create a bit of drama and tease out a certain quality that you do not want: Developers who can’t admit they’re lost.
When a developer faces an unfamiliar and difficult problem, how does he or she react to it?
- Does he admit it?
- Does she double down and really attack the problem?
- Does he try to avoid it?
Some people get too cerebral during the coding test. They’re worried about having gotten the answer wrong or they are preoccupied with defending their choices. That kind of pride rarely leads to job offers.
Believe it or not, you don’t want know-it-all developers. In coding, for someone not to fly through the problem and get it right the first time isn’t a red flag. Day in, day out, that’s not how coding typically works. If the candidate solves the problem right the first time, he probably got lucky.
Speed does show a certain level of talent, but it doesn’t show me how quickly he can recover when he doesn’t nail the problem right away. We want to see how candidates respond to adversity. Consistently excellent software development requires emotional resilience.
On occasion, Colin or another seasoned Clear Function developer will know the right solution to a coding challenge and will explain it. If we sense the candidate gravitating towards that solution and getting excited about approaching the problem from that angle, then that is a good sign.
We look for enthusiasm, curiosity, and a desire to learn. Clear Function wants to foster a collaborative environment where it’s okay to not know everything and to invite other team members to help you problem-solve.
So yes, a negative reaction to learning something new is a major red flag.
You want developers who exercise good judgment and know when to bring in fresh perspective. You have to follow your nose as to whether or not the developer’s behavior and responses during the coding session are appropriate for the role you’re looking to fill.
What about you? What red flags have you noticed when hiring developers?
We’d love to hear from you on Twitter: https://twitter.com/clearfunction.