When I signed on to join the team at Qualified last month, I ran the company through the diligence process that I use to assess opportunities at technology start-ups. Great product? Check. Strong growth trajectory? Check. Awesome customers? Check. A team I’m excited to be a part of? Check.

But beyond this list of important criteria my decision came down to a feeling that I couldn’t shake-one that my intuition told me was worth listening to above all else.

In 10 years of working with high growth technology start-ups, I’ve never come across a company that’s too good at hiring software developers. Everybody struggles with finding great software engineers.

I’ve sat in countless board meetings, leadership off-sites, and all-hands gathering where the story is largely the same-”We had 10+ open job reqs for development positions at the beginning of the year. We’ve filled three. One hire didn’t work out.” Queue the thumb-twiddling and downward glances.

Expensive employee referral programs ensue. Contracted recruiters come in to help. But all the subsequent efforts aside the common denominator is clear-there’s a shortage of software engineering talent and companies need to find better ways to identify, attract, and retain developers.

When I looked at the opportunity at Qualified the marketer in me saw a very real pain point and a market opportunity worth attacking; followed shortly thereafter by a lot of controversy surrounding the tools that are available to help companies assess software engineers.

Any Google search or discussion with software engineers about the developer hiring process quickly surfaces a myriad of opinions on how coding skills tests are used in the recruiting process. You’ll find lengthy debates on this topic in HackerNews threads as well as not-so-subtle articles with titles like Why Coding Tests Are A Bad Interview Technique.

At first blush these sentiments should have deterred me from joining a company that makes a developer assessment platform, right? But I saw that the market for these products is exploding and I decided to dig in-a process that began by asking my former boss Dimitris Georgakopulous, Co-founder of Buildium and Outseta, for his take on coding skills tests.

“There’s absolutely a market and need for tools like this,” Dimitris said. “You simply can’t assess and hire developers without asking them to write some actual code.”

Joel Spolsky, CEO of Stack Overflow and Co-founder of Trello, provided further backing of this perspective with a simple analogy.

“Would you hire a magician without asking them to show you some magic tricks? Of course not. Would you hire a caterer for your wedding without tasting their food? I doubt it. Do whatever you want during interviews, but make the candidate write some code,” writes Spolsky.

Encouraged by this feedback, I turned the question on the development team at Qualified. “Why do so many developers dislike coding skills tests?” Their answers surprised (and built credibility with) me.

“I’ve heard the complaint that interview tests are awful, pointless, and demeaning a lot- especially on social media,” said Phil DeJarnett, a Senior Front-End Developer at Qualified. “It’s frustrating at best because it’s clear that developers are looking at it from an (understandably) selfish perspective. ‘ I’m a good developer, why do I have to prove this to someone I don’t even know?’”

Jake Hoffner, Qualified’s Co-founder and CTO, took it one step further.

“As a senior developer I’d be hesitant to take most coding assessments if I was looking for a new job,” Hoffner says. “I feel like I’ve built products and have a professional network that should preclude me from needing to do that.”

Prior to Co-founding Qualified Jake built Codewars—he’s definitely a person that I’d describe as a “developer’s developer.” But coming from a guy that’s now spending his professional life building a developer assessment platform, I was taken aback by hearing this level of empathy for the anti-coding tests sentiment.

“What’s this guy doing building a developer assessment platform then?” I wondered to myself.

I’ve spent the last few weeks talking to HR and engineering leaders to dig into this question in the greatest amount of depth possible. I’ve since resurfaced with strong conviction and evidence that there are companies using coding skills assessments in not only a developer friendly manner, but also in a way that directly leads to them finding and hiring the type of developers that immediately begin delivering on-the-job.

In fact, if wielded properly coding skills assessments can even help companies build credibility and excitement with developers throughout the hiring process. This is yet another aspect of your employer brand that can be optimized-and perhaps the one that speaks most directly to what it’s like to work on your company’s engineering team.

Shane Sown, a Talent Acquisition expert who has built engineering teams at companies like Facebook and Zillow, says it best.

“When a candidate does run into an interview that represents real-world problems that would need to be solved in the day-to-day of the actual position it’s MIND-BLOWING. I have had candidates leave an interview with a coding assignment that they were actually excited to complete, because they felt like they would understand the company’s problem and add real value.”

This post will teach you how you can move beyond the negative sentiments and turn your company’s use of coding assessments into a strategic advantage. But let’s start by reviewing some of the reasons developers dislike coding assessments in the first place.

While developers have expressed disdain for coding assessments for a wide variety of reasons, almost all of them can be overcome. These sentiments almost always come from coding skills tests being used as a blunt instrument to pre-screen developer candidates out of the recruiting funnel. Here’s how your company can intelligently apply coding assessments to flip the script and turn hiring developers into a competitive advantage.

Most coding assessments test only algorithmic skills

The most common-and credible-reason that coding skills tests get a bad rap is that the vast majority of assessments test algorithmic skills rather than actual programming ability. The tests represent a computer science problem that has little to do with assessing an engineer’s ability to deliver the work they’d actually find themselves doing on a day-to-day basis.

Glen McCallum, a Senior Software Engineer at INscribe Digital, draws a wonderful analogy between coding and music in his article Why Code Challenges Are Bad Practice For Hiring Senior Developers published just last week. Testing algorithmic skills is a technical exercise akin to learning to play scales in music. While playing scales is important when you’re learning music, it has almost nothing to do with working as a jazz musician.

“This week I was working on a Hackerrank problem for fun,” writes McCallum. “I had to pull out my old text book for data structures and algorithms in order to code up a merge sort from scratch. I felt inadequate, sent a tweet, and then a light bulb turned on in my head.”

“We all studied these algorithms in undergraduate computer science classes. But as you gain a lot of professional experience you learn how and when to apply them, then you refresh your memory as needed. I knew exactly what merge sort was for and I knew exactly where to find the reference algorithm. I just didn’t have the details in my head at that moment.”

McCallum continues building his point by returning to his music analogy.

“Does it make you a better professional musician if you can play all scales perfectly at any time? Absolutely not! In fact I’d argue that you’re wasting precious practice time. How silly would it be if you asked a professional musician with a history of outstanding performances to sit down at an audition and play a scale? It’s insulting. Then dismiss them before they even perform because they didn’t do the scale perfectly. The thought makes me sick to my stomach. But in 2019 it happens every day to senior developers applying for jobs.”

Luckily, there are developers out there who have been heavily involved in the hiring process that also understand the objectives of their friends in HR and the importance of pre-screening candidates.

“There’s enough programmers in the world who aren’t really skilled enough for the job (whatever that job may be) that it becomes necessary to offer some kind of litmus test that a potential job-seeker must pass,” writes Ted Neward, a Guest Lecturer on development at the University of Washington’s iSchool. “I get that and it’s not like all the programming tests in the world are created equal. But the ones where the challenge is to implement some algorithmic doodad or other? Shudder.”

How to address the “coding assessments test only algorithmic skills” challenge Most coding assessments are built as generic STDIN/STDOUT tests. Instead of leveraging these tools, look for coding assessments based on unit tests-developers write unit tests on a daily basis. Also look for assessments that use language specific frameworks-preferably the same languages that candidates would be writing code in if hired at your company. Testing for the nuances of each specific language helps to better surface candidates who will deliver clean code on-the-job.

Coding skills tests are time consuming

Another reason that coding skills assessments are often bad mouthed is simply because they can be time consuming to complete.

“My biggest pet peeve with these types of tests is this: there are a lot of companies out there, and I’m sending out resumes to each one that I can find,” says Brandon Savage, Owner at Tailwinds. “I simply do not have the time to write fifteen code samples a day, just because you want to evaluate me against your coding test. Period.”

How to address the “coding tests are too time consuming” challenge While Savage has a point, this objection is far easier to overcome. From the perspective of the hiring company, all it takes is a little self-awareness and empathy for the applicant-make it a point to be mindful and respectful of each applicants’ time.

I asked Jake Hoffner, Qualified’s CTO, what he’d recommend with this challenge in mind. His answer was simple-for a first cut at a technical screening exercise, share an assessment that should take no longer than an hour to complete and ideally only 20–30 minutes. For a final stage technical assessment, limit the time commitment of the candidate to two hours.

“Even if they don’t complete the assessment in two hours ask them to stop at that point,” says Hoffner. “You’ll learn a lot from what they were able to accomplish in two hours, and you’ll learn even more from talking to them about where they’re at two hours in and what they’d do next anyways.”

From the perspective of the applicant, I’d also push back on Savage’s sentiment-if you find yourself needing to write 15 code samples, you need to reassess your job search strategy. This is indicative of a spray-and-pray strategy where you’re firing off a large volume of resumes (and are subsequently asked to take a high number of coding tests).

Regardless of the position you’re applying for, focus instead on applying for a smaller number of positions that you’re most interested in. This way you can devote significantly more time to each, which almost always yields a higher number of job offers.

Coding tests don’t reflect the real world programming experience

The focus on algorithmic skills aside, software engineers often cite that coding tests don’t reflect the actual experience of writing code as you would on-the-job. For example, many coding tests require developers to build something from scratch.

While starting from a blank slate is easy, it’s rare that developers would do this very often once hired-more often than not the real world, on-the-job experience would instead dictate that you familiarize yourself with an existing code base and learn to contribute to it effectively.

How to address the “coding tests don’t reflect actual programming” challenge There are countless generic coding tests out there because they are easy to create. Instead, look for coding assessment tools that give you access to a database of pre-built assessments in a wide variety of languages, scopes, and challenge types that are as similar to your own code base as possible.

If you’re hiring for more senior roles, look for a coding assessment platform that allows you to create and administer your own custom, multi-file assessments that directly reflect the process of contributing to your actual code base.

Coding assessments take developers out of their comfort zone

Developers often question the validity of coding skills tests because they’re asked to perform in an environment that’s not familiar to them. Understandably, they feel like they’re not able to put their best foot forward.

This complaint is also very legitimate-imagine asking Tiger Woods to play the Masters with somebody else’s golf clubs or asking a violinist to audition by playing the cello. Most developers have an IDE (integrated development environment) that’s been highly customized for their own personal tastes and preferences in a way that’s comfortable, familiar, and allows them to write code as efficiently as possible. How could they possibly perform their best when they’re thrown into an unfamiliar environment that they wouldn’t actually use if hired anyways?

On top of that many coding assessments are either timed or ask developers to perform on-the-spot while others look on-again contrived circumstances that add to a developer’s anxiety.

How to address the “coding tests take developers out of their comfort zone” challenge This one is simple to address-let developers operate within the confines of their comfort zone. Doing so will help you get the best read possible on how they’ll actually contribute on-the-job.

Look for coding assessment tools that allow developers to customize their IDE, or better yet use their own IDE altogether when completing coding assessments. If you do time restrict assessments, allow developers to work independently then use code playbook tools and pair programming sessions to discuss and expand upon the work they’ve already completed. This will give you a deeper level of insight into their thought process and problem solving ability.

Senior developers shouldn’t need to prove themselves

Senior developers are sometimes unwilling to complete coding assessments simply because they feel like they shouldn’t need to prove themselves-they’ve been working for years and have countless products and code samples they can instead highlight to showcase their abilities. You wouldn’t try to sign Lebron James by bringing him in for a workout and asking him shoot free throws for the first hour.

While there’s validity to this point-particularly with the very best engineers-there’s also at least some degree of ego at play here. As someone who has hired a large number of marketers and designers, when I’m confronted with someone who is not willing to deliver a reasonably scoped test project what I’m essentially hearing is, “ I have an ego and I don’t want this job that badly.”

I can tell you with certainty that there’s a lot more risk with a marketer delivering a 90-day growth plan during the interview process than there is with an engineer completing a coding assessment. You’re being asked to share your own, original thinking and there’s nothing to keep the company from taking your own ideas and running with them on their own. There’s inherent risk there and you are being asked to provide value up front.

But if you are unwilling to do this, what does it say to the company that’s looking to hire you? And if you really check your ego at the door and take a look at this from the perspective of the employer, it’s really not too much to ask. For development jobs the employer is likely committing to paying you well over $100,000, to contributing to your 401k, to bringing on a person that they hope will contribute to their product for a long time to come. The employer is almost always taking on more risk than the applicant-particularly in smaller companies.

How to address the “I shouldn’t need to prove myself” challenge Make sure that whatever you are asking of senior developers to do, it’s actually providing some insight on how they’d contribute on-the-job-don’t make them jump through hoops for the sake of jumping through hoops!

If they’re truly a high quality, senior developer you can spend less time assessing their actual programming ability and more time probing on what they’re like to work with and how well they incorporate feedback. Create custom, detailed coding assessments to provide a common structure against which to evaluate senior developers, but purposely limit the amount of time they actually spend on assessments.

Instead use pair programming sessions or code playback to discuss with senior developers some of the architecture decisions they made or how they might expand a feature further. Rather than using coding problems in isolation, use the assessment as a starting point for a much deeper discussion that gives you insight into how candidates think and what it it would be like to work with them.

Automated scoring of code can lead to false rejections

Finally, there’s often skepticism or worry about coding skills tests because automated scoring of code can lead to false negatives-applicants getting rejected that shouldn’t necessarily be. Fair enough-for any coding problem there’s almost never a single “right” answer.

Consider the great works of literature; if assessed against the strict rules of grammar, almost all of them would fail an automated test. James Joyce’s Ulysses, considered one of the great works of English literature, is filled with fragmented sentences, slang, and words that are made up altogether. Joyce himself would fail to get hired at even the local newspaper if they were using an automated language assessment.

How to address the “fear of false rejections” challenge Automated assessments are a prerequisite for hiring developers at any sort of scale and save a company’s internal employees from spending a massive amount of time reviewing code submissions-any developer worth their salt will understand and appreciate this.

What you can do is look for automated assessments that have been informed, validated, and approved by thousands of other developers already through communities like Codewars (which forms the basis for all of Qualified’s assessments). Also look to use a developer assessment platform that provides a full suite of feedback tools beyond automated scoring of assessments-look for pair programming functionality, code playback, and tools to manually provide and capture feedback on specific segments of code.

Developers have voiced many hang-ups with coding skills tests, and many of their criticisms are well founded. But by leveraging the latest technologies in tandem with developer friendly hiring practices, companies can turn their use developer assessment tools into a competitive advantage.

Your company’s use of coding skills assessments represents a very real opportunity to build your employer brand, give candidates a strong initial impression of your engineering team’s culture, and create a hiring process that developers talk about glowingly (and share with their friends).

“How a company interviews people is a direct correlation with the quality of talent they attract,” says Shane Sown.

What does your developer assessment process say about your company?

Originally published at https://www.qualified.io.

Why Some Developers Hate Coding Skills Tests (And What Hiring Managers Can Do To Change That) was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

We ran the numbers, and the cost of landing a new developer will set a company back roughly $22,750 — the expense associated with the time it takes to review resumes, conduct phone/tech screenings, and perform in-person interviews. It’s no small sum, but worth every penny to add a productive and innovative team member who can help an organization reach its goals. But when a new developer doesn’t work out, the cost of this mis-hire to a company’s bottom line, team morale, and future outlook can be staggering.

A Six-Figure Mistake

Estimates vary on how long it takes for a new hire to reach full productivity, with figures ranging from 29 weeks to 8 months to a full year. For the sake of this exercise, let’s imagine it takes 6 months for a new developer at your organization to reach optimal productivity. If everything goes as intended, the hire will show an output multiplier somewhere between 1.875 and 2.5. That is to say, a new developer making $80k a year will return $150K to $200K in profitable output to the company to cover all-in business costs and help turn a profit.

The most readily apparent evidence of a bad hire is someone whose output multiplier isn’t helping in achieving profitability, or worse, doesn’t even cover their own salary. So at 6 months, an $80K developer with an output multiplier of only 1 would run the company roughly $40k in salary alone, plus $75K at the low end of missed/unrealized profitable output. Add that to the $22,750 expense of recruitment, and in just half a year a developer mis-hire winds up costing a company about $138,750 — but that’s not all.

The Incalculable Ripple Effect

Replacing an underperforming developer can be a laborious and challenging affair for HR, management, and engineering departments. From a monetary standpoint, budgets will have to contend with a severance package, possible legal fees, and the cost of having to conduct another months-long round of recruiting to fill the newly vacated position.

Then there are the incalculable, but no less important, costs related to the effects of bad and fired employees on overall office morale. The negative disruption to the workplace reduces the productivity of other team members, leading to lower output which can impede enterprises from reaching its crucial milestones. When viewing an organization’s 2–5 year outlook, the ripple effect of a developer mis-hire can force stakeholders to shift timelines and redefine success.

Reversing the Damage

The good news is that the negative effect of a bad hire can be undone by filling the position with a brilliant developer whose incredible output can help recoup lost time and money, putting an enterprise back on track to achieving its goals. Facebook CEO Mark Zuckerberg is quoted in the New York Times, saying, “Someone who is exceptional in their role is not just a little better than someone who is pretty good. They are 100 times better.” The sentiment demonstrates the value top talent brings to a team, and reveals how the derailment caused by a mis-hire can be reversed by a genius developer whose profitable output multiplier is at the high end of the range. Qualifed’s online platform leverages code assessments and pair-programming interviews to streamline the candidate process and help identify brilliant developers. Send us a message to request a free trial.

The High Cost of Developer Mis-Hire was originally published in The Qualified Coder on Medium, where people are continuing the conversation by highlighting and responding to this story.

So how can your company improve its chances in a competitive hiring market? Check out our cheat sheet below for seven tips on landing the best and brightest software developers!

The Cheat Sheet

1. Create an enjoyable candidate experience: Gone are the days of nerve-wracking interviews and stressful hiring processes. Candidates place a premium on the hiring experience as a positive or negative experience can change their opinion of a company for the better or worse. And with 25% of SSD 2018 participants saying employee referrals is the most efficient way of hiring talent (more than any other method), it’s important that your team members have a great candidate experience as they are your company’s strongest ambassadors, helping to fill new positions that open up.
2. Establish a smooth interview process: An extension of tip 1 above, it’s important to implement an efficient and frictionless interview process between the candidate and all stakeholders. Properly prep each candidate for their interviews with expectations so they can be on their A-game, and ensure interviews are timely as candidates are likely under consideration at multiple companies. It’s a job seeker’s market, so by implementing a smooth interview process, you can give your company an edge over competitors.
3. Maintain clear communication: If you were considering multiple companies, would you pick the one that was on the ball about communicating the timeline of the candidate process from start to finish, or the company that left you in the dark? Easy answer. By maintaining clear communication of the process schedule, which assessments will be made and how they will be delivered, which skills will be tested, and conveying what is important to the company and culture, you present your organization as an attractive, well-run machine.
4. Reveal the relevance: The candidate experience is packed with interviews and assessments as the company tries to evaluate each developer under consideration, but are you sure the candidate understands the who/what/why of each step? Get the most out of your candidate by disclosing the relevance of each person they meet and why they’re meeting with them. Likewise, the candidates should understand how the assessments relate to the position they are applying for (Qualified can help!).
5. Implement a consistent interview structure: Your company may see dozens of candidates for each open position, so how do the developers stack up against one another? There’s no way to really know unless you implement an interview structure that is consistent across all candidates by using the same questions and assessments. This standardization will help you compare the strengths and weakness of each candidate so that the hiring team and stakeholders can make a well-informed decision.
6. Allow room for flexibility in hiring practices: Are you looking to hire an entry-level, junior, or senior developer? The demands of the position may require you to tweak your hiring practices in order to court the talent you need. Since positions differ, allow flexibility to adjust your recruiting process so you can find the best match for each open role.
7. Understand the culture: 39.6% of SSD 2018 participants report culture fit as being the most important hiring criterion (second only to willingness to learn at 44.5%). From a company standpoint, it’s critical to know your own dev culture in order to evaluate whether a candidate will make a seamless fit. Even if your company is looking for diverse mindsets, you must have a firm grasp of the culture to help gauge different perspectives. It’s equally as important to set up resources for candidates to learn about your company and culture so that they can determine whether the organization is a place where they can make a positive impact.

When it comes to assessing developer skills, Qualified can help. Demand for brilliant software developers are outpacing supply. Your company can position itself for a fast, optimized talent recruitment process by implementing the tips from the cheat sheet above- or by making sure you know what competencies you are hiring for (another thing we support). Our online platform streamlines the candidate process by quickly identifying the best technical candidates through code assessments, pair-programming interviews, and personal sessions of outlining candidate competencies. Send us a message to learn more.

___________________________________________________________________

References:

https://www.glassdoor.com/Salaries/software-developer-salary-SRCH_KO0,18.htm

https://codingsans.com/uploads/landing/State-of-Software-Development-2018_final.pdf

https://codingsans.com/uploads/landing/State-of-Software-Development-2018_final.pdf

Hiring Software Developers Cheat Sheet was originally published in The Qualified Coder on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hiring the right engineer for the job is critical to a company’s success. So, how can we ensure that we are finding the perfect person for the position? While testing a potential hire’s coding ability should be primary step in assessing fit, the following seven characteristics will be key in finding your perfect developer beyond the technical skills.

Passionate

A programmer who is passionate about his or her work will be 10x more effective than someone who is in it just for the paycheck. A passionate programmer may not necessarily consider programming both their job and their hobby, but they often do. They like to explore new technologies and concepts, and are constantly pushing their limits, not because they have to, but because they enjoy the challenge. They will often spend much of their personal time learning technologies they are excited about.

Focus - keep their eye on the ball

A programmer who understands why they are doing what they are doing will stay focused and on task. You want them to be generally passionate about their field, but you also want to know they will stay focused on the short and long term goals at hand. You don’t want coders who find themselves on tangents, trying to implement the latest and greatest, but unnecessary, technology into the codebase — or trying to over-optimize things they are interested in that aren’t a high priority for the team.

Fast Self Learner

The state of the art of programming is constantly evolving. Programmers need to demonstrate that they can pick up new technologies, techniques and best practices quickly. Once a developer understands the core concepts of programming, they should be able to build off of that knowledge. If a programmer can’t pick up any new programming skills on their own without having someone teach them, they aren’t going to last long. Staying up to date with cutting edge technology is pertinent to a company’s advancement, innovation and success.

(Sub-)Domain Expert

Most companies these days are not hiring what you would call “generalists”. Generalists are developers who have a solid foundation in computer science and a broad knowledge across many different types of technologies, often with one domain that they know best. For example you may have a generalist web developer who can do both front-end (UI) and back-end (business logic) development. While generalists are great utility players, they will often not be as well informed of all of the latest technologies and techniques. Most companies are looking toward more specialized talent. Advances in development are happening so rapidly that it has become increasingly difficult to stay on top of latest develops within a specific domain. Of course, it’s still incredibly important for a developer to have solid fundamentals and a strong understanding of their domain, but they should also be an expert on the specific technology sub-domain they are being considered for. A web specialist would likely know much more than a web generalist about front-end development, but little to nothing about back-end development. This is why testing for specific on-the-job skills is vital in hiring a developer who will most effectively contribute to your company’s specialized demands.

Team Player

Programming is a form of reproducible logic/thought, therefore developers will invariably have their own style. You will rarely see two developers come up with the same exact solution, or possibly even the same general approach, to the same complex problem. Programmers need to be able to show that they can adapt to the standards of a team, and write code that takes into account others potentially needing to work on it later. They should write code that makes logical sense to others and isn’t overly specific to their own unique style of organization and thought. A new hire needs to understand how an existing codebase works and how to add to the collective work of a team, while keeping concepts consistent. They should write documentation that helps their colleagues understand their work. They should be able to present their thoughts and take constructive feedback without taking it personally. This is why when hiring a new developer, it is vital to be able to watch their process when writing their code in order to get insight into their unique approach and feel into whether it will fit into the existing teams’.

Problem Solver

Problem solving is at the core of what a programmer does. This involves a few aspects — first, engineers need to be able to prove that they can quickly identify the cause to an issue. Next, they need to show determination and efficiency in solving it. This might be a bug with an existing set of code, a scalability problem regarding how to handle increased demand of a product, a maintainability matter when dealing with increasing complexity of code, etc. Not only does the problem need to be located efficiently, but the developer must also be able to solve it in a clear and concise way.

Craftsman

Great programmers take pride in their craft. They write efficient code that is well thought out and well tested. They sweat the details, while still aware that they need to deliver on time. Craftsmanship is all about the quality of the product. There is a big difference between simply being skilled, and executing that skill with creativity and dexterity.

It isn’t always easy finding the right developers, but when you know what to look for and to test for, you’ll be 10x closer to building your perfect team.

7 Traits to Look for when Hiring a Developer was originally published in The Qualified Coder on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Phil DeJarnett

If you are new to software development, whether starting as a professional or even just learning as a student, you probably find the culture intimidating. The range of skills required to become a “great” developer is vast, with low-level skills that range from a solid sense of mathematics to high-level skills like user-interface design.

It can be overwhelming trying to balance learning all these skills, especially while trying to keep up with the constantly evolving software industry. What can you do to improve your abilities, to get from where you are to where you want to be?

In my 20 years of professional experience, reading books and articles and watching videos is not the important step. The most important thing is…

Practice!

If you are learning how to play an instrument, it’s no question for most people that you can’t get anywhere until you pick up the instrument and try to play it. And it’s not just once in awhile, either. Instrument practice is something most musicians do every day. Even if they are professionals.

Learning theory and exploring new ideas is, obviously, essential to improving yourself in any discipline. The most important step, though, is turning those concepts into engrained knowledge and muscle memory. In this way, programming is a lot like learning an instrument.

Until you burn in those core concepts — and you will need to continue to learn these throughout your career — you will struggle with the basic components of programming, for example:

1. How to approach a problem
2. How to break it down
3. How to test and find bugs
4. How to quickly narrow down the likely source of a bug
5. How to improve performance and maintainability.

How Do You Practice to be a great Developer?

On the surface, this seems like a dumb question, but it really isn’t! Practicing an instrument diverges from programming, because you can pick up a piece of music and play that same piece over-and-over until you get better. Programming doesn’t work quite the same way, because once you’ve solved a problem, you can, at best, iterate on that solution to improve it.

That’s an important step, but to really expand your knowledge, you need to regularly find new challenges.

Find Your Own Projects

The best way to learn is to find a problem you want to solve, and try to solve it yourself. Maybe you want to automate something, or calculate some value regularly.

Basically keep your eyes open in your own life for things that you would like to work better, or try to improve on something you already use. Then try to research and see if you can solve it. Don’t get caught up in finding a “perfect” solution, rather see how close you can get in a short amount of time.

These little exercises will keep your mind fresh and have the benefit of having no fixed goal, so you can have fun with them.

Open Source

A common recommendation is to look for Open Source projects you can help on. I definitely recommend digging into the FOSS culture, as it will expose you to a wide and varied set of skills and viewpoints.

Unlike a lot of programmers, I don’t think this works perfectly for someone starting out, simply because jumping into even a small OSS project is overwhelming, as there’s a ton of basic concepts that you are expected to already understand, like code style, language tricks and concepts, and more.

Competitive Programming Sites

My favorite site for daily programming challenges is Codewars. (Disclaimer: I liked it so much, I now work for them.) Codewars is great for honing your developer skills, as it provides new content all the time, in a wide variety of languages, so you can make sure you flex that programming muscle whenever you get the urge.

Make Mistakes Every Day

I think this is the most important step, and the most important skill to learn. You need to make mistakes every day. Every time you practice, practice until you make a mistake. Learn from that mistake.

If you try a new problem and solve it easily, you probably aren’t learning anything new. That is more like reciting a previously learned skill. When you come across a problem you can solve in your head, find a new way to solve that same problem. Don’t even worry if it’s not the best way, just expand your skills with new ideas.

Great Practice Tips

To really accelerate your education, follow these tips:

Break Your Code

A common mistake very early programmers make is to write it, then only run it once or against the most simple scenario. A great way to deepen your abilities is to purposefully try to break your own code.

Find unexpected ways to run your code, test on different machines, disable the internet, etc. Ask yourself:

• Does it still work, or does it just crash? (If it crashes, see the next section.)
• If it runs, does it report errors?
• Can you find a way to handle those errors without stopping the program? As an example, if it fails due to the internet being down, maybe you could try the request again later, and only stop if several requests fail.

Learn How to Debug

This is a deeper topic than can easily be covered here, but every language has some way of debugging. This is another reason why you should make mistakes every day: you want a reason to dive down under the surface of your code and understand what’s happening at a deeper level.

Most debugging will let you step through your program — jumping deeper into the lower layers and learning what really happens when you call a method, or set a value, or make a network request.

The goal with debugging — from a learning standpoint — is to build up that muscle memory about how the parts of a program are glued together. The deeper this knowledge, the easier it will be to predict, find, and fix bugs in the future.

Don’t Ask Questions…

…at least not immediately. Instead, try anything and everything you can think of. This is more important the less comfortable you are with a concept or language.

When you can’t think of anything on your own, search! The Internet is overflowing with help for learning programmers. Find answers and try them out, but don’t just copy-and-paste and move on. Modify those answers, see if you can understand why they work, adopt them to your code.

…But Always Seek Advice

When you have tried everything, and preferably after you have a working solution, now is the best time to seek advice. Look to peers and senior developers to review your code.

Take that advice, apply it and use it in the future. Rewrite what you already did with those suggestions in mind. Ask yourself

• Did they help improve the code? If so, how?
• Did they make it more readable? How can you apply that in the future?
• Did they improve performance? What assumptions did the old code make that were less performant?
• Can you expand on that suggestion? Maybe you can apply the changes in similar ways to other parts of your code.

Now, Start Practicing!

Now that you have some ideas, get out there and start practicing! The longer you wait, the longer before you’ll feel confident enough to take the next steps in your developer career.

There’s no time like right now to begin turning that surface knowledge into long-term, deeper skills.

Interested in what we’re working on? Check out Qualified for Education and Qualified Codecast.

The Key to Becoming a Great Software Developer was originally published in The Qualified Coder on Medium, where people are continuing the conversation by highlighting and responding to this story.

by Nathan Doctor

Great companies spend immense resources searching for talented engineers, and even more to bring them onto the team. These recruiting and sourcing costs add up quickly.

While these costs amount to a serious expense, with salary making up the majority of engineering budgets, they don’t expose the true cost of hiring to companies. The real cost of hiring engineers is far less apparent. It’s hidden in a subtle way, but can seriously drain resources and productivity.

This hidden cost of hiring is embedded in the hundreds of hours your engineers spend evaluating and assessing candidates. Through resume review, phone screens, technical interviews and extensive on-sites, days worth of time is allocated to candidates, the majority of which don’t make it to hire. These talented (and expensive) team members’ energies should be focused, as much as possible, on innovating and building product — the tasks that will drive the company forward.

The true, hidden cost of hiring — your engineers’ time — reduces your company’s ability to innovate and could be costing you $22,750 of enterprise value per hire.

The Value of your Engineers

All of our hiring expenses, both apparent and discrete, go into finding great engineers precisely because of how valuable they are to the organization. Their value stems from their large impact on the product and the technology that drives the business forward.

Their skills and talents are cultivated over years of professional experience. These engineers pour their enthusiasm and abilities into writing great software, which is why we bring them onto our teams. Yet engineering teams still carry a heavy burden in the hiring process, the necessity to evaluate and assess potential hires, with countless hours of their time.

Inefficient use of Engineering Time

All too often a company’s hiring process overuses their engineering talent for pre-screens and interviews, many times with candidates who aren’t qualified to begin with.

On larger teams, engineers are often scheduled out to interview candidates who have only been minimally pre-screened. They spend their time reviewing code samples and projects, running on-site interviews, and holding technical phone screens with candidates who don’t even end up making it far in the hiring process.

In smaller and growing teams, this burden often falls to the already overworked CTO, VP or Director of Engineering. With minimal recruiting infrastructure, or dedicated recruiters, they are forced to field all candidate flow. This becomes a major distraction to their most important duty — leading the existing technical team and ensuring engineering resources are produced effectively.

Regardless of the spectrum of company size and the seniority of engineers, it is vital that companies find the right balance within the hiring process in order to ensure that valuable engineering hours aren’t being wasted.

$22,750 in Costs

Assume a developer’s cost of productivity to the company is roughly $350/hr (far more for team leads and directors). This estimates the value that a software developer’s work delivers to your company in the form of product improvements and innovation. These improvements then result in increased growth, improved sales and added business-value. This can be broken down based on the base cost of salary (avg. $120,000/yr for an experienced developer), the 25–50% extra enterprise costs (benefits, healthcare, perks, employer taxes), and the premium of return, the company expects to receive on top of it, about 3x the full cost.

We then look at the three main tasks that company has to fulfill to review each potential hire — the resume review, a phone screen, and an in-person interview. Typically companies see a large ratio of applicants/interviews/hires, in Marketo’s case their 80/8/1 rules, whereby 100 applicants will lead to 10 interviews which results in 1 hire. This number ranges although it’s safe to say that companies look at over 60 resumes, get on a phone call or technical screen with 10 of them and will do 5 in-person interviews to find their next engineering hire. This allocation can shift based on roles, if the company has full-time recruiters, how many candidates they send to engineering/tech phone screens, and if the engineering lead is doing resume review. In general, these hours break down to:

Resume Review
60 resumes * 5 mins = 5 hrs
Phone/Tech Screen
10 screens * 60 mins = 10 hrs
In-Person Interview (day-long, across multiple interviewers)
5 interviews * 10 hrs = 50 hrs

65 hrs at $350/hr = $22,750

This comes to an average of 65 hours per engineer hired for $22,750 of business costs, and even more for longer processes or more competitive positions. With the importance of engineering innovation and progress, this is not a cost that we want to ignore.

Recruiting as a Burden on Developers

While the sheer hours that get wasted on ineffective and unnecessary interviews can take a huge toll on productivity, there are even further impacts that result from the energy expense.

Seemingly small distractions can completely undo hours of work. Interviews, with potentially unqualified candidates, distract engineers from what they were hired to do — use code to solve problems. This requires focus in order to perform optimally, especially when faced with difficult technical demands. Because it takes continuous precise focus to work toward an effective solution, this distraction can actually have a demoralizing effect as it breaks work flow — short-term memory gets loaded with all of the moving parts, leaving engineers to rebuild their mental model and take even more time to simply get back to even. An hour long distraction can actually debase hours of work.

Invest Engineering Resources Wisely

Now that we’ve dissected the ways in which engineering teams time and focus can get squandered during recruiting, let’s discuss how we can solve this.

Reducing this $22,750/hire cost comes down to improving recruiting process. We want to increase efficiency so that manual technical screens are only done with worthy candidates, and that only viable talent is making it to each on-site interview.

We must view each engineering interview as an *investment*. We should only be using an engineering teams’ time with candidates that have a high likelihood of being hired. We don’t want to scatter these valuable investments with anyone who enters the process, but rather only those who show strong promise of maturing into a full hire.

Increasing Process Efficiency

The best processes that result in the most efficient use of engineering time often filter candidates beforehand so that coding competency has already been determined. This can be done in a variety of ways, through skill assessments, referral-based hiring, and coding competency tests. This serves to accelerate the process, while simultaneously allowing engineers, CTOs, VPs and Directors of engineering to focus on their main tasks, only investing in a few interviews with promising candidates. In addition, this process is respectful to the candidate’s time, as it allows for quick and deliberate decision when an otherwise drawn out process may not lead anywhere.

This is the reason we built Qualified.io to save engineering teams time and accelerate their hiring process. In reducing the amount of time engineering teams spend evaluating candidates, we increase process effectiveness and identify great developers faster. This helps eliminate the hidden cost of the hiring process and allows your company to drive forward with every hour of engineering genius that you have.

The hidden cost of hiring engineers — $22,750/hire was originally published in The Qualified Coder on Medium, where people are continuing the conversation by highlighting and responding to this story.