Targeting Skilled Programmers/Developers
Hiring developers is one of the most challenging tasks IT executives face. How do you find ones who code flawlessly but also are good team players?
Chad Lilly, director of recruiting at Lextech, has more than 16 years working in the professional services market connecting employers to talent. To help you make your next great hire, Lilly shares this advice for IT executives: "A superstar developer is rarely on the market, as they are well-regarded by their peers. In my experience, about 2% of developers on the market are superstars, 30% are solid developers and the rest are the remaining 68%."
Stats like these demonstrate the need for sound practices and skills when looking for your next developer, because failure can mean missed deadlines, bad code and poor standards.
What makes a great developer, a great developer? Most share these common traits: curiosity and a desire to learn, great problem-solving skills, the ability to deal with several layers of abstraction at the same time, solid communication skills and a belief that in most cases simpler is better.
Finding someone who encompasses all these traits is what Lilly describes as "finding a diamond in the river. You have to dig for them." To help you mine for these diamonds, Lilly shares some of the tips and tricks he uses to find talent in the vast mountain of IT professionals.
1. Be Forward Thinking
This is a huge part of finding the right candidate. Many companies don't take the time to consider the future when they hire a programmer. "With newer technology", Lilly says, "developers will have less of the actual specific technical expertise, so hiring managers must realize that it's more of the aptitude that matters. There won't be someone who has four years of experience with a technology that's only been around for two years, so this is especially where forward thinking on behalf of hiring managers comes into play".
Another example that demonstrates the point: Company "A" has been using a proprietary CMS for years but in the next fiscal year it is considering a move to an open source CMS, like Joomla or Wordpress, to save money.
You would imagine if they were on the market for a developer they would search for someone who knows open source but surprisingly many don't. Uncounted companies simply look at the skillset of the person that left or they consider only the current systems and technology that are in place. Be forward thinking--what is coming down the pipe, what will I need next year? "Recognize that new technologies will spring up and think ahead to what talents you'd want a developer to have in order to adapt to that new technology quickly," Lilly says.
2. View Their Portfolio
Any good programmer should have no problem producing a portfolio of items he/she has worked on. Not every developer will have a brilliantly fleshed-out portfolio and that's fine. Regarding developers, Lilly points out that, "past projects or coding are proprietary or embedded in a past corporation's system."
Look for CodeProject, StackOverflow profiles or open source contributions. "This is an especially beneficial additional piece for candidates to talk about during the interview and for hiring managers to check out, Lilly says, "Other side projects that they're working on can act as pieces for their portfolio as well."
You'd also be wise to eye any public social networking profiles they maintain. Do they maintain a professional Web presence? Have they spent time bashing their last company or boss? Candidates beware, Lilly says, "all candidates in any industry should expect employers to Google them."
Knowing what type of work people have done in the past and seeing how they conduct themselves on social networks will give you a better understanding of the candidate's strong and weak points and how they will conduct themselves in the work place.
3. Do an In-depth and Structured Phone Interview
This process is designed to weed out the unqualified candidates and demonstrates how the interviewee will react when faced with a real coding challenge. There are a couple common mistakes that you should avoid.
Don't let the interviewee drive the conversation. Guide the interview and ask questions that you feel will pull the developer out of their comfort zone. Watch out for single faceted developers or programmers who have spent their entire career focused on only one platform. That should throw a red flag to employers. Don't just ask questions about items on a candidates resume, because they are well-versed on these items and have answers planned accordingly. Instead, Lilly says, focus on these questions.
What is their favorite language to develop in.
Why do they like it?
What would they change if they could make it a better language?
What has been their most challenging project to work on?
What new technology are they looking forward to using on their upcoming project?
What changes in the industry will affect the future
If you were in charge in your last position, what would you change to make it a better role for you?
These types of questions are often used to gauge a candidate's passion and knowledge. Questions should, of course, be tailored to the individual's skillset. What you want to uncover is how passionate this person is about the platform or technology. How well do they know it? To achieve this try and form questions that require thought and an opinion.
This is why it's so important to know a little something about the platform the candidate is interviewing for. Many developers have expressed frustration when being interviewed by an individual who doesn't understand programming at all.
This article by Stevey Yegge focuses squarely on how to do a an effective SDE phone interview that will help you flesh this process out. Here is a brief excerpt that outlines his approach:
Coding. The candidate has to write some simple code, with correct syntax, in C, C++, or Java.
OO (Object-Oriented) design. The candidate has to define basic OO concepts, and come up with classes to model a simple problem.
Scripting and regexes. The candidate has to describe how to find the phone numbers in 50,000 HTML pages.
Data structures. The candidate has to demonstrate basic knowledge of the most common data structures.
Bits and bytes. The candidate has to answer simple questions about bits, bytes and binary numbers.
In the end, you are looking for deal-breaking knowledge gaps. Can this person program? Does he/she understand the technology? Moving forward, the question you need to ask yourself each time a person makes it to a face-to-face interview and fails is this--how could this have been uncovered on our earlier phone screening?
4. Surprise Them
You've committed to the face to-face interview-it's time to get them thinking. Lilly recommends, "Lego Mindstorm," a toy that combines Legos and programming. Using this simple toy can give you real time insight into your candidate's problem-solving skills. An interviewer would want to gauge their response, do they consider it fun, challenging or frustrating. The end game here is to see how the candidate thinks.
As we discussed earlier curiosity and problem solving skills are paramount. Seeing how the developer responds will let you know how they will react when they are faced with a real world problem. An applicant who maintains a negative attitude or states things like "what is the point" should raise some red flags for employers. "Some", says Lilly, "have just gotten up and left".
Mindstorm is a tool that can be useful but there are others out there. No one understands what your company needs better than you. Think about how you can keep your applicant thinking and on their toes.
5. Do They Play Nice?
Why is this important? Because more often than not developers work on a team--gauging how candidates work in a team environment is another great way to gain insight into their real personality.
Lilly suggests several techniques for this: "Play Pictionary with a group of people from your office, toss the football or Frisbee around outside." Get them involved and then watch and answer these questions:
Do they participate?
Do they wait for instructions?
Are they communicative?
Are they dictatorial?
Knowing how a person reacts to a team setting will help you understand more about the person behind the resume and that type of information is invaluable.
6. Practice Coding Tests
Anyone who works in IT will tell you, there are a lot of programmers out there who have no business in the IT field. The simplest way to sort the riff-raff from the players is a simple coding test. This should be an integral part of the process whenever you are interviewing a programmer. The goal is to eliminate the candidates who aren't qualified and gauge the level of candidates who are.
Each organization is unique so many choose to create their programming test in-house. However, there are several places online that offer practice coding tests. Here is a sample of sites that offer these:
These tests should be short about or hour or so. The information they yield can be telling about your candidate.
How do they code?
Do they use "best practices"?
Is their code clean?
How much time did they take?
After a quick review of the programming test you will gain clarity into the candidate's aptitude vs. ability and find more follow-up questions. The real beauty of this evolution is the capability to identify quickly and up front developers who can't write good code. This can save you a lot of time and effort.
7. Make Them Audition
So you've identified your top pick, his/her portfolio is solid, he/she has the experience and knowledge about the technologies that are important and the phone interview went off without a hitch. Some contend that it's time to have a face-to-face interview but there is another option. Assign them a task and handle it as though they were a consultant. Pay them just as you would a consultant for their work.
The task should be something real--a job that you need done but is perhaps a lower priority. This task should be short, a few days or week at most. The candidate can work remotely or in-house. How this project is handled will let you know whether or not you've got a solid performer and if the person doesn't pan out, you've spent some money but you saved more in the long run.
Yet another option is a probationary period, the employers agrees to hire the person for a specified period of time. When the period is over their performance is reviewed and the decision to keep or let go the candidate is made.
8. Hiring Weekends
Hiring weekends according to Lilly, "require a larger commitment from the company but offers a higher closing rate." This approach works best when a company is trying to hire for several positions at once. The company is responsible for several items including, flights, transportation, conference halls, entertainment, food and drinks. As you can see, it can be an expensive outing. That said, Lilly points out that there is a, "60-75% closing rate", making it worth the investment. He goes on to state, he "feels like less mistakes are made", using this approach.
Prior to the hiring weekend candidates are screened and participate in two phone meetings/interviews. The event normally involves either five -10 candidates or 10-plus employees. On Sunday as the candidates leave, management decides who they will hire and offers are made on Monday or Tuesday. "Any delay in the offer allows the candidate to create doubt in his or head and makes the close harder," Lilly says. Lilly adds that these types of functions are normally held in one location to reduce liability.
The weekend event is outlined below:
Candidates arrive and drinks are served in the hotel bar. Candidates are greeted as they arrive.
Breakfast (interact with candidates), company presentations (get a common story to the candidates), lunch (shift and make sure employees and candidates are talking with each other; candidates will tend to congregate together).
Includes technical interviews. They should be challenging and focused; at least two technical interviews and one business/personality interview must happen.
Saturday after interviews:
Internal meeting (quick recap of interviews); candidates relax before dinner and drinks.
Saturday evening: Dinner and drinks. Employers will work at getting to know the candidates further and ask them questions that arose during the interview portion.
The morning activities include breakfast, benefits, general information, hearing stories from employees on why they joined and getting people out to their flights.
Sunday late morning:
Final feedback with the internal team is held. A yes/no decision is made while interviewers are still there. The recruiters work final conversations/feedback for the candidates and set the expectation that further conversations will happen and they should have an answer by Monday or Tuesday.
Meeting wrap-up with management team following results of the weekend and offers are made to approved candidates.
This evolution can demonstrate a candidate's commitment and his or her ability to gel with your team. Do they buy into your corporate culture? Are they willing to give up an entire weekend? How do they act in social settings? Having the time to get to know and interact with potential hires will also clue you in to what they find important or what they want. Again, the goal here is to gain insight into how these persons act and problem solve in real-time situations.
Finding a Superstar Developer
There are legions of poor-to-average developers out there and they stand between you and your goals. Invest the time necessary to find a great developer and you will be rewarded with simple elegant code that does what you want and projects that finish in the black.
The bottom line here is if you are unsure at all about your developer candidate, don't hire him/her. The cost can be too great and although continuing the search can at times seem painful, it will all be worthwhile when you find the right programmer.
Steve Jobs summed it up well when he said, "I found that when you get enough "A" players together, when you go through the incredible work to find these "A" players, they really like working with each other. Because most have never had the chance to do that before. And they don't work with "B" and "C" players, so it's self-policing." -Steve Jobs
Get the "A" players on your team and develop something incredible.
This story, "8 hiring tips for identifying superstar developers" was originally published by CIO.