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.

This enjoyment feeling is succinctly captured by Mihaly Csikszentmihalyi in his concept of Flow. Flow is what I strive for every day of my programming career, but I don’t always get there. It’s not easy and sometimes I fear it’s beyond my control. There are so many factors both internal and external to the computer that are crucial to developing a product. Many of these factors will remain unknown to us until they inevitably pop up out of nowhere; snapping us out of any semblance of a programming flow. On the best of days we handle these problems with grace and understand how to circumvent, on the worst of the days we fight them head on and get nowhere.

So how do we recognize the worst of days? How do we know when to cut our losses and try another approach? How do we maximize the potential for reaching flow in our daily lives as developers?

Asking ourselves these questions is the first step. Being introspective and truly honest with one’s self is the quickest way to any real personal progress. There are so many factors that naturally affect our flow; some may be unique to certain developers while others may be more common than we realize. Recognizing the factors that most affect you and your team is paramount to your success in the field.

From talking to my colleagues and examining these factors within myself, there appears to be some patterns in the things that affect us most. Let’s take a look at some of these factors.

Find Challenges that Suit You

Challenges and goals should never be too easy. You should always be adjusting your trajectory towards ambitions that excite and even scare you a bit. Ideally this is finding an organization whose purpose aligns most with your own objectives. At a minimum this is finding challenges and goals to set within your organization that will intrinsically motivate you.

Finding these challenges is fairly straightforward when tasked with a new project or exciting new feature. However, there will be times where you will be faced with a long list of simple bugs or mundane tasks. Even within these instances, there are techniques that can be utilized towards setting your own challenge level and achieving flow.

For simple bugs, ask yourself:

Can you find the root cause of this bug instead of settling for a band-aid solution? Could this bug occur anywhere else in your codebase? What steps can be taken to preventing it from occurring ever again?

You can choose to see it not just as one bug, but as an instance of a class of bugs. See it as an opportunity to catch something now and determine procedure towards making sure variations of it never occur again. Make it your personal vendetta to extinguish those bugs once and for all.

For mundane tasks, ask yourself:

Can you achieve the goal of the task in a more effective manner than proposed? What kind of additional functionality in this space might delight your end-user? If you’ve done this task before, Is there a way to automate it or create a sort of framework or library to encapsulate your solution?

Understanding your natural cycle of energy throughout the day is another factor to consider. Perhaps you are somebody who is more adapted towards taking on creative tasks in the morning, while handling the more routine tasks or bug fixes in the evening (or vice versa). Keep a log and examine the days you feel most productive. How were those days structured?

Stay Healthy and Alert

For most developers, programming is a career and it’s something we intend to be doing for years and years. If you have a habit now that you cannot foresee yourself maintaining for the next 10 years of your life, when will it stop? Will you see the crash coming or will you burn out first?

We need to maintain our mental and physical well-being every day of our lives to the best of our ability. Doing this will boost not only our longevity in the field, but also our daily productivity. Let’s focus on some things we can do to maintain or physical and mental interests.

• Eat smart and understand what you’re putting into your body does to your productivity levels. In an effort to maintain productivity into the afternoon I’ve found keeping lighter lunches helps increase productivity. The industrious Benjamin Franklin believed that always being a bit hungry is essential to productivity.
• Sleeping enough to reach the recommended amount, when possible. When it’s not possible understand what it does to your productivity. You may find that you’re better off crushing quick, easy tasks and bugs when you’re sleep deprived; or maybe it’s documentation. Whatever it is, maybe save it until Friday when you’ve got that late concert Thursday night.
• Meditation can be effective for both creative purposes and maintaining focus. It can open your mind to allow ideas to flow in or calm your mind to focus on the things that really matter.
• Exercise will keep you feeling strong, alert and healthy. It’s not necessary that you become an athlete, but our bodies were not meant to stay in one position all day. Make sure you move around a bit, find something that makes you want to stay on your feet for an hour or two.
• Keeping consistent with your schedule will allow you to find your most productive self. Just as we do with our computers, we’ll want to program our daily lives to be as efficient as possible. Explore the bounds of what your schedule can hold for you and then reign in on the habits that best perpetuate your goals and desires.

Know When its Time to Take a Break

As important as it is to stay focused and on track, there are times when we push too headstrong into a problem and we need to take a step back and allow our brains to open up and get creative. Taking a break or changing the scenery can help spur new ideas.

Don’t be afraid to take breaks when you’re not feeling productive. If you have the freedom you can go for a long walk, a bike ride or a long drive in your car. Maybe take a laptop or notebook to a local coffee shop or park and try to write some ideas out there. Often times our minds are still working on tough problems even while we’re not consciously aware of it; when we’re sleeping, showering, or eating. It’s surprising how often we’ll stumble on our most creative solutions the morning after a long night of grinding away at a problem trying to force something to happen.

It can be especially beneficial to find complimentary training or learning resources that provide you with a break, while still learning concepts that can be applied to the difficult problem you’re stuck on. I was introduced to Codewars three years ago by a co-worker and it’s been a favorite resource of mine for training programming skills ever since (in full disclosure I work at Codewars now). The beautiful thing about the training modules, referred to as Kata, is that they are small, self-contained programming sessions with clear indicators of success and failure. Through the difficulty settings we can pick the challenge level that engages us and work until we have clearly achieved the solution. Incidentally these are the exact conditions necessary for finding flow.

Wrap Up

We’re lucky as developers to have a craft with the potential to practice and learn to our heart’s content. With only a computer and some decent internet access we can work on our projects and hone our skills through the night. It’s a craft that appeals to those of us with a growth-mindset and the drive to become great at what we do. The only limit to our success is where we choose to spend our time. Regardless of what our personal lives are like, we’re all limited to a certain number of hours that we can put in each week. We may be able to squeeze blood from the stone and pull out some more hours out of our week, but to what end? We must realize that it is not how many hours we put into our craft, but the quality of those hours that really determines our success.

Let’s recognize that finding flow is paramount to our success as developers. Be sure to ask yourself what factors contribute most to your flow and don’t stop there. Ask other developers, especially those on your team, what contributes to their success and focus. Often times posing these questions will bring up insights and factors you’ve never even considered. Picking up on these factors will continue to make you grow and be productive in ways you could have never imagined.

How do you find your flow?

Finding Flow as a Developer was originally published in The Qualified Coder on Medium, where people are continuing the conversation by highlighting and responding to this story.

There’s a common expectation when looking for great developers that they need to be “passionate” about coding, which is often equated to coding long hours. It carries the assumption that the best software engineers live, breathe, and sleep code. That great developers should have intensive work weeks, and fill their free-time with coding side-projects. It wants to see prolific Github accounts, tons of open source contributions, and expects great developers can’t wait to get back to writing code.

In my experience, there are people like that. And they can be great — until they burn out, of course. But while focusing so much time on code can imply that someone is a great developer (though never guarantee it), a lack of after-hours programming does not mean someone will be a worse candidate than someone who does.

In the end, while there’s a lot that separates great developers from mediocre ones, there are more important traits that make a superior developer.

Great Developers Are Problem Solvers

All first-class developers share one common skill: they can solve a problem. Though there’s more to it.

• They have the ability to define the problem it in a way that makes it possible to solve
• They can take their problem definition and break it down to target a solution.
• They are able to assess it from different directions, knowing that complex problems have multiple solutions.
• They also know how to find answers when they are missing information or experience. This is key, because challenging problems always require growth and learning to solve.

One thing you might notice is none of this is specifically related to years experience or raw knowledge. Instead, this is a skill set of its own, that’s often innately developed. From junior to senior, great engineers will be able to follow through on these steps, no matter their experience with the problem domain.

Great Developers Don’t Give Up

I think this is where the misconception that great developers work late comes from. What really is happening is that many amazing developers will get caught up in solving a problem, and want to see it through — or at least get their work to a state where they can take a break without losing their mental model.

This doesn’t mean that all developers have to work this way. The best developers know to always step away from complex issues, to let their mind rest and make it easier to tackle an issue from a different viewpoint.

Great Developers Do Care — About The Quality of Their Work

There is an important distinction here. Great developers care a lot, but they care about the work they do. In the right circumstances, this can be misconstrued as being “passionate,” but I feel like it goes deeper than that. Rather than a general, over-arching concern for all-things-programming, they are going to care about specific issues that affect them and how they work.

For example, a strong developer isn’t always going to accept their first solution. They care about getting the solution right, not just solving it and moving on. This means taking the time to review the solution, looking for edge cases and potential long-term issues. This also means thinking about long-term maintainability — as is appropriate for the problem at hand.

Great Developers Don’t Have to Program After Hours

This is the core issue. Just because someone doesn’t write code after hours doesn’t mean they aren’t a great developer. There are lots of great reasons that a developer might not work after hours on programming. Even more so maintaining balance is very positive to a developer’s mental well-being and will return large gains in the long-term.

• Many developers have other hobbies, that are often orthogonal to software development. If you are looking to hire someone, talk to them about their hobbies and interests.
• If a developer has a family, don’t expect them to have a lot of extra free time. But don’t discount someone here, either. Having a family might mean they’ll get more satisfaction out of the time they have at their job, to focus on challenging themselves and solving problems with code.
• For employed developers, learning about their current role can give you insight into what they find enjoyable or what they dislike about their current job. It also can open the door to learn about what they would like to be working on.

Great Developers Will Stand Out — With the Right Process

Hopefully you can agree: great developers are far more than the hours they log. Evaluating a developer solely on their résumés and extracurricular coding, neither of which show the whole picture, is a guaranteed way to lose talent. So how do you find them?

We’ve found the best way to find great developers is to test their ability to solve problems. Provide them with short, fair, and interesting challenges to solve. The solution to these challenges will give you a lot more insight into how they think and work as a developer.

Things to look for:

• Are they willing to solve tough problems?
• Are they persistent in solving a difficult challenge?
• Are they able solve the problem in a way that is maintainable, and can be understood by other developers?

Choose the Right Process for Your Team

When looking for developers to join your team it’s critical to evaluate potential candidates in a way that allows truly great developers to stand out. That’s our mission at Qualified, accelerating talent assessment in a way that saves time, while unearthing true talent. In our next articles, we’ll look at different processes you can use to highlight great developers.

Great Developers Don’t Need To Be “Passionate” was originally published in The Qualified Coder on Medium, where people are continuing the conversation by highlighting and responding to this story.