5 Dos and Don'ts of Hiring a Developer

Developers are the unicorns of the modern labor economy.

Their ethereal talents often bewilder the most seasoned of marketing professionals.  As they navigate multiple screens of what appear to be a sea of foreign numbers and strange hieroglyphs, many of us may develop feelings of awe as our technical colleagues concoct complex digital systems and design beautiful user experiences, all through the magic of their keyboard.

Increasingly, agencies are being called upon to challenge the status quo for digital customer experiences and as a result, are relying on the acquisition of better and better technical talent.

Some nail it. Others fail so miserably that the costs associated with poor hiring choices can be enough to derail an entire project (or even agency).

We’ve compiled a list of some of the big do’s and don’ts of hiring a developer for your next project.

DO: Consult somebody on your actual position requirements

First and foremost, if you’re inexperienced in hiring technical talent, it helps to go and find somebody who is experienced to nut out the position description. Often, what we think are the requirements are not what they seem and talking to another developer or technical recruiter can help distinguish whether or not you’re making any unfounded assumptions about the role, overcomplicating the PD or even oversimplifying it. Getting a clear understanding of questions like:

• What language skillset/s is required?
• What level of seniority is required (i.e. junior, mid, senior developer)?
• What development methodology will be used (if working with teams)? 

…and many other questions will help ensure you’re pre-qualifying your applicants (and not scare off the good ones through ambiguous expectations either!)

DO: Understand the scope of the job/task before you promote the position

Developers, particularly front-end developers, are in high demand, so generating interest from the crème de la crème is no easy feat. Attracting top technical talent requires a strong mix of well-defined and flexible expectations:

• Is the contract freelance or permanent?
• Are the hours flexible? 
• Can developers work remotely or do they have to be onsite? Can a mix be facilitated?
• Is the developer expected to work as a soloist or in a team of other developers?

DON’T: Pretend you know what you’re talking about.

One of your fabulous abilities as an agency exec is convincing clients or consumers that the agency itself or the products and services we sell are worth investing in, even if it means ethically blurring the edges of what our competencies truly are. 

Whatever you do: don’t try and overuse this charm with a developer. Pretending to understand the nature of the developer’s work, if you don’t, is a recipe for a disaster for several reasons:

• It blinds you from whether or not the developer him/herself is actually as competent as they say they are.
• It sets up a destructive working relationship. There’s nothing more cringe-worthy than when an agency executive attempts to tell a developer how to do their work. It’s a surefire way to generate disengagement from your team, and will make you come across as ignorant to not only the developer, but also your colleagues.

DO: Mitigate your risk

It doesn’t matter how technical you are. You can be the most experienced technical hirer in the world and still not be 100% sure you’re making the right hiring decision. Therefore, it helps to set up a series of risk mitigation strategies to ensure that you’re continually qualifying the candidate at every stop of the hiring process. Below are some of our suggestions:

Set up an objective vetting process

Use a third party, whether it’s another developer, a recruiter or even a qualified client to help vet certain candidates who send through their CV or portfolio. It helps to have somebody validate or dispute your own opinions before you commit to bringing a candidate in or not

Create a test project.

Put the candidate through a test that best encapsulates the skills described in the original position description. This tends to get most developers, since most people (not just developers) overestimate their capabilities or exaggerate them in interviews.

Backup everything

Protect yourself against the absolute worst downside. Save whatever existing data you have by backing up all databases or source code and by remembering to ‘commit’ any project changes to Git (see What is Git article) before a new developer digs under the hood of your source code.

DON’T: Cheap out

There’s an image that tends to circulate the feeds of LinkedIn every now and again that highlights three opposing ideas: Quality, Price, and Efficiency (or Speed). The idea is with any given task or project, a decision maker can realistically only invest in two of the three: 

• If you want Price and Quality, a task may take longer.
• If you want Quality and Efficiency, you will pay more in price.
• If you want Efficiency and Price, you will lose quality.

This theory is especially true with hiring developers. No two developers are made equal and good developers are as rare as unicorns. 

Do yourself a favor. If you find an exceptional developer who will work well with your existing team, pay them what they’re worth. The cheaper solutions will inevitably cost you more.
These are just some of our dos and don’ts for hiring a developer, but we hope these five have helped you better clarify your next steps. Ultimately, it all comes down to one thing; respect the developer by respecting their craft. 

Interested in a career with Core dna? Shoot us an expression of interest via our careers page.