So You Want to Use A Recruiter Part I – Recruit Your Recruiter

This is the first in a three-part series to inform job seekers about working with a recruiter. Part II is “Establishing Boundaries” and Part III is “Warnings”

This week I read an unusually high number of articles (and the comments!) about recruiting. Although most of the discussion quickly turns to harsh criticism, there are always a few people wondering the best ways to find a decent recruiter to work with and what to do once they have established contact.

Some recruiter demand stems from candidates looking to relocate into areas where they have no network, while others just want to maximize their options and feel they may benefit from the services provided by an agency recruiter. Regardless of your reasons for seeking out an agency recruiter, first you have to find one.

Finding a Recruiter

There are three reliable methods to getting introduced to a recruiter.

Referral

This is the best method for most, as being introduced by a contact can have unexpected benefits. To maximize those benefits, you must consider the source of your referral.

If the recruiter has a great deal of respect for the person introducing you, you are likely to be given some immediate credibility and favorable treatment due to that association. Unfortunately the alternative is true, and if you are referred by someone the recruiter does not respect it may be assumed that you are not a strong talent. When asking for recruiter referrals it is wise to start with the most talented people in your network.

Your network does not have to be the only source of referrals, particularly if you are looking for a recruiter in an area where you have no network. User group and meetup leaders are frequently contacted by recruiters and one should expect group leaders to be knowledgeable of the local market. Even a random email to an engineer in another location could result in a solid lead.

Let the recruiter find you

If I had a nickel for every time I heard technologists complain that they aren’t hearing from enough recruiters, I’d be poor – though some voice frustration that they don’t hear from the ‘right ones‘. Increasing your visibility will attract recruiters who may or may not be the ones you’d want, but it helps establish a pool for evaluation to choose who is worthy of a response.

To maximize your chances of being found and contacted, you need to consider how recruiters will find you. The obvious place is LinkedIn, and spending a few minutes fixing up your profile will help.

Keywords and SEO concepts as well as profile ‘completeness’ should be your focus. (further reading on this) Recruiters are likely to be searching for combinations of keywords from their requirements, usually with some advanced search filters based on location, education, or experience. Completeness matters.

Some recruiters search Twitter and the other standard social sites as well. If you have a profile anywhere, just assume that a recruiter might find it and optimize keywords similarly.

Keep in mind how easy or difficult it is for people to contact you once you’ve been found. Just because I see your LinkedIn profile or Google + account doesn’t mean I can contact you. Many professionals create an email address (maybe currentemail-jobs@domain) strictly for recruiter correspondence and include it in their LinkedIn profile and other social pages.

Another option is to get discovered on job search sites like Indeed, Monster, and Dice. These are frequented by active job seekers, and some recruiters may view your posting there as a somewhat negative signal. Be warned that posting personal information on these sites means that those phone numbers or email addresses will live forever in the databases of recruiters everywhere.

PROTIP: Those that complain about recruiters often cite laziness in the initial contact. This may be evidenced by an obvious cut and paste or clear signs that the recruiter didn’t read the bio. If you want to screen out recruiters that don’t do the work, put up a barrier to weed out the lazy. This page that uses scripts in Python and Haskell to hide an email address is perhaps my favorite, but there are other less clever ways if you want to set the bar lower than the ability to cut/paste code into a compiler.

Search

Recruiters search for you, and you can search for them. Most recruiters are going to be easiest to find on LinkedIn due to the amount of time they spend there.

1 – Click on Advanced at the top of the main LinkedIn screen (just to the right of the search bar)  

advanced copy

2 – On the upper left side of your screen you will see several fields.  Make sure you are doing a People search (and not a Jobs search).

people search copy

3 – Type ‘Recruiter’ and other terms specific to you in the Keywords field.  Try ‘developer‘ or ‘programmer’ and a term that a recruiter might use to brand you, such as a language.  Recruiters often populate their LinkedIn profiles with the technologies they seek, not unlike job seekers trying to catch the automated eye of a résumé scanning system.

keywords copy

4 – Enter the zip code of the area where you wish to find work and consider setting a mile limit.  Some recruiters work nationally, but local knowledge goes a long way if you are seeking to work in one area. Once you start entering the code, a menu appears.  Depending on where you live, you may want to select 25 or 50 miles (probably good for northeast or mid-Atlantic US), or up to 100 miles (for midwest).

location copy

5 – On the right, make sure you have 3rd + Everyone Else checked under Relationship.   This will maximize your results, particularly if your LinkedIn network is small.

3rd copy

6 – Click Search. Repeat, and vary the words you used in Step 3.  You should see a few different faces as you adjust the keywords, and you’ll also see whether you have connections in common with those in your search results.

Twitter is another decent option. Make sure you are searching People (and not Everything), and pair up the word recruiter with some keywords and/or geographic locations. You’ll get numerous hits in most cases, and should only have to do a bit of legwork to find their bios.

In addition to being able to find recruiters on social sites, you can use job boards as well. If you search for a Ruby job in New York City, you may quickly find that several of the listings are posted by one or two recruiting companies. Look into those firms to see if they have a specialty practice.

Search engines might be a bit less useful and are likely to turn up the same listings found on job boards.

Evaluating a Recruiter

Once you have found a pool of potential recruiters, you need to decide which ones to contact. Most job seekers want a recruiter that can provide quality opportunities, has deep market knowledge, can leverage industry relationships, and will navigate issues in the hiring process.

What criteria should we use in the evaluation?

Experience

Just like most disciplines, in recruiting there is no substitute for experience. It takes time to develop contacts and to learn how to uncover potential land mines. Extensive education, recruitment certifications, and training programs don’t get you a network or prepare you for handling unique situations.

Early in my career I know I made many of the mistakes that technologists complain about, and I didn’t have a solid network or steady clients for at least five years. At a certain point in your recruiting career you may not have seen it all, but it’s rare that you are surprised by an outcome.

Focus and Expertise

Experienced recruiters that have spent little time in the industry may be good for general job search advice or negotiation, but can’t provide full value. Look for a consistent track record of years in your field and geography of your search. Talking to a few generalists will make the specialists stand out.

Relationships/Clients

Since recruiters aren’t paid by you and differ from a placement agency, it’s important that the firm has client relationships. Most firms do not advertise their client names which can make it difficult to discover the strength of an agency’s opportunities. The descriptions themselves could be enough to convince you that the agency has attractive clients. Agencies with solid relationships may reach out to past clients and contacts when they don’t have a position that is a clear fit for your background.

Personality fit

Being that an agency recruiter is going to be representing you to companies and even advocating and negotiating on your behalf, it’s important that you get along. You don’t need to be best friends, but someone who dislikes you is unlikely to fight for your best interests.

A ten minute call should give the insight you need to make the decision. Ask questions about their experience and pay attention to the types of questions they ask you. If they don’t dig into your goals and objectives, they probably aren’t concerned with finding a good fit for you.

 

How I Learned To Appreciate Job Hoppers

The possibility of being labeled a job hopper is still a concern for many in the technology world. This fear is often unreasonable and is primarily a function of traditional and antiquated employment concepts being extended into an economy where they likely don’t belong. In other words, don’t take career advice from your parents.

When I first started recruiting software engineers during the late 90’s dot-com boom, I was advised by more senior coworkers to avoid wasting time speaking with job hoppers. People who frequently switched employers were perceived as high risk for companies who needed to invest significant time and money into making new hires effective, only to lose them shortly thereafter. Recruiters were afraid a placement might not even reach their guarantee period.

The economy and workforce as a whole were undergoing rapid and dramatic changes, but long-established preconceptions about employment were somewhat slower to adapt. Linear career paths were the expectation, and the prevailing practice was still to promote our best engineers into management without regard for their leadership potential or soft skills. Company loyalty was still a strong emotional factor that resulted in long tenures.

This new well-funded software startup ecosystem siphoned talent from large and established companies, with engineers leaving behind stability and pensions for modest salaries and stock options that provided get-rich-quick possibilities. Once the big firm pool dried up, they cannibalized and created a class that appeared to many as mercenary startup engineers. This was a class of job hoppers, but their motivations (and subsequently their character) were often misrepresented or misunderstood.

Were they mercenaries?

There were (and still are) a fair share of individuals that chase short-term gains by making job decisions based almost exclusively on numbers. Accepting offers from the highest bidder every time will work for some, but to maximize lifetime earnings (ignoring job satisfaction here) the top offer may not always be the best path. Was this new class of startup job hoppers driven primarily by financial gain?

For most, I believe the answer was no.

Due to the competitive nature of the industry and basic economic principles of supply and demand, most job changes result in at least some small increase in compensation. It would be easy to assume that engineers accepted these offers based on the higher package, but for most the desire for change was probably attributed to the need to build new things.

It’s no coincidence that we find many of the startup job hoppers went on to become independent consultants and contractors, where there is no stigma attached to short stints. We could again make the argument that they were driven to consulting by high rates, and some certainly were, but many point to their preference to finish projects and then move along.

Engineers left many of their startup jobs after a year or two because they had built what they were hired to build, were drawn to the job based on the opportunity to create something, and were much less enthusiastic about maintaining it. This desire to build is a characteristic valued by managers who emphasize getting things done, so they can hardly fault them for leaving when there is little left to do.

Job hopping vs the alternative

Of course, the opposite of job hoppers are employees who remain in the same job for inordinate tenures. Most industries have historically interpreted a long stay with the same employer as a positive sign and an asset for one’s candidacy. In technology this is typically no longer the case. In recent years the adage “Do you have ten years of experience or one year of experience ten times?” has been applied to those who seem more driven by company loyalty and stability than career self-interest.

There was a time when it was more difficult to find new work without a highly stable work history. In today’s technology market, I would make the argument that a career characterized by one or two lengthy employment stints is actually less marketable to the majority of tech employers than your standard job hopper. Discrimination against those with long tenures is often wrongfully attributed to ageism or an overqualified candidate, where the root of the discrimination is a belief that work variety produces better engineers. As a recruiter, removing the appearance of dust or stagnation is a major challenge when working with candidates coming off a long tenure.

Positive vs negative hopping

It’s important to note that there are different kinds of job hoppers, and the picture painted thus far has been mostly of those viewed favorably by the industry. These are people who make self-interested decisions to move once they have maximized their career gain from an opportunity. Usually this meant the ability to gain a new experience, such as learning a skill or building a product. To lose any potential negative stigma associated with job hopping, one should have a list of accomplishments and projects that were seen to completion. That doesn’t mean there can’t be failings along the way, but successful job hoppers have a track record of being hired for a purpose and meeting or exceeding the expectations of the employer. They should also be able to explain the motivations behind each move and why it was right for their career at that time.

The job hoppers that are likely viewed in a negative light often lack both accomplishments and justifications for their transitions, and can often have résumé gaps that aren’t easily explained. They may have a history of abandoning efforts before completion, or are consistently wooed by new employers regardless of current project status. Unemployed job hoppers with these backgrounds eventually have a difficult time in job search.

Conclusion

Attitudes towards those that frequently change jobs have transitioned as the economy has changed, and companies have more realistic expectations about their employees acting in their own self-interests. The stigma around job hopping in technology has almost been eliminated at smaller companies, particularly for candidates who have a solid list of accomplishments and are able to articulate a history of positive career choices.

 

How Ben Accidentally Became a Developer

In early April I received a message from Ben, delivered to my Reddit account.

I’ve been reading /r/resumes for, well, the whole time I’ve been actively looking for another job. I’ve noticed your comments on other posts and respect your opinion. Even though I’m not a “programmer” per se, I do enjoy reading your site and appreciate the time you take to help folks like me who are trying to make the best impression possible.

Ben wanted some advice on his résumé and career prospects in technology, and he wrote a quick bio. He earned a degree in religion and worked in that field for seven years before deciding that his passion was for technology. During his tenure in the church he dabbled in web development and learned to solve basic networking and hardware issues to reduce the church’s technology expenses. He resigned his church position to pursue entry-level roles, and ended up spending a year in retail before eventually being hired as a Junior Computer Technician.

After spending three years in the technician role, Ben asked his manager for additional responsibilities. He was already performing light systems administration tasks for their small office, and was then entrusted to write a web application. Ben taught himself PHP, JavaScript, and SQL. The web app he built became a major revenue source for his company and a highlight of his career.LineDrawingManComputer

Ben, on paper

After learning about Ben’s work history, I reviewed his résumé. The two sentence profile atop his résumé mentioned troubleshooting, managing hardware and software, vendor selection and training. There was no mention of programming experience.

Below the profile was a listing for certifications. None of his certs were truly relevant to programming.

His experience section was next. The first role listed was Systems Administrator, which had descriptions of his accomplishments in that role.

I was now halfway down the page and I have seen nothing about what he saw as his most valuable professional accomplishment. And then there it was – Web Developer. He had duties in both sys admin and development, and chose to list the sys admin experience first.

His technical skills section led with several operating systems, servers, and virtualization tools. Below that, a mere two lines from the bottom of the résumé (just above his degree), he listed programming languages.

“…not a programmer, per se…”?

After I finished reading the résumé, I thought back to his comment from the original Reddit comment. “Even though I’m not a ‘programmer’ per se…” At this point it was hard to tell if Ben would be more marketable (or happier) as a sys admin or a developer, so more information was required. 

Ben then sent me a random email to tell me about his blog, which he had recently converted from WordPress to Octopress and had subsequently picked up some Ruby along the way. I checked it out and saw he had a couple small GitHub repos. This was all news to me. I asked if he had any other programming experience he was hiding.

It turns out he had done some freelance front-end web development work for a bit. He added that he had also contributed to the development of a template that was adopted by WordPress as a stock theme.

Ben might not have considered himself a programmer, but I expected others would disagree.

The Intervention

I sent Ben an email suggesting he focus 100% of job search efforts on finding a development role, and that his experience should qualify him for intermediate level slots. Ben responded that he had been reluctant to seek programming positions because he’d been doing that work for the least amount of time, but acknowledged that he’d probably be happier (and better compensated) as a developer. We worked together over the course of a couple days to rewrite his résumé, which emphasized his coding accomplishments.

Results

Within five days of our first contact, Ben had a couple interviews lined up for web development positions. Fifteen days later Ben accepted a new job offer as a developer, which came with a 60% increase from his prior salary.

Ben now describes himself as a “Full-stack web developer” on his blog.

How to Level Up

I regularly hear from and read about technologists in a career rut. Unless one is both lucky and adept at predicting the future, experiencing some temporary stall can happen to professionals at any career stage. It may be the feeling of being stuck in an unchallenging role, feeling burdened by an undesirable skill set, or trapped in a company that seems difficult to escape.

Career stagnation in technology could be defined as a prolonged period characterized by limited project variety, no advancement or even lateral movement, few tangible accomplishments, and little exposure to any emerging trends. Some managers are aware that workers in these situations generally leave, so the managers may proactively try to satisfy staff by shuffling teams and providing more interesting tasks. Many managers have to focus on deliverables and may give little thought to the career development of their charges, perhaps throwing money at retention problems instead of providing challenges.

levelup copy

To “level up” could mean a promotion into management or technical leadership, a new start at a firm with increased opportunity, a role with autonomy and decision-making responsibility, or the ability to make significant improvements to skills and marketability. People that think about the leveling up concept often know what they want (or sometimes what they don’t want), but don’t necessarily see the best paths to get there.

Leverage the skills you have to get the skills you want

Most professionals view their current skills as a means to getting new jobs, but it’s useful to also think about skills as the key to acquiring other new skills. This tactic is most relevant when a skill set is dated and a previously strong marketability level is now questionable. Some will attempt to make a clean and immediate break from their old technologies or responsibilities into the new, usually with mixed results.

As an example, many COBOL programmers tried to enter the stronger Java job market following Y2K. Some applied to jobs with no Java experience hoping their COBOL years would be deemed transferrable, while others pursued certifications and self-study to ideally be viewed as a somewhat “experienced” hire. One overlooked strategy was to approach companies that were using both COBOL and Java in some capacity, with the understanding that the candidate was willing to write COBOL if provided the ability to also work with Java.

Most job seeking technologists have at least one ability that will help them contribute immediately to any other team or organization. It could be an obscure technical skill, leadership experience, or domain knowledge. Even if the skill is not something the person wants to use forever, it could be a key component to getting hired. Try to identify companies that may be looking for some specific expertise you can provide, even if it isn’t the most attractive tool in your bag, and be transparent about your willingness to do that less desirable work in exchange for exposure to skills that are in demand.

DIY

For those in the most stagnant of technical environments, taking on independent projects or open source may be the best way to gain experience and increase marketability. It’s usually preferable to learn new things on the job (because money), but being proactive about your career and keeping abreast of current marketable technologies will also show initiative to potential employers. The level up from personal projects almost always comes from an employment change.

Sometimes to level up you need to take a step back – or sideways

Careers aren’t always linear, and the expectation that trajectory needs to follow a strict continuous and incremental level of responsibilities is perhaps naive and potentially dangerous. Job seekers are often prone to placing too much weight on a position’s salary or (gasp) title without fully considering the position’s potential opportunity as it relates to future marketability and career development. Somewhat frequent movement between jobs is accepted in our industry, so positions can be viewed as stepping stones to future opportunities.

When evaluating new roles, whether with a current employer or another firm, imagine what a three or four year tenure in that role at that company will look like on future résumés. Will the skills likely to be acquired or improved in that role be marketable and transferrable to other firms? Accepting positions that come with lateral responsibility and compensation is usually a wise long-term decision when provided a more favorable learning and growth environment.

Homakov: Story of a White Hat

In early March 2012, a Russian programmer one month shy of his 19th birthday emerged on the radar of the software world via one “simple” commit that startled both the Rails and GitHub communities.

railscommit

The exploited vulnerability was known to many in the community, so discussion about the controversy gravitated towards GitHub’s failure to properly protect repos and the potentially insecure default settings of Rails. The attention drawn to mass assignment served as a beneficial public service announcement to other Rails users, although the delivery method put off many developers as well as GitHub admins who quickly suspended (and just as quickly reinstated) the account. It was all over within a few hours, but Homakov had “arrived”.

Who is this guy?Homakov

Egor Homakov grew up in Saransk, a small city of 300,000 residents that sits 400 miles east of Moscow and somewhere deep within Ukraine on a Risk board. He dabbled with Delphi as a teenager to learn how programs worked, and later Pascal. His GitHub dates to 2009, oddly enough on New Year’s Eve. After initially struggling to understand programming concepts, his self-study turned a corner when he transitioned to web apps. Homakov dropped out of university before completing a year, which he admits was a risky move for someone in Saransk, but he found the program far too boring to continue.

Homakov initially focused his career on SEO, but when clients were hard to come by he began advertising PHP programming services on SEO forums. When negotiating a proposal to build a simple news management system for an early prospective client, Homakov requested a rate around $10 per hour. The prospect countered with an offer of $30 if the job was done well. This was a significant wage in Saransk, and Homakov distinctly remembers his mother’s pride.

Over the next few years Homakov bounced between employers, with freelancing gigs followed by short stints at European startups in the online payments and travel spaces. Eventually he decided consulting was his best option, and he is now part of the security firm Sakurity which provides penetration testing and code audit services to clients worldwide. The lion’s share of Homakov’s income comes from consulting, with some additional income via bug bounties (including a $4,000 payout from GitHub earlier this year).

Fame or infamy

Although he admits that he knew little about security before the 2012 GitHub hack, Homakov instantly became a polarizing figure. His action was lauded by some who believed the high profile exposure of the vulnerability would benefit the community by raising awareness for other Rails users. Others felt a more private notification would have been more appropriate, not to mention GitHub’s clear responsible disclosure policy in the terms of service. Supporters saw him as some populist hero sparring the Rails elite, while detractors resorted to mocking his broken English and even criticizing his profile photos. Those on both sides surely realized that he could have chosen the black hat route and done something much more malicious with the Rails repo and any others, and could have done so anonymously.

Some soon discovered that Homakov had indeed opened an issue about the mass assignment vulnerability, and only went public when he felt his warning had fallen on deaf ears. Homakov later regretted much of his behavior, and eventually provided a brief public apology to both GitHub and the Rails team. It’s not much of a stretch to imagine that GitHub’s bug bounty program launched earlier this year was at least partially influenced by their highly public experience with Homakov.

The most interesting man in tech?

Since leaving Russia, Homakov has become a world traveler. His Tumblr feed reads like a poorly edited and NSFW Frommer’s guide, chock full of selfies and commentary on the livability and food/drink from locations throughout Europe, the United States, and southeast Asia. Sofia, St. Petersburg, Barcelona, Istanbul, New York, Shanghai, and Seoul – all while earning a living and developing a reputation in the security space.

From his writing it is clear that he has an affinity for Asian culture, bright city lights, and beer (not necessarily in that order), while showing no affection for his country of birth. After about a year on the road, Homakov finally settled in Thailand, where he intends on living for a year before picking up for more travel on the spots he has missed on his first world tour. India, Africa, and South America are on the agenda.

He seems pretty funny too. His Twitter feed is peppered with various self-deprecating third person references as well as little gems like this…

joketweet

And now that he’s showing maturity…

joke2… he seems to have the ear of at least some in the industry.

atwood

Although much of his security research is unpaid and he is far from wealthy, it’s been quite a trip so far. From $30 to $300 an hour, and from Russia to Bangkok with plenty of stops in between – all in two years. He admits he acted irresponsibly, but now calls himself white hat and takes responsible disclosure seriously. As someone who first arrived to the security field conspicuously, Homakov continues to strive for increased credibility and legitimacy from peers in the industry. For many, his work will speak for itself. As he now approaches his 21st birthday, one has to wonder what his future hold.

 

Author’s Note: This article is a departure from Job Tips For Geeks normal content, but I see value in profiling technologists who have unique careers. I hope to profile others with non-traditional backgrounds and career paths. Feel free to contact me if you feel you fit into this category.

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?

How To Succeed in Software Without a CS Degree

This week I was approached by two individuals seeking advice on finding employment in a programming capacity, yet both lacked the traditional standard requirement for entry-level positions – the BS in CS (‘BSCS’). I get asked about entering the industry often, and each scenario has a unique wrinkle.

The most recent candidates were a fresh Ivy League liberal arts grad and a Physics Ph.D. The former had brief hobbyist programming experience and the latter gained light exposure during school. Both are immediately employable in other industries, but perhaps not in the field they now target.

Of course, both may still be able to earn a BSCS (or MS) and take the traditional route. For our purposes here, let’s take that option off the table. For a Ph.D., the thought of additional classes might be hard to swallow, while costs might serve as a barrier for many others.

Non-BSCS candidates are often at a distinct disadvantage when competing with BSCS grads for entry-level positions. It’s becoming more common for CS grads to enter the workforce with multiple internships and code samples to bolster their candidacy. It’s reasonable to assume that typical non-BSCS grads have nothing comparable, in addition to what may be considered a less attractive degree.

One important point to remember is once you’re in you’re in, meaning that the most difficult job search for non-BSCS grads should be the first one. After gaining a bit of experience, your risk factor subsides (assuming you didn’t perform horribly in your first job). After three years no one cares about your major, and after five no one cares about your degree.

What are the common approaches for a non-BSCS grad to break in?

DIY and self-study (AKA GitHub, apps, certifications, blogs, and sites) – This method is based on the philosophy that you get a shot if you have a body of work. The wealth of freely available resources makes this method attractive to both the confident and the frugal. There can be a fine line between rigorous code immersion and post-graduation idling, so it’s helpful to set tangible goals, a schedule, and practice self-discipline.

When given no direction on what to build, people usually struggle to find projects ideas. Look for suggestions like those on Martyr2’s Project list, and improvise. As for reading material, there are extensive lists of free programming books that may be helpful. All the material you need is out there and easy to find.

Bootcamps – Any conversation today about breaking in for the non-BSCS will include bootcamps, and I have mentioned thoughts on them before. Bootcamps may be regarded as a compromise, where the investment of both time and money rests between DIY and degree programs. Some view bootcamps as an accelerated BSCS, or a hybrid internship and apprenticeship with classwork included. Most bootcamps appear as preparatory schools for startups based on the skill focus and instructors. Do your homework, and use caution when discussing the value of bootcamp experience versus degrees to avoid insulting employers.

Internships, or cheap/free labor – Some organizations (think small businesses and non-profits) will let a non-BSCS perform development tasks as an intern or volunteer. This can be a clear ‘win-win’, as the organization gets productivity while you get somewhat valuable real-world experience. A combination of volunteer or internship and personal projects starts to level the playing field for a non-BSCS.

Training in – There are companies that hire non-BSCS for entry-level programming jobs, and the first months include corporate training programs designed for non-CS grads. The positions may pay less than entry-level programming jobs, with curriculum intended to produce effective employees instead of versatile engineers. For example, instruction could focus on proprietary technologies and frameworks instead of popular industry offerings.

What are some key items to consider?

Get out of the basement! – Some DIY’ers bury their head in code and books with no human interaction. Make community learning events and outside communication a part of your diet. This will help you measure your knowledge in a live setting while also providing the opportunity to make some industry contacts.

Don’t enter the job market too soon – For CS grads, the natural time to start the search is around graduation. No mystery there. For the non-BSCS, there is an instinctive rush to start applying to jobs early in order to take the temperature of the job market. Fight the urge. If you apply to a desirable company today and are subsequently deemed unready, don’t expect to be reconsidered in three months (when you are ready). Make sure you know enough to succeed in technical interviews, have your GitHub code clean and optimized, have any apps or sites tested and fully functional, and are prepared to make a strong impression.

Leverage the skills you have to acquire the ones you want – Bringing useful abilities and experience that can pay immediate dividends (no matter how small) to an employer mitigates their hiring risk. If you are able to contribute to an organization beyond just code, providing both a learning opportunity and a decent wage is easier for firms to justify.

Be realistic – Your three months of self-study or bootcamp are not likely to get you the dream job at Google. Be willing to start towards the bottom and pay your dues to move up.

Beware certifications – When faced with a choice of proving abilities with either code or certifications, always pick code. Many industry pros attach a stigma to those who focus on getting certified instead of just doing.

Make learning opportunity your #1 job search criteria for first jobs – The money will come. Trust me. If provided multiple job opportunities simultaneously, opting for a job due to an extra $2K or a commuting difference of five miles will be regretted. Find a place where you can learn and grow.

For more tips on job search for software professionals, see Job Tips For Geeks archives or my book.