Every year, thousands of professionals in various lines of work look to the programming world as a promising new employment option. Just in the past few months, I have spoken to attorneys, accountants, salespeople, and even a former professional athlete trying to land their first paying gigs in the industry. This isn’t the first time we’ve seen this.
A brief history lesson and cautionary tale
During the initial dot com boom of the late 90′s, millions scrambled to enter the technology industry. Naturally, some entrepreneurs looking to cash in on the movement developed accelerated training programs and boot camps designed to quickly convert blue collar workers into earning members of the IT industry. These classes and certifications were not cheap, but they usually cited high placement rates (and in some cases guarantees) and salary data for graduates.
Early on, the training programs typically had barriers to entry. Entrance exams and interviews left the least qualified applicants on the outside looking in. Time commitments made juggling a full-time job and a training program challenging for many, while cost made these programs inaccessible for others.
As you might expect, training programs with lowered admission standards and reduced prices arrived on the scene. Financial aid was made available, lecture times were adjusted to accommodate almost any schedule, and marketers flooded TV/radio/newspapers with anecdotes of auto mechanics and dental hygienists now earning double in the IT field. When qualified instructors were not available, classes were led by recent graduates who did not find employment.
Much of this training was geared towards obtaining a certification known as the MCSE (Microsoft Certified Systems Engineer), which was primarily a qualification towards Windows admin roles or desktop support. Even today, Microsoft has marketing material live on their site touting the value of these certifications.
The early graduates of the first programs probably did have high employment rates. However, the rise of the MCSE factories created a new class of applicant dubbed the Paper MCSE, defined as someone with no experience that was just able to pass the test. The MCSE certification quickly became associated with a type of get rich quick mentality, and having the letters next to your name was less indicative of knowledge and more likely someone trying to game the system.
If this story doesn’t sound at least a bit familiar, it should. Back then the message was ‘learn computers’, but now everyone from the President to Shakira (not to mention Ashton Kutcher and NFL legend Warren Sapp?) is telling us we now need to learn how to code. Today’s career changer isn’t trying to simply fill what are generally considered less glamorous jobs like help desk, but rather they want to be like those (pardon the silliness) rock stars and ninjas that they read about who are higher up the food chain.
Programming boot camps and the availability of MOOC’s has again taken learning of in-demand skills to the masses, and (regardless of your opinion on their value) the emergence of these programs impacts the hiring landscape for everyone. For now, most of these programs have some admissions criteria and may be affiliated as feeders to recruiting or consulting firms. Unlike their predecessors, the programs often boast that graduates will network with industry veterans and leave with real-world contacts to leverage in their job search.
Although it’s far too early to see how these graduates will do over time, history and basic economics indicate that new programs of reduced quality will emerge.
The difference between then and now
The major difference between the MCSE gold rush and the recent development-focused trend is that today’s career changer is often expected (and hopefully able) to demonstrate proof of their credentials. Graduates of boot camps are often very quick to point out that the classes were rigorous, had low program acceptance levels, required hours beyond typical full-time jobs, and that they built professional-grade applications before graduation. In almost every case where I’ve encountered a boot camp grad, these topics were brought up immediately by the job seeker. If the reputations of these programs become overwhelmingly positive (I’d now say they are no worse than lukewarm now), grads should become much less defensive as to the value of their education.
Being accepted into a help desk job today without experience or a relevant degree is one thing, but how willing will the programming community be to view these graduates as one of their own? This is more daunting when you consider that the community is considered to be protective of their craft’s reputation, and are sometimes known for being less-than-welcoming to their own. Will employers value the more hands-on approach of a three month boot camp over traditional lecture-based four year CS degree programs?
Keys to success
Whether you graduated from a boot camp or a four year program, I think the expectations for most new hires are similar. Employers probably won’t be expecting boot camp grads to be committing code any sooner or later than a BS in CS, and it is expected that there is inherent risk for any hire (particularly any hire without experience). There is some leap of faith for managers trying to evaluate someone for their first industry position.
For boot camp grads specifically,
You’re not being hired because of your boot camp app. Although your code portfolio may help you some, in a few years you’ll realize your app looks like it was coded by someone who learned Ruby in three months. Don’t overstate the importance or relevance of whatever app you built – it’s incredibly impressive to you because you don’t know better (yet). You are being hired almost exclusively on your perceived potential, not weeks of work.
You’re being groomed to work at startups and smaller firms. At this point HR representatives at most large firms will be less open-minded to you than to CS grads. Don’t take that personally because it’s really not about you, and big shops probably aren’t who you are trying to attract anyway. Your instructors likely came from startups, are teaching development as is done in typical startup environments, and the technologies taught are of a common startup stack. Your job search time is best spent focusing first on the firms that have a relationship with your program, and then other startups.
Your non-programming intangibles are just as relevant as the boot camp. Employers know that you can’t become highly productive in programming with a few hundred hours of learning. Conveying the smart and gets things done attribute is still the most important factor. You are still considered a risky hire, and if you are perceived as potentially damaging to the team dynamic you will be passed over for someone less risky.
Use caution if comparing boot camps to CS degrees. The two are vastly different, both with advantages and disadvantages. The quality and quantity of time for each are difficult to compare, and those that invested four years are more likely to be swayed by your knowledge than by diminishing the value of their degree.
To both CS and boot camp grads,
You’re not an expert. In my experience, the word expert gets bandied about more often among the inexperienced with something to prove than it does by industry vets with project history. Expertise takes time. Once you’ve been in the business a few years, you will meet people who know twice as much as you do yet still consider themselves novices. Whether in interviews or on résumés, choose your words very carefully to prevent the appearance of overconfidence (and to prevent what seems an open invitation for technical grilling).
You’ll do best if you show respect to the industry veterans. The people you are interviewing with have likely paid their dues during times when learning and information wasn’t as readily available. It’s probably difficult to envision being a programmer in 2001, where those in the field had far fewer tools or resources. They probably think you’ve had it easier in a lot of ways (and harder in others), so temper confidence with some humility.
Job Tips For Geeks: The Job Search DRM-free ebook reduced to $6.99 for the holidays. A great gift for the tech pro in your life, or for the annoying co-worker that you wish would find a new job.
Anyone involved with hiring entry-level technology professionals (or reads posts on Reddit’s cscareerquestions forum) is aware that students are being prepared by schools for how to do work in the industry, but are often ill-prepared on how to find work in the industry. There is a major difference between the two, and many grads are being edged out on jobs by equally or even less-qualified peers who were just a bit more proactive about their career. If you think finding a job is only about internships and GPAs, please keep reading.
Some students feel that if they aren’t working 10 hours a day building the next Twitter from their dorm room, or if they didn’t intern at Google or Amazon, that they will struggle to find work. This is hardly the case, and I assure you that if you do a few things during your college years (that require a minimal time investment and no money), you will be several steps ahead when it is time to apply for your first job.
Many new entrants to today’s technology job market are obsessed with the handful of high-profile companies that set the trends in the industry, and the next generation of software engineers seem to think that the only companies worth working for are Google, Microsoft, Apple, Facebook, Yahoo, Twitter, and Amazon. Software development has become both a celebrity culture (where companies and their CEOs are the stars) and an oligarchy in the eyes of recent graduates and teens, who set their sights on employment with this small number of firms. Young developers in foreign countries appear to be particularly susceptible to this hyperfocus on a tiny segment of the hiring market. If you don’t know how widespread this is, I’d suggest a visit to Reddit’s CS Career Questions section to see what people are asking.
When Yahoo changed their remote work policy the web exploded in debate around the value of remote employees, and the more recent news around Google dismissing GPAs, test scores and answers to Fermi questions made many tech companies reconsider their hiring procedures. Not a day passes where a piece on one of these companies doesn’t hit the front page of most major news sites. A cottage industry has erupted with authors and speakers providing guides for aspiring engineers to create résumés, land interviews and answer technical questions to get jobs specifically at these companies. The focus seems to be less about becoming skilled and more about being attractive to a specific subset of employers.
These companies are glamorized amongst budding engineers much like Ivy League and top-tier schools are with high school students, and the reason you probably won’t work for Google is the same reason you probably didn’t go to MIT. Because they are highly selective, and they simply can’t hire everyone.
Of course some of you can and perhaps will work for Google and the other companies listed here, just as some of you may have attended top universities. But the majority of
you us won’t – and that’s OK. Follow your dreams, but be realistic about the outcome.
So here comes the good news! Beyond Google, Microsoft, Apple, Facebook, Twitter, Yahoo and Amazon, there are hundreds of awesome places to work that are highly regarded by engineers the world over, and most people outside the industry (and many inside) haven’t heard of most of them. Experience with these shops, much like the above list, will get you noticed. Companies like Netflix, LinkedIn, Salesforce, eBay and GitHub are well-known but not typically mentioned in the same breath as the top celebrity firms, though they certainly could be. I’d venture that most college CS majors haven’t even heard of 37signals or Typesafe, where smaller teams are doing work that is regularly recognized by the engineering community.
And again the bad news. You probably won’t work for these companies either. For most of the world, these are still reach schools that employ relatively few. Although they may not be held by the general public in the same esteem as that list up top, they are incredibly selective, and most in the industry will view the difference between this group and the Googles as incredibly slim.
And now for some more good news. Beyond the lists of companies above are thousands of great places to work that I guarantee you have never heard of. These may consist of startups that fly under the radar or smaller specialized technology companies that serve a niche market. They could be the development groups for major banks or 25 year old mom and pop shops that have an established customer base and solid revenues. Game developers, ecommerce sites, consulting firms, robotics – the list goes on.
In almost every city, this group is the one that employs the overwhelming majority of engineers. This is where most of us will likely end up – a company that you will surely need to describe and explain to your parents and significant other.
In the city where I focus my business (Philadelphia) and run our Java Users’ Group, we have some Googlers and I’ve known engineers who have worked for Amazon, Yahoo, and Apple. And I know many many others who either turned down offers or likely could have joined those companies, but chose instead to work somewhere else. Just as some students may reject the offer from the top-rated school to stay closer to home or to accept a more attractive scholarship package, many of the world’s top engineers simply don’t work for Google or Facebook, or anywhere else in the Valley for that matter.
Philadelphia is by no means Silicon Valley, yet there is a fairly robust startup scene and a large number of software shops that are doing valuable work. Over the past 15 years I’ve worked with hundreds of Philly companies to hire engineering talent, and 99% of these places would be unknown to the typical developer. I almost always have to describe my clients to potential candidates, as most of these shops have not built a reputation yet, and these are firms ranging from 20 to perhaps 20,000 employees. And the vast majority of them are great environments for technologists where developers work alongside at least a few top engineers that could (and some that did) pass the entrance requirements for the Googles and Facebooks of the world.
All the great engineers in the world aren’t in the Valley, and they don’t all work for Google. This fact is obvious to most, but fewer than I’d expected and hoped. If that is the goal, go after it. The rest of us will be here if it doesn’t work out.
Job Tips For GEEKS: The Job Search DRM-free ebook is available for
$9.99 (reduced to $6.99 in December 2013) – more info here.
In August 2012 I published a blog post Why You Didn’t Get The Interview, which received a good bit of attention from readers and was republished a few times (most notably by Lifehacker). Of course one article could not list every possible explanation that an employer or recruiter might use to discard a résumé, so I decided to revisit the topic once again. This is not intended to be a comprehensive list, but rather an addendum to the previous post that may help explain a lack of response to your job search.
No submittal content - Online applications often consist of several fields and check boxes that don’t always give job seekers an opportunity to express interest or differentiate themselves. However, when you send a résumé via email or are provided some space within an online application to craft a custom message, you are foolish not to take advantage. Simply sending a résumé without any supporting information about your experience or interest in the job comes across as lazy or aloof, and can give the appearance that a job seeker is simply blasting résumés indiscriminately (perhaps even in an automated fashion). SOLUTION: Tell the employer at least one or two things that drew your attention to the job and company.
Multiple applications to the same employer for vastly different roles – Sometimes I will open my inbox and find an email from a job seeker about one job that could possibly be a fit, and then find another four or five emails from the same applicant for other jobs that are not remotely connected to the candidate’s experience. This applicant may have received some attention if he/she only sent the one semi-targeted application, but the additional blind stabs have too many negative implications. It typically signifies either a lack of self-awareness regarding qualifications, immaturity, or desperation. SOLUTION: Before submitting your résumé, check several of the company’s listings to make sure that you are applying for the one or two jobs that best fit your experience and goals. If you have a strong desire to work for a specific employer, sending a targeted application to one or two listings is much more effective than spamming your résumé to all of their vacant slots.
Many small red flags – My original article last year referenced 14 fairly obvious reasons that job seekers are not interviewed, but often it’s not that simple. Many times a résumé/application package will contain a handful of items that would not be a problem when considered individually, but when combined add up to a rejection. The recruiter or hiring manager will feel that too many special circumstances would have to occur that make the candidate’s hire unlikely. Perhaps a candidate has a slightly elevated salary expectation, requires relocation assistance, is minimally qualified, and lacks any easily identifiable positive indicators of talent or ability that stand out from others. An applicant with only one of those characteristics would likely be considered, but the aggregate picture makes it too much of a longshot. SOLUTION: There is no real fix to this. You could always try to explain what could be perceived as a red flag. For example, if you are relocating to a specific area, make it clear why you are looking in that specific market to avoid being viewed as someone open to jobs worldwide. Displaying some level of interest or passion for the employer could also help overcome objections and get you a shot.
Personal reputation and your employer’s reputation – It shouldn’t surprise anyone that if you apply to firms where people either know you or are connected to those that do, a decision to interview will typically be based on how these contacts feel and talk about you. However, your employer’s reputation may also come into play here as well. If a particular company has interviewed multiple former employees of your firm without much success, chances are they will not waste time interviewing another. As a recruiter, it is fairly common for companies to tell me “Unless they are outstanding I’m not overly interested in candidates from COMPANY, as we see many and have not had any luck.” Your company’s reputation is more likely to work in your favor if you are employed by a firm known for having talent, but it seems the trend to discriminate against employees of certain shops continues. I wrote about this a bit in a past post regarding discrimination by startups against workers from large enterprises. SOLUTION: Keep your personal reputation in mind when dealing with co-workers and particularly when leaving jobs. Minimize stints at employers that have a negative reputation in your market.
Inconsistency - This can be the result of discrepancies between a résumé and cover letter/application, between a résumé and LinkedIn profile, or just something fishy in the résumé itself. If you changed professions more often than Barbie (impressive list) or have travailed up the corporate ladder and come back down multiple times, your application will raise suspicions. Candidates that list titles progressing from CTO to CEO and then down to Junior Developer will be scrutinized. SOLUTION: There isn’t anything you can do to change the past, but explanations could go a long way if you left an industry to pursue a passion. Make sure all of your online profiles match your résumé details before sending applications. Try to use job titles that reflected your actual duties if you worked for a small firm and had an inflated title. Even if you were CEO or CTO of your dorm room software company, it may not be helpful to list the job that way.
“Meh“ – Your qualifications and history are virtually identical to the others in the stack of résumés received. You may have met what was listed on the job spec, but so did everybody else. This is of particular importance for jobs where it is expected that most applicants will have similar qualifications, such as entry-level positions for new graduates or jobs that list highly generic specifications. SOLUTION: There has to be something different about you that you can add to give some positive spin to your candidacy. Review the requirement again and try to find an area where your background exceeds the expectation, or a specific experience you have that others probably don’t.
My ebook Job Tips For GEEKS: The Job Search was recently released and is available for
$9.99 (reduced to $6.99 in December 2013) on iTunes, Amazon, Barnes and Noble, Google Play, and Kobo. I can provide a PDF version for sale by request.
I’ve recently seen a spate of engineers declaring boredom and/or dissatisfaction with their current roles and responsibilities, which leads them to openly question what options are available. Perhaps building accounting software products or maintaining the web presence of an insurance firm just isn’t inspiring you to get out of bed anymore. This problem isn’t unique to the software industry (and based on a 2003 Joel On Software post, not necessarily new), but whenever a professional invests years of their life getting an education and honing their skills, it can be daunting to think that the time was somewhat wasted.
Thankfully, if you are losing your passion for typical web or software development, your training and experience have at least in part prepared you for several alternative roles that perhaps you have not considered. It seems that frustrated developers tend to weigh their options as stay in development or leave the industry, without considering the fact that these other alternatives exist. If the source of discontentment is tied to the role of app or web dev work (and not the overall tech industry), there are some relatively new roles that have become more in demand that may satisfy the itch you have.
This information may also be useful to new entrants into the market and grads that are wondering what they can do with their computer science degree other than just stereotypical development roles.
Here are some examples (some have crossover and similarity):
Performance Engineer - This role isn’t about building a product, but rather improving speed, scalability and reliability. Performance engineers may be thinking about databases or monitoring tools one day and hardware or operating systems the next. It is a highly technical and specialized role with increasing market demand.
QA Automation Engineer – QA is one discipline that seems to have gone through some significant changes over the course of my career (15 years). In the late 90′s, QA meant large teams of manual testers and high demand mostly attributed to the Y2K scare (history lesson for the young). At some point thereafter it became the norm to outsource QA overseas, making QA a lost art in the US and thus making QA talent significantly harder to find. Over the past couple years, there seems to be some resurgence of demand for QA to be performed domestically, and hires typically will be expected to have some automation and scripting experience.
DevOps Engineer – This is another role that has been growing due to the number of shops that like to deploy frequently. As the trend in delivery will not be changing anytime soon, the ability to automate the process will continue to be in demand.
Configuration, Release, or Build Manager/Engineer – As the look of development teams has progressed from crowded shops to remote employees, combined with the popularity of cloud-based computing, the concept of configuration management is changing. Demand for talent in these areas is relatively steady.
Embedded Systems and Firmware Engineer – Although the transition from your typical app or web developer position may be a bit more complex, one should expect growth in embedded systems to continue as the variety and sheer number of devices continues to increase. The concepts of ubiquitous computing and the Internet of Things are getting one step closer to reality every day, and engineering talent with a unique set of skills will be required.
Project Manager, Technical Writer, Business Analyst – Having a coding background can make the move into any of these jobs a bit easier, and your appreciation for development should maximize your shot at being successful.
Before abandoning the years you have invested in learning how to code, consider whether or not you may be happy in a different role that enables you to reuse many of the skills you have already developed.
My ebook Job Tips For Geeks: The Job Search has been released and is now available in most formats. See the book page for details.
Generally speaking, when you walk into an interview you are at the mercy of the interviewers. Although you may be given some general information regarding the interview format and probably have an idea about the questions or exercises you may encounter, there are endless possibilities on the topics you may be asked about over a two or three hour session.
As was stated before, any item on your résumé is fair game, so one way to potentially avoid queries on unfamiliar topics is to keep those words off your résumé. Regardless of what is or isn’t on your résumé, it is quite likely that you will be asked questions pertaining to subjects that are not within your areas of expertise. Trying to fully eliminate the exposure of certain vulnerabilities is an exercise in futility, but there is one rather effective method to at least attempt to mitigate the risks.
There is an increasing trend in the technical hiring world for employers to request firm evidence of a candidate’s abilities that go beyond what a traditional résumé includes. For programmers, this typically can be achieved through a code sample. Front-end designers and developers may be expected to show off some UI or website that they built, and architects may be asked to share documents. Mobile developers may hear this more than any other group, and are routinely asked “Do you have any apps available?” as part of the vetting process.
One way to partially control the content and direction of your interview is to provide interviewers a work sample that will presumably become a point of discussion. This will turn what could be a technical interrogation into a version of show and tell. Even if the exchange about your sample only takes fifteen minutes, that is fifteen minutes of the interview where you hopefully will shine, and it is fifteen minutes less time for the interviewers to delve into other topics that are probably less familiar.
To employ this tactic, be sure to make it known at some point early in the process that you have samples of your work for review by request. A GitHub link at the top of your résumé, a URL to download your mobile app, or a link to sites that you developed are much more graceful than large file attachments. You can choose to extend an invitation to view these projects as early as your résumé submission, and when scheduling the interview you can express your willingness to discuss the projects in more detail and offer to bring a laptop with samples.
Independently volunteering to show representations of what you have produced will give an employer the impression that you are both willing and able to demonstrate the quality of your work. That act makes the applicant appear more open and trustworthy than someone who hesitates when asked for some samples. Recruiters and hiring managers alike will welcome résumé submissions that are accompanied by additional supporting evidence of a candidate’s abilities.
When you enter the interview, you can mention that you brought samples to show if the team is interested in seeing your work. This will typically be received quite positively and could lead to a deep dive into familiar territory.
This post is an excerpt from the recently released ebook Job Tips For GEEKS: The Job Search, available to purchase from iTunes iBookstore, Amazon, Barnes and Noble, Smashwords, and (soon?) Kobobooks. A sample from the iBook in PDF format can be found here.
Lately I’ve seen quite a few requests for advice from younger programmers, asking questions either directly to me or in public forums about a career decision they are being faced with that is causing some level of stress. Reddit’s r/cscareerquestions is a hotbed for this type of activity, and you might see the occasional similar post on Hacker News. After 15 years in business, I’m quite comfortabel providing insight on the potential benefits and drawbacks of say, taking a job doing mostly Python versus a position exclusively using a rarely seen proprietary language and platform, or accepting a pure technical management position versus staying more hands-on.
Generally, I want to tell all these people the same thing. If you really enjoy the work and want to be successful in the business for a long time, you should try to make decisions, think like, and become an engineer’s engineer.
I know quite a few people I’d describe as an engineer’s engineer, and most of them have some gray hairs or are young but sound like a throwback to times past. Fortunately, some less experienced developers are benefitting from being able to work alongside someone in this category, who are more often that not open to mentoring and showing the way. As a recruiter I look at and treat these engineers like gold, as they are the types that any of my clients would want to hire – plus they tend to teach me new stuff in every conversation.
Who is the engineer’s engineer?
- Utility player – In baseball, it wasn’t uncommon in the early years for players to play several positions. Specialization has happened in baseball to the point where there are now pitchers who only pitch in the 9th inning. Similarly, software development shops are now often filled with segmented roles for build engineers, dev ops, QA, architects, performance engineers, database developers, etc. The engineer’s engineer is a utility player that can jump in almost anywhere, and doesn’t see the demarcation as a boundary that cannot be crossed. Little is considered beyond the scope, and they will not want to silo themselves into a singular function.
- Initiative – If they see something that is broken, they fix it. Will automating a task make our lives easier? If so, let’s do it, and only ask permission when absolutely necessary. This requires some level of autonomy.
- Technical integrity – By this I mean that an engineer’s engineer will have some opinions about decisions being made (if this person isn’t calling the shots) and will make that opinion known when there is disagreement. Instead of just saying an idea is bad, an alternate solution will be given. This is the desire to do things correctly over taking short cuts, which is likely to conflict with the business at times.
- Can’t be bought with money or title – This group will never take a job purely based on salary or rate, and are driven by the ability to solve interesting problems and work with a strong team. Job title means absolutely nothing. In my experience, most engineers factor money heavily in job decisions and sacrifice a better career move or additional job satisfaction for what amounts to a difference of $2.00 an hour. If you’ve chosen a job based on a 5K salary difference, this is you.
- Sharing - The engineer’s engineer wants to share, whether it be information on how and why they arrived at a particular solution, their favorite tools, or anecdotes about past projects. This is based on a combination of pride in their work and interest in teaching others. Open source is often a part of this equation, where there is a desire to share your solution for the outside world to see and use.
- No limitations - The engineer’s engineer doesn’t want to have the toolset options defined and thrives in an environment where they have autonomy over what will be on their machine. Having a company mandated IDE or OS will be a turn-off, as will any roadmap listing few acceptable tech options. Heavy bureaucracy, regulation, or barriers to being able to solve problems are an issue. The shop ideally will be engineering-friendly.
- No personality conflict, less ego – Of course, many strong programmers (and some weak ones) have quite a bit of ego about what they do. The engineer’s engineer does not come across as overly self-important, and can be more humble than those much less-skilled. This group isn’t alway the most friendly or popular person on the team, but is never the most hated.
- Movement – This group wants things to be progressively moving forward with few delays. Low latency in their process and little downtime at work.
- Has the back of team members – Solidarity among other engineers is their goal, and they tend to stay above or away from the drama of interoffice politics. They are there to solve technical problems, and have no interest in gossip or attacks on others.
- Know that they are not their code – These people can separate a technical criticism from a personal attack.
- Doesn’t need to be a leader – They are often more happy when they are not in charge, and are not instinctively driven to tell others what to do.
Note: In thinking about and doing some mid-article research for this piece, I came across Paul Graham’s 2004 piece Great Hackers which identifies some of the same traits listed here as being shared with hackers. The hackers he describes should share the workplace desires and drive as the engineer’s engineer, but may not always have the same personality or behavioral traits.