Category: hiring

Who Needs Side Projects?

The topic of side projects or personal projects for software professionals (commonly in the form of mobile apps, websites, various GitHub repos, and even technical blogs) has been fairly well-documented in the past few years. The concept of side projects as hiring barometer is still a relatively nascent industry phenomenon that emerged in parallel with the rising popularity and eventual ubiquity of open source software, web-based repository hosting, and usable blogging platforms. I distinctly remember the first time a client of mine indicated a preference (however slight) for candidates that could demonstrate coding from outside their employment. It was 2004, still a few years before GitHub.

The growth of SourceForge and then GitHub provided the opportunity to collaborate easily and effectively with friends, colleagues, or even strangers. Some engineers chose to code off-hours and some chose not to. As has been written before, others may not have had the time. Whether engineers did or did not contribute to open source or create side projects, all eventually became aware of the trend, and some likely predicted that the landscape for job search may be changing.

Flash-forward to today, where we commonly see job advertisements requesting a résumé and links to GitHub or personal projects. College seniors scramble to assemble a code portfolio while balancing internships and coursework in their final semesters. Highly experienced engineers with 20 years of stable employment and a formidable list of professional accomplishments still wonder if their work alone is enough to compete for jobs. Even high school students ask questions about starting to build things in preparation for a job search several years down the line.

It’s clear that many engineers are concerned with the perceived necessity for personal projects, regardless of experience. Blogs like mine are probably guilty of unintentionally feeding fears, as career advice is not one-size-fits-all. It’s a useful exercise to clarify the benefit of side projects for different groups.

Who benefits most from side projects?

Entry-level candidates, new college graduates – When a group of largely homogenous candidates compete for positions, side projects are a differentiator. Typical résumés for new grads list GPA and select courses. Without internships or projects, they are virtually identical in every way. Even a link to rather mundane GitHub repos might give employers a bit of insight into ability.

Recent industry entrants without marketable experience – Many professionals are forced to accept undesirable jobs due to personal circumstances, while others make poor career choices early on. Two or three years of professional experience in the wrong shop might not lead to any real accomplishments. Side projects may be the best method to demonstrate skill early in a career.

Stagnant employment history – Candidates who have held the same position in the same company for many years are subject to somewhat unique scrutiny, with the most common theme being the concept of whether someone has “ten years of experience or only one year of experience ten times“. Showing some other skills gained outside work might shed the one-trick pony image and demonstrate an interest in learning.

Dated skill set, limited technical environment – For some engineers, side work might be the only opportunity to play with the new and shiny toys that other employers use. If the day job only allows archaic languages and tools, future marketability may depend upon side projects.

Those looking to change their path – Similar to entry-level candidates, professionals attempting to alter career direction may look to side projects as their most powerful strategy to gain some credibility. A good example of this is the large number of budding engineers who accepted QA positions while intending to move into development roles, or web developers who seek employment in mobile.

Conclusion

Side projects are often effectively used in lieu of work experience and tangible accomplishments in order to establish credibility and demonstrate skills. Their importance fades over time for professionals in ideal technical environments, defined as places where engineers are productive, learn continuously, move between projects and groups, and are able to develop a varied set of marketable skills. The value of side projects may vary over the course of a career depending on factors in the workplace, which are usually beyond the employee’s control. The groups outlined above derive the most benefit from side projects. For established and highly accomplished professionals, side projects can be completely unnecessary.

Graph

Why Hire Older Engineers

Another day, another article about age and technology. The comments of these articles usually escalate into some generational war played out with mythology and anecdotes regarding relative energy levels and productivity, work hours, the value of experience, and general competence. These discussions usually make no progress, while some useful topics are ignored.

As someone who has been around programmers (and ran a Java Users Group) for about 15 years, I often guide senior technologists in marketing their skills. When doing business with clients, I find myself advocating on behalf of older coders regularly. During the first dot com boom multiple six-figure job offers were dealt to anyone at any age who could spell J-A-V-A, but the landscape is much different now.

Most companies I’ve worked with give candidates of all ages a fair shake, although I’ve witnessed some who have been less friendly to industry veterans. For firms that need additional justification for hiring older workers, here are a few additional considerations that may go beyond the more common topics of discussion.

mainframe picture

Recruiting – So your efforts to scale your team came to a screeching halt? Inevitably the friends and family network dries up and firms rely on internal recruiters or outside agencies to identify talent. Although young hires may be more connected due to early adoption of social networks, older workers usually come with established professional networks. These contacts are not just other senior engineers, but will also include younger former co-workers. When you consider the costs of recruiting (not to mention the costs of a bad hire), the ability to tap into the network of highly experienced engineers might even justify paying a higher salary.

Beyond just the network a senior engineer may possess, having experienced talent on staff will appeal to young candidates who understand the value of learning and career development. A predominance of junior engineers will typically scare off older applicants, and it’s also likely to be a red flag for some subset of the young. Graduates are typically encouraged to find a career mentor, and they will seek experienced professionals to serve in that capacity.

I generally advise my clients on employing some senior level engineers who are strong coders but will also serve a secondary purpose of attracting other less experienced hires. The term I usually use is “hire magnets“, and those magnets may fit a few different profiles. The magnet could be a recognized authority on a topic, an involved tech community leader, or simply a knowledgeable and charismatic developer who enjoys sharing knowledge.

Fad recognition – Industry experience may give engineers a sharpened ability to sniff out the difference between a passing fad and the genuine article when considering new technologies. This of course isn’t by rule, but once an engineer has seen enough shiny things being hyped by marketers and evangelists it should theoretically become easier to evaluate trends with less bias. Hires with this skill may save a company time, money, and many developer hours.

Less performance unknowns – Older engineers with a documented work history, a list of credible references, and demonstrable work experience should be easier to vet than juniors coming from their first or second job. The ability to rely on past performance to predict the future is a benefit, though never perfect.

Retention/stability – Employee retention is a serious concern and cost for many firms, with demand for talent contributing to turnover. Older engineers and those with families should be less likely to consider relocation for new positions, which limits their other employment options to local or regional opportunities. Although both junior and senior level engineers may have bills to pay, the breadwinner concept changes perspective and may result in satisfied and fairly-compensated developers staying put.

Senior level developers often reach a point where compensation plateaus and money ceases to be an incentive to change jobs. Employees less driven by dollars are surely driven by something. It could be something as simple as proximity to their home or a desire to solve complex technical problems, but competitors are less apt to change these factors and often need to compete with pay.

From my experience, most engineers see fewer significant increases related to job change around their 15th year in the business, and by the time someone reaches that level of seniority it isn’t unusual to have once taken a pay cut. Junior level talent in competitive markets view job change as the most reliable means to salary increases, while the relatively minor compensation differential for senior engineers may not outweigh the uncertainty of a new employer.

Unique situations – There are some scenarios that happen in development shops that are nearly impossible to replicate in a classroom or lab setting, and the ability to face the unexpected comes from being there. This could refer to crisis management when a server goes down, handling difficult customers, or knowing how to navigate office politics. Prior exposure does not guarantee preparedness, but should make the second experience less shocking.

On-the-job learning – Older engineers may now be on their second or third set of platforms and corresponding tools. Developing the ability to learn new languages and tools in a work environment is a skill. It is quite valuable to know how much (or how little) to read before starting a project with an unfamiliar component, or which methods are most effective for you when seeking knowledge.

Any that I missed?