19 Tips for Recruiting Great Developers

1. The big job boards like Monster and Dice have become practically useless for hiring top tier talent.

It is easy to quickly obtain a pile of resumes using these services. However, this approach will have you shucking a heck of a lot of oysters to find a truly great Perl programmer. Several professional recruiters I know have given up on these boards except for staffing entry level positions like help-desk and phone support jobs. The odds of finding the proverbial rock star programmer on Monster are growing increasingly slim.

2. Niche job boards will get you qualified leads, but not very many of them.

High-end job boards like TheLadders charge a fee to the candidates and are as much a den of recruiters as the mainstream sites.  I find it hard to believe that top-tier talent is likely to pay to be listed on a job board.

Caveat: I have not personally used TheLadders as part of my recruiting efforts, but did briefly have a subscription as a candidate.

The really niche job boards like the one at JoelOnSoftware do a good job at pre-qualifying the candidates through self-selection, but maybe too much so.  I’ve listed a few jobs on this site for opportunities in Austin that generated almost no response. I suspect this is a better tool if you are in a bigger market like NYC or the silicon valley.

Actually Joel’s board does have a compelling strategy to draw higher quality candidates:

  • Trim back recruiter nonsense by forcing the advertiser to disclose in the ad who the candidate would actually be working for.
  • Asking advertisers to post their Joel’s Test score. Candidates who care about this are more likely to be passionate about their craft.

Despite my limited success with it, I’d still recommend the site given that there really is no financial risk.  I can personally attest to Joel’s “If it doesn’t work, you don’t pay” guarantee. We got our money back promptly with no hassle when the listing didn’t net any interview-worthy candidates.

3. Use LinkedIn Strategically

I have it on good authority that LinkedIn is a pretty strong source of candidates who are only passively looking and currently employed, which are generally traits of the better candidates. However, programmers don’t seem to frequent the job board on this site  as much as sales and management types.

That said, I  can’t really vouch for its job board when looking for developers based on my experience. However,  never before have you had such unprecedented access to the innards of another company’s org chart as LinkedIn provides. A few quick searches containing the name of  other companies in your industry will usually reveal developers with relevant experience in your industry.  This site is also used as a stealth way of looking for another job for people who don’t want their employer to catch them on a job board.

I was just NETWORKING, I promise!

4. The best candidates aren’t going to come to you.

There are exceptions to this, but I’m betting that you wouldn’t have read this far if you are recruiting within a company that the best programmers already yearn to work for. This advice is for the rest of us who don’t have the luxury of offering a job that would be a showstopper on a resume or turn heads at RenFest / Comic-Con.

Some managers, especially new ones, whose only experience with recruiting has been as a candidate desperately seeking an audience with a choice company, have the impression that their role as a hiring manager is akin to sitting atop a throne as candidates compete for their favor.  Not exactly.

There is a pool of candidates who are going to come to you, and their names will quickly become familiar because they will apply to every job posting you open even over several years. In most cases, there is a reason that someone else hasn’t snapped up these people and absent evidence to the contrary you probably don’t want to hire them either. If you aren’t willing to be proactive in your search and sometimes take on a more subservient posture when dealing with candidates, you are eventually going to force yourself to choose from this pool.

The top guns may only hit the open job market once in their careers, and from that point forward get subsequent jobs through networking, which brings me to my next point.

5. Networking is as essential for you as it is for the candidate.

Networking as a job-hunting strategy is a no-brainer, right? So what are you doing to make sure you are on the other end of that network for the right candidate?

Your existing team of developers is often a great entry point into a pretty substantial network of developers. Referral bonuses are the tried and true way to enlist employee help with the recruiting process, but often the prospect of working with a favored peer is a more powerful motivator.

Other benefits of this approach include:

  • The person who made the referral will to be invested in the success of the employee and likely will take an active role in bringing the new person up to speed.
  • Barriers to acceptance into the team will be reduced because the new person already has a relationship with at least one person.
  • You are more likely to get a true picture of what you are getting with the candidate without as much puffery as you might get interviewing strangers.

Warning: This doesn’t work so well with the mediocre programmers. The best developers try to hang with people smarter than themselves. Mediocre ones will seek out people to make them feel smarter. Don’t hire the wing-men.

6. Focus your search on finding developers, not job hunters.

Employers are going to hang on to their best people and keep them away from recruiters, recruiting events, and by extension you.

I’m not trying to imply that their bosses are actively prohibiting them from these types of contacts, but rather that they work hard to keep them happy and busy enough to not even try.

Developer conferences and user groups are a great way to contact engaged developers who may not be actively looking for work. They even triage themselves into sessions so you can more readily identify them by their area of expertise.

The best emissary to send to such an event is a development manager or supervisor. HR types are going to scare away the fish by being too sales-y and saying things like “Do you know Sea Pound?” and many programmers tend to be too introverted to make a lot of contacts.

I’ve a friend who recounted a tactic that had worked well at these events for him. He wore a t-shirt to the conference that read: “I’m hiring developers.”

7. Programming competitions

If you need a lot of developers and want them to triage themselves by skill AND aptitude, you might try sponsoring a programming competition. I’ve no personal experience with this approach, but I’ve seen a number of companies try it.

It definitely sounds good, but be careful to understand what you are looking for. These competitions seem to appeal to people who love puzzles, and those are types of programmers can often exhibit a pathology where they like tinkering and optimizing at the expense of getting a good-enough solution out the door.

8. Don’t expect to pay median salaries for top talent.

Often I see companies that claim to hire only the best, but their HR people argue that they should only have to pay the median salary as determined by salary surveys. Try that argument at a jeweler or sports car dealership and let me know how that works out.

How can you charge $200K for that diamond necklace when I can prove that the average piece of jewelry retails for $150?

If you want the top 10% of developers, you should expect to pay at least in the top 25 percentile, and you are only going to get off that cheap if you bring something else to the table like a cool product to work on,   good benefits, private offices, or some other perk.

9. Get the muggles out of the process as early as possible.

If at all possible, don’t force the candidates to endure even a phone interview with a non-technical person. If you can’t avoid it, at least strip out any technical questions from the interview script that the person performing the interview doesn’t understand well enough to talk about competently.

Let HR/Recruiters manage the scheduling, resume screening, benefits discussions, etc. , but don’t give them a phone interview script with technical questions and let them lose on the candidate.

10. Be flexible with your requirements.

If you need a .NET developer, don’t be a stickler for C# or VB.NET. The best programmers can become quickly proficient in just about any language, make sure that the person screening resumes understands what keywords are acceptable substitutes for the ones in the job description.

11. Branding is not just for cattle and marketing.

Branding is the act of creating and maintaining a positive image to grease the skids for selling people on your team or company. It is often confused with advertising, but it is a distinctly different animal. Branding is about managing your reputation and advertising is just one means to that end.

Creating an identity for your team that is attractive to potential recruits not only helps with sourcing candidates, but also adds ballast to your side of salary negotiations.

Brand characteristics that resonate with developers:

  • We have and hire the best developers – Top developers want to work with other top developers.
  • We work on cool products that your friends and family will be familiar with.
  • Our company is a meritocracy that values technical know-how above politics.
  • Our team keeps up with the latest technology and invests in training for developers.

Some techniques for advertising and reinforcing your brand:

  • Sponsoring developer conferences and events
  • Developer Oriented User Groups – Often you can get a plug on the cheap by buying the pizza or contributing a few give-away items like t-shirts or books.
  • Support Open Source Projects under the name of the company.
  • Offer unusual perks that appeal to programmers and then submit a press release about it to local media outlets.

12. Understand your needs and recruit for that.

This seems too obvious to mention, but is probably the easiest mistake to make. Clearly define what you expect the new hire to do every day and hire someone that can do that job every day and enjoy it.

Some guidance in this area:

  • Don’t hire based on interviewing skills unless you need a sales guy.
  • Don’t hire based on management skills unless there is potential for them to lead or manage in the near term.
  • Don’t hire a clone of yourself or your best employee, you already have that. Hire someone that complements what you already have.
  • Hire for what you need NOW, not what you think you will need later.

13. Ignore your instincts during the interview

Your tendency during an interview is to form an opinion quickly at the start. Your mind is wired to preserve its own worldview and will often fight against all evidence to protect that initial judgment.

To remain objective and overcome jumping to conclusions, consciously decide to go harder on the people you like and easier on the ones you don’t. Otherwise you will be inclined to do the opposite and just reinforce a your initial impressions and waste a chance to learn more about the person in front of you.

14. Trust your instincts when making the final hiring decision

Trust your gut whenever you are the slightest bit uneasy.  At my own peril I have several times learned the hard way that losing a good candidate is far preferable to hiring a bad one. For the dozens of people I have hired in my career, there have been a number of people I was sure would be great and turned out to be just so-so, but  I have never hired someone that I was unsure about that turned out to be a great employee.

At each step of the process separate your candidates into two piles:

Yes: From what I know so far, I could hire this person without reservation.

No: Everyone that doesn’t pass the criteria for the yes pile. Includes anyone who is a “Maybe” or a “Yes, but…”

15. Just say no to puzzle problems.

First, see item 7  about the problem with logic puzzles.

Second, these things tend to annoy really good programmers who don’t like make-work or meta problems.

Don’t kid yourself that “you just want to see how they think.” Knowing that someone can come up with a clever way to estimate the number of boat trips required to determine which switch turns off Mt. Fuji is fun conversation, but a waste of everyone’s time.

Alternative approaches to evaluating a candidate:

  • Rough-out an application architecture on the white-board for this scenario.
  • Role-play with them a troubleshooting scenario for a challenging problem you have worked through.
  • Get code samples.
  • Ask them to describe an application they have built and ask probing questions to make sure you understand their level of contribution to that project.

16. Write an interview script and test it on your current team

Write interview scripts (for each job title/level) and keep your notes for each candidate.

Good reasons to use standardized interview script

  • Less room for ad-hoc questions helps you avoid favoritism (see #13).
  • Documentation of  equal treatment of candidates to defend against potential hiring discrimination claims.
  • Easier apples-to-apples comparison of candidates..

Tips for refining your interview script

  • Test it on current employees – Did it draw out the important positive and negative aspects of that employee? Tweak it until it does.
  • Get current employee feedback on the script – Any offensive/insulting questions? Do they think it would help or hurt the perception of the company for the interviewee?
  • Review your interview notes one year after the hire. Were there any surprises? Tweak the script to prevent similar surprises next time.
  • Review your script for and remove questions that require  specialized knowledge that only a current employee would have.

17. Don’t leave people hanging.

If your company’s recruiting process is interminably slow and out of your control, take it upon yourself to call your short-list candidates and frequently re-assure them that things are progressing. The best developers are going to be highly recruited. Don’t assume that just because someone submits a resume that they are somehow locked-in and will be forced to give you first right of refusal.

I’ve heard and been part of stories of companies calling back EIGHT MONTHS after a resume was submitted to ask for an interview. This is crazy. Even if by some miracle that person was still on the market after that long, clearly they have been passed over by just about everyone else in the interim. Why would you even want them after so much time has passed?

18. Recruit former employees

Face it, your top people get recruited heavily and eventually will jump ship to see if the grass is greener, even if it isn’t.

Good employees that have left your team in are a great source of new hires for several reasons:

  • You know what you are getting and so do they.
  • Previous employees can become productive much more quickly.
  • You can recoup some of your previous training investment.

Even if you can’t convince them to come back, the fact that you want them back is an ego boost for them and will often create some goodwill and improve your branding by creating an advocate that works with a lot of other developers who you might be interested in recruiting.

Some preemptive steps to increase your  odds of re-hiring a good employee later:

  • Give them a final chance to give honest feedback about the aspects of the job they didn’t like and communicate your desire to fix those things for the rest of the team.
  • Organize a happy hour and give them a great send-off.
  • Give them a souvenir of their employment to take with them that will remind them of their friends at the job.
  • Keep in touch, and not just when you need something.
  • Call to ask how their new job is going and solicit advice on things they like about the new job that you could try.
  • Continue to make sure they are invited to happy hours to keep the ties with their former co-workers strong.

I have re-hired several employees during my career as a software development manager who have turned out to be some of the best programmers on the team.

19. Mind your karma and don’t make enemies

Don’t be an ass when developers leave the company, whatever the circumstances. It doesn’t matter if you never want to see this person darken your doorstep again. Also, treat every candidate who took the time to apply with respect, even if they were completely unqualified. Word of mouth is a powerful thing and this industry isn’t as big as you might think. Chances are that these people will talk to someone about your company that you one day will want as an employee or customer.

A Manager’s Retrospective on the C# versus VB.NET decision

There is no shortage of discussion or flame wars weighing the relative merits of the various Microsoft .NET programming languages, nor is there an outcry for another opinion on the subject. This article will instead discuss the process of making a sound business decision on a controversial issue without inciting mutiny among the developers. More importantly, I’ll revisit some of the key considerations in that decision through the razor sharp focus of hindsight. It is my hope that my experiences from the trenches will provide guidance to software development managers who have not yet made the jump to .NET, are bootstrapping a new shop, or are considering a switch from another platform.

It’s been just over six years since I managed the transition of my development team to Microsoft’s .NET platform and made the call, for better or worse, to standardize on VB.NET. As a developer myself, I was keenly aware of the how the programming language of a software development shop defines its culture and similarly shapes the professional identity of many programmers. The polemic among developers created a real risk of breaking down the team dynamic through second-guessing and deflated morale regardless of my choice. As is the case with implementing any politically sensitive change, the prudent course of action was to aggressively seek buy-in by actively soliciting input of each team member, remaining visibly objective, and maximizing the transparency of the issues that factored into the final decision. Despite the lack of unanimity requiring over 30% of the team to acquiesce on this hot-button standardization issue, the team dynamic remained strong after my final decision.

The Players

Although the list of languages that are currently supported on the .NET framework is more diverse than most would probably imagine, the options were far more limited back in 2003.

C#.NET: A hybrid of C and Java that attempted to lure defectors from the Java camp to the .NET platform. It also provides an easy transition for C++ refugees who are sick of the annoyances of manual memory management and having 9 incompatible ways to implement a simple string.

J#.NET: Most of the quirks of Java and none of the cross-platform support and about as useful as non-alcoholic beer. Enables developers to pretend they still hate Microsoft, but participate in their market share. Also allows Microsoft to pretend that C# wasn’t a blatant attempt to crush the upstart Java language that threatened to weaken their dominance of the OS market. The technology pundits have moved on to other issues enough for Microsoft to silently drop support for J# from Visual Studio.

VB.NET: The next generation of the popular Visual Basic language, all grown up and fully OOP capable. It is unfortunate that Microsoft didn’t take this opportunity to rename the language to remove the stigma associated with programmers using this language that only resembles its forebears in its verbosity. I assume they kept the name to provide an unambiguous upgrade path for the unwashed masses of VB6 programmers many of which ironically and belligerently dug in their heels and refused to upgrade.

C++.NET: For a while I assumed that I must have been missing something with respect to C++.NET. The juxtaposition of the venerable I’ll-roll-my-own-thank-you-very-much C++ and the don’t-worry-your-pretty-little-head-about-cleaning-up-that-memory .NET framework felt even more awkward than “Java.NET.” I took a course to absolve me of my silly notions, but only managed to reinforce them. C++.NET is neither fish nor fowl. It is like a halfway house for recovering masochist programmers who really want to like automated garbage collection, but want to take it one day at a time. Just one more hit of STL, I promise I’ll quit tomorrow! In one of the rare parallels with the VB camp, many of the Microsoft Visual C++ developers found little motivation to abandon Visual Studio 6.

The Contenders

Let’s face it. Aside from C#, VB.NET, and their ugly cousin C++.NET, none of the remaining .NET languages were used for much more than  Microsoft demos to prove that they wanted to support open standards. This was even truer back in 2003 when I was weighing the options. The team divided itself naturally into a C# and VB.NET camp and no one even hinted at seriously considering a third option.

The Process

It is extremely important when soliciting input from employees to be very clear about how the final decision is going to be made, especially when it is not the purely democratic process that they might otherwise assume. Recognizing this, I was careful to communicate that while everyone’s input was valued and would be carefully considered, I’d be making the final decision based on both the advice of the team and the interests of the business. I promised complete transparency on my decision and a chance to appeal it on factual, but not subjective grounds. As it happened, no such appeals were proffered. The C# proponents were slightly disappointed, but were also thankfully supportive the decision to go with VB.NET.

My solicitation for input included the following:

  • Provide as many supporting arguments for your preference as apply to our environment.
  • Arguments based on business objectives (reduced cost, greater efficiency) will be weighed more heavily.
  • Performance comparisons between the languages had been researched and dismissed already, don’t bother including them.
  • It is perfectly valid to support your preference in terms of your personal goals (money, prestige, taste, etc.).
  • Regardless of whether you can support your preference, please indicate it in your response. Morale impact is a key consideration.

Facts, Factors and Opinion

After compiling my own research, business case analysis, and the collective wisdom and opinion of my team, the following key themes emerged.

  • Functionality (TIE): Functional differences between the capabilities of these languages were primarily cosmetic/syntactic/irrelevant(Appleman/Atwood), MSDN.  There were a few IDE features that one language or the other had the edge on, but MS was already promising IDE parity in future releases.
  • Learning Curve (VB.NET): Because our previous standard was VBScript for ASP pages, and VB6 for the middle tier object layers, VB.NET seemed like the quickest path to productivity. I was particularly concerned about the impact of forcing the developers to make the jump to a completely different language at the same time they would be also required to get up to speed on the .NET framework and ASP.NET.
  • Existing Code (VB.NET): We were maintaining a significant amount of existing VB6 and VBScript code that would need to be ported to .net. Visual Studio provided tools to automate most of the conversion from to VB.NET, but considerable extra time would have been required to go to C#.
  • Product Road maps for .NET languages (VB.NET): An MSDN magazine article comparing the road maps for the two languages indicated that VB.NET was going to continue to be optimized for rapid application development while C# would follow the tradition of C++ and trend towards power-user features. The direction of VB.NET was more relevant to our development efforts which were mostly on CRUD type applications.
  • Developer Preferences (VB.NET): Despite the tendency of most to gravitate towards the familiar in platform wars, C# had a good showing. The balance was tipped by a few developers who had already started down the VB.NET track of their MCSD certifications. I hate to reinforce the stereotype, but it was interesting to note that the more senior developers were mostly in the C# camp.
  • Developer “Street Creds” (C#): Almost all of the developers subscribed at least weakly to the popular notion that C# experience would command a higher premium than VB.NET by riding the coattails of C++ as a more respected language. Whether justified or not, it appears that this rumor has become fact.
  • Product “Street Creds” (C#): There was also some concern that the “taint of VB” would hurt the perceived professionalism of our software among our customers. I have not yet seen evidence of this, however, we don’t advertise the language we use, and our customers don’t generally ask or care.
  • Recruiting (TIE C#): There was a lot of discussion that MS was strongly favoring C# as the language of choice for .NET and that most developers were following suit. I was somewhat concerned about the possibility of VB.NET becoming marginalized and creating recruiting hurdles. That is, if VB.NET became uncool, it might be difficult to get people to respond to our job postings even if we didn’t discriminate against people with only experience in other .NET languages. On the other hand, I reasoned that we might be able to avoid paying a “C# premium” that didn’t guarantee any associated additional value add over a competent VB.NET programmer. I think that predictions of VB.NET’s demise were very premature as it continues to have a solid following. However, in retrospect, I think I underestimated the impact of the decision on recruiting. I suspect that some of our recruiting difficulty (even with very competitive salaries) can be attributed to the fact that VB.NET developers readily apply to C# jobs, but the reverse is not as common.
  • Language Obsolescence (Non-factor): A small contingent was even predicting that Microsoft planned to phase out VB.NET in favor of C#. I just didn’t buy into this notion given my experience with how slowly Microsoft has retired product lines in the past. It took them 27 years, for example, to retire FoxPro after acquiring it, and salvaging it for parts to include in their competing database package, MS Access. So far it appears my skepticism was warranted.

Recommendations

As I have already mentioned, our team went with VB.NET. I still think it was probably the right decision given the skills of my existing team and our considerable investment in legacy code in VB based languages, despite the minor difficulties it has created for recruiting. Absent either of these preconditions, however, I definitely would suggest a preference for C# for any manager going through this decision today. That said, this article is no substitute for your own research. As is the case with any heated topic, there is an abundance of misinformation, some of which may even be repeated by members of your own team. One resource that I have come to trust over my years in this industry is Dan Appleman, who has published a highly regarded e-book, Visual Basic .NET or C#, Which to Choose? (VS2005 edition).

The lesson that can be drawn from my experience, however, is not so much about a preference of one language over the other, but instead the importance of involving the whole team in the change management process. This decision has major ramifications on their professional careers that extend beyond the walls of your organization and has the potential to create significant anxiety among them. Manage that anxiety by including them in the process, making it clear that their individual interests are being carefully considered, and the making the decision objectively and transparently as possible.

Links to the Fray

Your resume. It’s the little things that hurt. (The Programmer’s Guide to Getting Hired)

A skill that emerges naturally for managers after conducting a relatively small number of recruiting efforts is the ability to recognize common anti-patterns in resumes that are contra-indicators of good developers. I’m not talking about the major faux pas that have been repeatedly covered in generic articles about job hunting, but rather the nuanced messages that are communicated to a technical hiring manager who has learned to  read between the lines. This article is intended as cautionary advice to help prospective developers avoid the most common and damaging mistakes beyond simple typos and grammar considerations.

Risk Level: For senior candidates, most of the mistakes described below are fatal to your candidacy. For more entry level technical positions I am more likely to let these types of issues slide, but do use them to differentiate candidates that are otherwise equally qualified, so it still makes sense to be mindful of them.

 

Tip #1: Don’t be hyper-specific

One of the most effective ways to portray yourself as a novice or one-trick-pony is to pile on the trivial details when describing past jobs or projects. I understand that you are proud of your accomplishments, and know how easy it is to get wordy when drafting the Book of Moi, but remember that a resume is a brochure, not a biography. The prime objective of a resume is to get you booked for an interview, not to close the sale. The interview is a much better forum to brag about the implementation specifics of the “Monolith 3.0 Infrastructure Upgrade Project” because it allows you to adjust the message as you deliver it to hone in on whatever aspects resonate with the interviewer.

The key problem with being too specific arises from the undesirable subtext it creates. I think this is demonstrated well in the following excerpt from a real resume submitted for a Web developer job that I was trying to fill.

“Created stored procedures to fetch query results from the database for higher performance. Involved in writing complex SQL queries that required data from multiple tables using inner and outer joins.”

Gems of this type are hardly rare. I see variants of this exact statement so often in developer resumes that I can now spot them as quickly as if they were marked with a yellow highlighter pen. My mind automatically drifts to the same questions every time I see something like this…

Question 1:  Why is this person making such a big deal about menial tasks like writing a stored procedure and using specific join types?
Option A: They find writing SQL/Stored Procs very difficult and consider it a major accomplishment to have done so.
Option B: They didn’t have much to talk about in the resume and are padding it with trivialities to seem more qualified.
Option C: They just learned about joins and are proud of that accomplishment.

Question 2:  Why call out that they wrote the procedure specifically to query data?
Option A: Maybe they have never written a query that modifies data, are they that inexperienced?
Option B: Are they trying to educate me about what a stored procedure is? Do they think this isn’t common knowledge? Perhaps it isn’t to them.

Another example from the same resume:

“Designed online store by using ASP.Net. This system allowed user to order the products from the store and user can accept the order or cancel the order. “

Question 3: Did this person do substantial work on the project or just write the code for the “Accept” and “Cancel” buttons?

My advice to the author of this resume would be to take Vince Lombardi’s advice and “Act like you’ve been there before.” By assuming the details, it conveys a tone that the candidate considers the specifics of optimizing queries as routine and not worth bragging about. The discussion about the specifics of the clever optimization technique are best saved for the interview. Here is a reworked version that generalizes the same sentiment without dwelling on the trivia.

“Substantially improved performance of company’s core accounting package by profiling and optimizing database access code.”

Another major problem with getting too far into the weeds on a resume is that it implies that the resume is a comprehensive. By being asymmetrically specific about experience with various technologies, it has the effect of implying that the applicant is less competent in skills that are described more generally and not skilled in those that are not explicitly mentioned. In the above example, by specifically calling out experience with SELECT queries, it leads the reader to the conclude that the candidate might not be able to form other types of queries.Be mindful that what you do say often speaks volumes about what you don’t.

Tip #2: Don’t egregiously add keywords in the narrative sections

It could be argued that being specific in a resume gives you an opportunity to get all the buzzwords in, and this is true. The gatekeepers to most jobs are recruiters and HR people who use keywords from the job requisition to locate candiates on sites like monster.com and internal recruiting databases often without understanding their meaning. For this reason, I like the idea of separating out the keywords in to a separate “skills” section on the resume. This makes it easy for recruiters to scan your list of competencies by grouping them together, and makes the narrative parts easier to read for the hiring manager who doesn’t need to be prejudiced by that level of detail.

Here are a couple of examples from resumes that work a little too hard to jam keywords into the job history.

“Debugged and fixed the bugs which reported in TestTrack Pro by Seapine Software, Inc. according to SDLC.”

“Designed the database in SQL Server using database normal forms to prevent data redundancy and ER (Entity Relationship) diagrams.”

Although it is amusing, I’ll forgo a discussion on whether using normal forms actually “prevent ER diagrams.” If only…

The Code Sample (The Programmer’s Guide to Getting Hired)

Why you are being asked for a code sample and what it says about the employer.

At some point during the developer recruiting process, any hiring manager with the remotest concept of due diligence is going to attempt to get a preview of what to expect from the applicant either by requesting a code sample or asking them to write some code during an interview. In furtherance of my ambition to minimize my resemblance to a jackass and to do my part to optimize useless effort out of the universe, I tend to forestall asking for code samples until I have arrived at the short-list of candidates that I would seriously considering hiring. Unless I have more than five or six really solid candidates (very rare), I’ll generally ask for the code sample at the end of the phone interview if it has gone well, and ask the candidate to e-mail it or bring it with them to the in-person interview.

Although management styles differ, I think it is a safe bet that a code sample request is a strong indicator that you are progressing well through the recruitment process and so far have made a favorable impression. I base this on the assertion that few managers are going to be willing to wade through dozens of code samples from marginal candidates in hopes of finding a diamond in the rough unless they are having a really hard time finding candidates because they have a lot of positions to fill quickly or need someone competent in a niche technology.

It’s a good thing, I promise!

I definitely understand that competency tests like this during the recruiting process are stress inducing for the candidate, but take heart that a request for a code sample can be a very positive sign for the candidate. Not only is it a sign of interest, but it also shows that the company is the type of place that carefully vets their technical people. Believe me, you do not want to work somewhere with lax recruiting standards. There are a number of reasons that companies hire without scrutinizing candidates thoroughly and almost all of them are bad news the person who ultimately gets the job.

  • They have a backlog on recruiting due to high turnover as they desperately try to replace people who are running out the door.
  • Lazy hiring managers who would rather over-hire and then weed people out on the job.
  • Supervisors that don’t understand technology and are afraid to ask questions because they wouldn’t be able to interpret the answers.
  • Lots of under qualified co-workers who are a continuing source of bad code that you’ll have to debug, and no mentors in sight.

Dissenting opinions and my rebuttal

If you have spent any time in message forums that focus on job-hunting for techies, you have no doubt come across a certain vociferous element that despises employers who request code samples and/or certain types of interview questions. While I empathize on the abuse of puzzle questions, extremely obscure technical questions, and extreme pressure interviewing techniques; the arrogance exhibited by some of these people frankly amazes me. In a separate article I discuss to the type of candidate that thinks “I’d just Google it.” is an acceptable answer to any technical interview question, but for now I’ll to address the fallacy of arguments like the following:

“Can you believe they asked me for a code sample? I have 10 years of development experience on my resume and four certifications. I’ve earned my stripes and shouldn’t need to prove myself to anyone. They are probably just trying to trick me into doing work for free. I’m not a monkey who is going to dance for their amusement!”

Unless this guy is Bjarne Strousup, John Carmack, or some other luminary of technology, he is wrong. Professional programming is the type of gig that has very few celebrities. If I could identify the most skilled programmer alive today, chances are that you wouldn’t recognize him or her. Even for those few programmers that you might recognize either their name or work, it will often be only because of the high profile projects they worked on and not necessarily their code-fu. The simple truth is this, most programmers are anonymous, even the really good ones. Before you start commiserating with complainers such as the one in my example, be sure to read some of his other posts about how there are simply no jobs out there evidenced by the fact that, despite his obvious skill, he has been out of work for 8 months already. Recruiters can spot attitude problems like this a mile away and know enough to put a second mile between themselves and these head-cases for good measure.

The bottom line is that you shouldn’t take efforts to validate your qualifications personally. Hiring managers have just learned through hard experience that they can’t blindly trust anything on a resume. There are simply too many people applying for jobs with puffed up resumes full of certifications yet they couldn’t code their way out of class PaperBag:Bag. It’s just the process, not an impeachment of your abilities. If you are still not convinced, consider what you would assume about a supposed “rock star programmer” who was so hesitant to show off his code. It smells fishy, and managers don’t want fishy when making decisions that will cost 5-6 figures per year plus benefits.

Code sample requests encourage “failing-early” in the recruiting process

Before I even look at the code sample provided by a candidate, I have effectively screened out three types of undesirable candidates that won’t submit the requested sample.

  1. The angry egoist described above.
  2. The resume padding exaggerator with no programming skill who has just realized that I have called their bluff.
  3. The tire kicker, who isn’t really interested in the position, but is applying on the off-chance that I might be able to give them a $50K salary bump.

The hidden agenda

The request for a code sample has a side benefit, in that it lets me test something beyond programming skill without being completely overt about it. In many cases I’ll add some special requirements on the code sample request, for example specific languages, length limitations, or submission instructions. This is an excellent way to detect candidates who refuse to follow directions or jump into solving problems before attempting to understand the requirements. Closely reading the instructions presented by a prospective employer, asking relevant questions as needed, and re-checking against those instructions before submitting will get you further than at least 25% of the candidates that make it to this stage.

 

No excuses – give up the sample

There are a number of reasons people give for providing a code sample. In my opinion, none of them are acceptable. I’ll address the two most common here.

“All my work related code is proprietary. I can’t betray my current/former employer’s trust by showing it to you.”
Good for you. I definitely respect your dedication towards protecting your employer’s intellectual property. In fact, it would probably color my opinion negatively of you as a candidate if you submitted a code sample that looked like it might contain trade secrets. However, that doesn’t get you off the hook. Many candidates mistakenly presume an implicit requirement that the code sample must come from your professional work experience. Unless you were specifically told this, this assumption is usually not valid. Whether it is fair or not, I interpret these responses as “I can’t send you any of my existing code, and I’m not interested in the job enough to bother writing anything new.” Do I really want to hire someone with the attitude, “I have to write code? Bummer!”

“I am a student and only have code from academic work.”
Again, I don’t care why you wrote it as long as it is your own work and it meets any requirements I specify.

 

Even if you do have some previous professional work that you are not restricted from sharing, I’d strongly advise you to take the time to write something fresh to use while you are interviewing for a programming job for a number of reasons:

  • Your coding skills should be improving over time, thus your newest code should be the best you have ever written.
  • The code you have already written was probably created under constraints that won’t be apparent to the hiring manager. You don’t want to submit code that requires an explanation or apology.
  • In most cases, you are free to write code to do whatever you want for the sample. You rarely get a chance to choose a problem that you are good at solving, take advantage of it.
  • Your existing code was written to solve a work problem not sell your skills. Different objectives require different approaches.
  • You have a chance to write code that matches the technologies/tasks that match the job description.

That last point is important and applies to other areas of the recruiting process. Anything makes you seem more familiar to them will help your chances because it encourages them to start thinking of you as an insider. Unfortunately, I also think this tendency is also the source of a lot of unintentional and illegal discrimination during the hiring process, but good managers have learned to recognize their own natural biases and find ways to remain objective about candidates.

Code sample ideas

For the truly stumped, here are a few ideas for programming tasks that can be solved in just about the right amount of code that works for a code sample, yet aren’t so trivial that they undermine your credibility.

  • A utility class for logging events and errors either to a file or the system event logs with a configurable level of verbosity.
  • A set of stored procedures for maintaining and searching data in a hierarchical tree structure.
  • An implementation of the singleton design pattern to serialize access to a resource file.
  • A calculator function that takes a single string of input that includes numbers and operators and returns the numeric result of the equation. Don’t forget input validation, error handling (divide by zero), and operator precedence concerns!
  • A method that takes a URL to a web site and a local path and downloads all image files based on <IMG> tags.
  • Create a method that takes a keyword, message, and login credentials and uses the Twitter API to respond to post the message as response to any friends of the account specified.

 

Best practices for preparing a code sample

A request for a code sample is like a take home exam, and there is no excuse to not ace it. Although code samples are more frequently used to identify potential problems than recognize programming skill, there is still some opportunity to score points with your submission. Making sure the code is highly readable is one of the best things you can do to improve your standing through the code sample. Although some of these items should not be considered a best practice for actual programming work and many of them are not even practical when you don’t have total control of the problem you are trying to solve, they are great ways to increase the readability of code sample submissions:

  • Separate logical blocks of the code with extra blank line. Whitespace is your friend.
  • Avoid line-wrapping as much as possible.
  • Method and variable names need to be meaningful at face value without reading the code that calls or implements it.
  • Reduce the number of parameters to functions you write, and avoid passing in optional parameters as much as possible.
  • Variables should be single use only.

Before
Dim loopCounter as integer
For loopCounter = 1 to maxPages
‘do something with pages
Next

For loopCounter = 1 to maxDucks
    ‘do something with ducks
Next

After
Dim PageCounter as integer
For PageCounter = 1 to maxPages
    ‘do something with pages
Next

Dim DuckCounter as integer
For DuckCounter = 1 to maxDucks
    ‘do something with ducks
Next

  • Use variables instead of inline function calls

Before
fooResult = foo(subfoo());

After
subFooResult=subfoo();
fooResult = foo(subFooResult);

  • Put in at least a few comments to show that you know that you are supposed to. However, follow best practices and don’t overdo it.
  • Show the code to another programmer and ask them to tell you what it does and how as quickly as they can. If you get even the slightest urge to explain while they are reading or they ask questions, rework it to make it self explanatory.

Don’t forget the quality control

You did have five of your best friends QC your resume and cover letter before you submitted it, right? Isn’t the code sample worth the same scrutiny? Understand that the code sample is used more often as a NEGATIVE differentiator than a positive one. In case you don’t speak marketing, this means that the person reading your code sample is using it to weed out bad candidates not find good ones. Here are some suggestions to keep your resume out of the trash-bin:

  • Compile the code – It is just plain lazy to give them code with mistakes that are so easily caught.
  • Spell check your comments and identifier names – Yes it is silly, but don’t give them chances to take cheap shots at you.
  • Unit test the code thoroughly to make absolutely sure it does what it is supposed to. If the job posting lists TDD you might even consider submitting the unit tests for extra credit, but be sure to confirm before doing this if it forces you over the code size they asked for.
  • Check for and eliminate any code that is borrowed or even looks like it might be. Hiring managers sometimes Google unusual identifiers and method names to make sure exact matches don’t come up for your code. You might want to do this too to see what comes up.
  • Find the smartest programmer(s) you know and ask them to tell you 5 problems, no matter how nitpicky. This prevents them from trying to be polite or lazy and not looking too closely. Getting the job is more important here than protecting your ego.

Other tips on preparing a code sample

 

  • Keep it short and simple. They are looking for ammo to filter you out. Don’t give them a lot of code to find fault in.
  • Don’t use clever coding tricks. They decrease readability and rarely impress anyone.
  • Use the code sample to demonstrate your knowledge of technique (Design patterns, generics, OOP, TDD) and specific technologies (AJAX, Web Services, XSLT, SQL DMO). Use the job description for cues for what things you might want to include.
  • Avoid controversial approaches such as Hungarian notation whenever possible. You don’t want to be forced into a confrontational posture with a zealot from a different camp that has pull on whether you get the job.
  • Don’t use comments to plead your case or apologize to the hiring manager as shown in the following counter-examples:
    /* I am really good with OOP as shown in this class! */
    /* Normally I would add error handling here if this were production code, but since I’m not taking this seriously… */

Your code sample and the interview

Even if you get a callback for an in-person interview after submitting your code sample, don’t rest on your laurels yet. For managers that work with a system similar to my own, there isn’t usually a round of cuts between receiving the code sample and the formal interview. Usually I just briefly scan the code sample for obvious deal-killers and don’t really read them carefully until the day of the interview so the candidate has a chance to defend it, if necessary. You can and should expect the code sample to be a topic during the interview, so be prepared.

Know thy code: You should know the code you submitted backwards and forwards, have some ideas about other approaches you could have taken, be ready to optimize it, and talk intelligently about all of the technologies you used. The code sample is fodder for under-prepared interviewers who are digging for something to ask about. “Interesting, you used the Fizbah protocol here. Would that work over IP too?”

Defend thy code: A lot of interviewers like to use a technique that involves contradicting the candidate in some way, such as questioning the approach in a code sample. You absolutely must defend your approach unless the interviewer has pointed out an indisputably better or more correct approach. Do not concede the point unless you understand the counterpoint thoroughly. A common trap is for an interviewer to play devil’s advocate just to see if you will fold under pressure. For example you are sunk if you bite when the interviewer makes a claim he knows is false, like “You shouldn’t have used the StringBuilder class here, it doesn’t work with Unicode.”

…but not dogmatically: When defending your code, however, you have to be careful to not give the impression that you are closed-minded or that you think you know everything. For example, if you got the StringBuilder/Unicode question and weren’t sure if the interviewer had a good point, you might say something like “Are you sure about that? I am pretty sure that isn’t the case, but it is a very valid concern. I’ll double check the documentation and follow-up with you in an e-mail later this afternoon.” This answer helps dissuade the notion that you might be a pushover, shows that you care enough in your craft to dig a little deeper, and that you are the type who likes to share knowledge of new discoveries.

…, and show that you know how to listen: When an interviewer criticizes a code sample or an answer to a technical question, many candidates turn off their ears as soon as they get detect a negative tone and start to cogitate on their rebuttal. Unfortunately this often causes them to completely miss the subtle clues that interviewers drop to help the candidate navigate the objection. It is critical that you practice active listening skills during an interview for this very reason. It looks bad when you make mistakes in an interview, but it is far worse to continue to flounder on a technical issue when the interviewer has thrown you a lifeline and you didn’t recognize it.

Follow

Get every new post delivered to your Inbox.

Join 133 other followers