Category: CS Careers
The “Big 4”, GitHub, Bootcamps, and Rants – Conversations Overheard From the Kids’ Table
I’ve been on Reddit for the past few years, mostly giving advice in a subreddit (or “sub”) called CS Career Questions. The participants run the gamut of technologists, and on any given day you can see questions from high school sophomores asking which math class would better prepare them for a programming career to programmers in their fifties seeking input on how to keep skills fresh.
After participating in /r/cscareerquestions for about a year and doing a couple popular AMAs, I was asked to be a moderator. Mods have the enviable job of keeping content on topic, deleting offensive comments, and banning users (not to mention bots) who don’t play nice. As a mod, I’m now obligated to pay closer attention to the activity in the sub.
I thought I’d share some observations on what I’ve noticed over the years, which may shed light on the thoughts of at least some in the next generation of engineers.
The Big 4, the Second Tier, and The Untouchables – When I entered tech in the late 90’s, the Big 5 was shorthand for the accounting firms (Price Waterhouse, KPMG, etc.) that had branched into tech consulting. Today the term Big 4 is used to signify the companies deemed to be the most select in the industry, and consists of some mix of Google, Facebook, Microsoft, Amazon, and Apple. Every college student seems to aspire to work for one of these.
Then there is a second tier of companies that are considered a half step down. Names in this tier tend to be newer companies like Palantir, Twitter, Netflix, SpaceX, LinkedIn, and perhaps one or two dozen other companies that most in technology will recognize.
If you listen to the conversations happening, these groups are the only acceptable employers to target. The second tier, which most in the industry would consider “elite” employers, are sometimes considered a fallback. Highly-selective firms have become safety schools, and many of these students don’t realize that the chances of being hired by even the second tier is not realistic for most of the population.
Industry veterans realize that most won’t end up in these 30 or so companies, but instead will work for companies their parents and peers won’t recognize. There is nothing wrong with aspirations, but it’s a problem when a high percentage of graduates feel they’ve failed.
Language/Platform Fascination – Because the group knows I recruit engineers for startups, I get many private messages asking me “Should I learn Node.js or Android?” or “Which pays more, Python or Ruby?“. I’m generally reluctant to try and answer these questions without some additional context. New engineers may not realize that they probably won’t be using the same tools or languages in five or ten years and how quickly supply and demand can change.
Self-learning, GitHub, and MOOCs – Many of the questions in the sub come from users who have a non-CS degree (or no degree) and are looking for a way into the industry. It reminds me of the push in the early 2000s for those without college degrees to get certifications in technology careers such as network administration or help desk. Today, programming is considered approachable.
The topic of self-learning comes from both those in the industry and those seeking entry. The value of personal projects is a constant conversation, although it’s hard to distinguish whether the newer engineers understand that the value of these projects should diminish as experience is gained. Bootcamps and MOOCs are relatively new concepts as methods to mint new engineers, and both seem to be considered as reasonable economic alternatives to a CS degree.
Recruiters, Resumes, and Networking – Based on the number of questions about recruiter interactions, resumes, etiquette, and professional networking, it seems universities might want to consider adding a course on these topics to the curriculum. Careers in technology have unique characteristics that are completely foreign to those outside the industry, and teaching some of these concepts before graduation would be helpful to students who clearly receive conflicting information from peers and family. Career advice for teachers and policemen isn’t applicable to technologists.
Expectations and Rants – When we have college graduates and rather inexperienced professionals being courted by multiple employers, it has the potential to create a class with unrealistically high expectations as to how they should be treated. If a recruiter from a Big 4 doesn’t reply to a job application or an email in a day or two, it isn’t unusual to see a rant. It’s a mix of legitimate complaints about industry hiring practices and concerns that they “heard during an interview that one engineer worked past 6PM” the night before.
How to Make More Money (and the plateau)
Most extended discussions about the technology industry and software engineering trade eventually find their way to the topics of worker supply and demand, talent shortages (real or otherwise), and compensation. Every Best Jobs of The Year list (examples here or here or here or here) features a Top 10 littered with assorted job titles given to those who code, often including salary data that could cause non-technical readers to regret life decisions.
New graduates entering the industry may receive multiple salary offers that dwarf those of non-coding classmates, and after five years on the job it might seem as if there is no limit on future earning potential.
The Plateau
What they probably don’t tell you in school or during your first few jobs is that most in the industry will hit a compensation plateau, where increases become smaller and less frequent. Market rate for skills increases with experience, but once a certain level of experience is reached the market rate flattens.
As an example, market rates for developers with 10 years of experience vs 15 years can be indistinguishable. Making lateral moves or even taking a pay cut in exchange for some potential asset (acquire a new skill or experience, equity, etc.) start to become best options.
The amount of time it can take to plateau varies. Someone who stays several years at one employer where small raises are standard may take 15 years to plateau, whereas someone changing employers with relative frequency or alternating between consulting and direct hire jobs may plateau early.
Ways to Earn More
When you’ve reached the plateau but have some need to earn more, there are a few methods to consider.
Move out – The most effective means to more compensation is still to get a job with a different company. This method usually becomes less effective at the plateau than it was earlier on, but there is almost always another company willing to pay at least a bit more.
Move up – Gaining more responsibility through an internal move should come with more salary. If the company is top-heavy or there is a line for advancement, moving both up and out may be necessary.
Ask – If money is the impetus for considering a change of any kind, why not ask your current employer first? If the answer is ‘no‘ now, they may become more cooperative when you have other offers in hand (not that I’m suggesting counteroffer as a sound strategy).
Branding your additional benefits – Professionals with similar accomplishments and years of experience appear homogenous and plateau. In addition to the productivity and ability that comes with years, are there other benefits that an employer receives by hiring you? Candidates with higher public profiles due to community involvement, such as Meetup leaders or conference presenters, may command a higher salary due to the increased visibility or prestige that their hire would provide a company. Candidates that are likely to be followed to a new employer by a loyal network of talent might justify higher prices.
Consulting and contracting – Contractors and salaried employees of consulting firms both typically earn above market rate for direct hires. A move to contracting or a consultancy can be a sound strategy for those in traditional non-consulting direct hire jobs, but consultants and contractors will also plateau over time.
Moonlighting/revenue streams – Those that have some extra time might consider taking on off-hours remote contract work to increase earnings. Building and monetizing a product may result in additional dollars with minimal long-term time commitments.
Specialize – Becoming recognized as a specialist in a niche area may make it easier to command rates above market. Those specializing in the newest technologies may be able to take advantage of the fact that a market rate has not yet been established.
What Programming Language Should I Learn?
Several times a week I am asked by a contact/reader/someone on Reddit for advice on what they should learn next. The question comes from both junior and experienced programmers, and has been posed both as open-ended (“What should I learn?“) and multiple choice (“Python or Ruby?“, “Django or Flask?“, “iOS or Android?“, etc.).
Unless it is someone I’ve worked with, there is usually little (or no) accompanying information or context provided which makes any answer rather speculative. To respond with hard data on compensation figures or even an informed opinion regarding future demand for a skill may be helpful, but offering career advice blindly without any knowledge of the person borders on irresponsible.
The easy answer (the long view) is to just say that overall programming ability and knowledge are the most important factors in maximizing employability, and that languages and tools are mostly interchangeable for experienced professionals. “Any good engineer can learn a new language in n weeks/months” is commonly heard from those at the senior level. Whether this is true or not is debatable, but it still does not account for a multitude of factors that may make a particular language more favorable than another to an individual at any given time.
One needs to think of learning as a time investment, and investors need to consider maximizing ROI. Before deciding where to invest their time, it may be wise to research and evaluate some of the following.
- Programming experience and background – Those with little or no programming experience are usually pushed towards a few languages, with Python and Ruby the most popular among bootcamps and courses aimed at beginners. Experienced programmers that have a larger set of realistic options may consider how quickly a language might be picked up based on the paradigms and concepts that are already familiar. Build on what you know. Many Java developers were C++ refugees in the late 90’s, and Java pros of the past decade are venturing into Scala and Go.
- Availability of learning resources – People learn in different ways, so it’s important to first recognize their best learning method and then research what resources are available. Those who learn best by doing can find it challenging or expensive to find resources and tools for proprietary or highly-specialized languages. Classroom learning opportunities or books on emerging languages often don’t exist or may be cost prohibitive relative to common languages. Documentation and support for newer tools can be spotty or unreliable.
- Market supply and demand – If employability is the impetus for learning (as opposed to intellectual curiosity, boredom, etc.), both the current and projected supply and demand for talent is worth noting. Supply and demand are not necessarily universal trends and can vary based on geography and experience level. As an example, demand for entry-level Haskell talent is almost non-existent but rises significantly with experience. Searching for jobs specifically within desired geographic regions and doing research with a tool like Indeed’s Job Trends may provide some insight into both local and national data.
- Professional goals – What types of products do you want to work on? Those interested in gaming might benefit from different choices than those interested in web development or embedded systems. Do you measure job satisfaction by professional accomplishments or is compensation a bigger motivator? Certain industries pay better than others, and certain languages are more prevalent in those industries.
- Popularity and adoption trends – Learning an esoteric language that employers don’t use can be helpful in becoming a better overall engineer, but useless for putting food on the table. Trying to become reasonably productive in a language after hours can take time, and the adoption levels and/or popularity of a language could potentially change during the learning process. Researching current and historical data can be helpful. In addition to Indeed Trends, other sources include the ThoughtWorks Radar, RedMonk rankings, and the TIOBE Index. Always consider how the ratings are assembled, past performances to determine trends over time, and keep in mind that others may be using the same data to make decisions. Just because a language is “#1” today doesn’t mean it will be in a year, and identifying and prospecting underserved language camps experiencing high demand is one way to employability before the market supply catches up.
- Community or vendor support – Is there a community of people dedicated to keeping the language vibrant and relevant? Is the language supported by a vendor in good standing, or are the stewards of the language in a poor position to continue? Regarding community, Raganwald tweeted this back in February and it resonated.
What did I miss?
Career Stagnation – Early Detection and Treatment
Have you ever been on LinkedIn and stumbled on one of their work anniversary announcements? In case you haven’t, they look something like this:
The announcements are generated by LinkedIn and typically followed by a predictable handful of likes, congratulatory words, and positive sentiments. I’m yet to see a comment that generally reflects my knee-jerk reaction to at least some of these posts.
Longevity and career stability obviously don’t have to be a bad thing, but I’ve seen far too many programmers become so comfortable in a job that they don’t bother to take a look outside to see what changes are going on outside of their bubble. When these professionals eventually decide to seek new employment, usually by way of some triggering event such as a layoff,they are usually stunned by how much the hiring landscape has changed since their last job search. This is a conversation I’ve had hundreds of times, where my role begins as educator (“JavaScript is actually pretty popular these days.”), morphs into advisor (“You might want to brush up your web skills.”), and eventually lands on crisis counselor (“It’s going to be OK.”).
Stagnation: How it happens
The formula for career stagnation is pretty simple. When one’s basic needs are met or even exceeded, they stay put. When provided with fair compensation, a tolerable work environment, and a comfortable chair, many technologists go about their work without finding the need to pay much attention to trends in the industry that don’t affect them. In an industry that changes rapidly, the result is marketability problems.
For some in our field, new challenges, learning, and change are basic needs. Even if these types are paid well and given other perks, they will be likely to investigate trends and possibly seek new employers. Their natural curiosity protects them from stagnation.
Managers hire technologists who possess the skills needed to perform jobs at their company, even if those skills are not in high demand on the overall job market. Those working for companies staying current with new tools and offering multiple challenging projects have no reason to fear the negative impact stagnation has on marketability. For those working in static environments with little change and a dependence on less popular or proprietary technologies, the burden of maintaining marketability is their own.
Avoidance, Detection, and Treatment
The biggest problem with stagnation is that technologists don’t realize it’s even an issue until it’s too late to remedy. Thankfully, there are ways to identify and treat this common problem.
- Diagnose – Set a reminder on your calendar to update your résumé and/or LinkedIn profile every six months. Are you able to add any projects or skills to your résumé? Are there any skills on your résumé that you no longer feel comfortable including for fear of being exposed as a fraud? How many six month periods have passed since you have been able to mark a significant accomplishment?
- Test – Send your résumé to a past co-worker – ideally someone who has been on the job market a bit – or a recruiter you trust, and ask if your current skills would get you interviewed. Make it clear that you aren’t actively seeking employment, but now are just interested in an assessment.
- Read and get out – Much of stagnation is related to technologists being insulated professionally and not paying attention to trends outside their offices. Reading technology blogs or article aggregators for as little as an hour per week will give you an idea if you are building marketable skills. Having any involvement with others in the industry that are not co-workers is perhaps the most valuable method of prevention. Some office environments may fall prey to groupthink and hive mind tendencies, so communication of any kind with the outside world is useful.
- If you aren’t getting it at work, get it at home – If your employer doesn’t provide you with the ability to work on challenging projects and relevant technologies, side projects are one solution if you have the time. Employers today tend to appreciate self-taught skills and impressive independent development efforts as much as on-the-job experience.
- Leave – Leaving your job doesn’t need to be the first solution to career stagnation, but for many it’s the most effective. When evaluating new employers, consider whether stagnation and marketability issues may arise again in the near future.
Marketability is a complex concept that depends upon several independent factors that are difficult to predict. Stagnation is easier to diagnose than it is to treat. Early detection is the key.
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.
How to Evaluate Job Offers
At some point in a career, many will be in a position to decide between multiple job offers from different companies – or at worst having to decide between accepting a new job or staying put. When starting to compare offers, it is common for the recipient to focus on the known quantities (i.e. salary, bonus, etc.) and perhaps a couple additional details that are generally considered more subjective (work environment, technologies).
In order to make a truly wise choice it is also useful to include less obvious factors as well as future considerations, as those generally will have a much stronger influence on career earnings and success. These are harder to predict, but must enter into your decision unless your sole objective is to meet some immediate short-term need.
The easy part
The most common components factoring into gross compensation are:
Cash compensation (salary, bonus, sign-on) – If the bonus is listed as guaranteed, the figure can be lumped into salary. Most bonuses are not guaranteed, but rather are tied to personal and/or company goals being met. Some firms or individual employees are willing to provide data on bonus history. Sign-ons are used to sweeten an offer or to rectify a potential cost the new hire would incur by leaving their job, such as an unpaid bonus.
Healthcare premiums and contributions – Offer letters typically do not list employee out-of-pocket insurance cost, and personal circumstances may weigh heavily on how one values health insurance. Employer contribution can vary from 50-100% while other companies offer employee-only contribution (no contribution towards spouse/partner/child), which can result in a total compensation difference of a few percent.
401k or retirement plans – Employee match and contribution to these plans can be significant. Consider both the dollar amounts and the vesting schedules.
Education reimbursement – If considering a return to school this policy could make a difference.
Paid time off – Although the real value any employee places on time off will vary, the dollar value of each day of PTO can be estimated using a formula.
(Annual salary / estimated annual work hours) x work hours in a day
Many candidates make the mistake of basing their decisions with too much weight placed on base salary. This may be attributed to our emotional attachment to numbers and compensation “milestones” (usually round numbers), the perception of status that results from salary, and the inability of candidates to accurately gather and calculate the details of a comprehensive package.
A friend might tell you about her 100K salary, but how often do you hear someone independently offer up that they pay 10K per year for health insurance and only get one week of vacation?
Additional considerations
The details above are all easily obtained, quantified, and require no interpretation. Everything from this point on will require a bit of investigation as well as some educated guessing.
Expected hours – To put a value on time for offer comparison, a quick calculation to convert salary into dollars per hour can be a telling figure. All else being equal, that 80K offer with a 40 hour work week is more per hour than the 100K offer at 55 hours. Estimates of work hours may not be accurate, so multiple data sources can help.
Commute time/cost and possibility for remote work – Distance may not be a reliable predictor of commute time or cost, and mundane details such as gas efficiency will quickly add up when you consider the trip is repeated 400+ times a year. Mass transit inefficiencies and delays have a cost to commuters as well. The ability to work remotely, even for one or two days a week, makes some difference.
Travel – This can be viewed as a positive or a negative depending on the worker. Consider any hidden expenses that may not be reimbursed, such as child or pet care costs.
Perks – Company provided phone or internet, gym membership, and office meals/snacks are not things job seekers expect, yet could provide thousands of dollars in value.
Self-improvement budget – Some companies may be willing to foot the bill for training or conferences that the employee would have paid for anyway.
Forecasting and speculation
The most vital characteristics contributing to a job’s long-term value are often hidden and unsupported by reliable data. Establishing the present day value of any one job is somewhat complex, and trying to forecast future values requires speculation.
Future marketability – This is a key factor in career compensation, yet is often overlooked when the temptation of short-term gains are presented. The consideration of future marketability is most critical for new grads or junior level employees, who are (unfortunately) often in debt and easily influenced by short-term gains and cash compensation. What skills will be obtained in a job, and to what extent will these new skills increase market value? Will having a company’s name on a résumé (whether by associated prestige or number of direct competitors) create some additional demand for services? If a goal is to maximize lifetime earnings, one could theorize that a year of unpaid work at a place like Google or Facebook is preferable to two years of paid work at many other companies.
Promotions and raises – Job offers only include starting salary/title. How, and how often, does a company evaluate employees for salary increases, and what amounts might be expected for performers? Do they tend to promote from within or hire from outside? Is there a career path and is there a point where compensation plateaus?
Stress and satisfaction – It’s impossible to place a hard value on work stress or job satisfaction, and the amount of either is difficult to predict. Satisfaction, work/life balance, and stress can impact both health and productivity, which could also contribute to marketability.
Stock/stock options – The number of factors that influence the potential value is too long to list. Vesting schedules may have substantial impact on perceived value if a long tenure isn’t expected.
Environment, team, management – Companies try to make a strong positive impression during interviews, but that image doesn’t always accurately reflect day-to-day operations. Younger workers should place considerable weight on whether there are team members to learn from and mentors who are both available and willing to guide. Employees with long tenures will have insight, though the opinion of more recent hires may be more relevant to anyone considering an offer.
Conclusions
Job change decisions are complex, and tough choices usually end up coming from the gut. The immediate results of a choice are easily identified and quantified, but the more important long-term ramifications require research, interpretation, and a bit of conjecture. When combining all of the smaller elements of a compensation package, the highest salary will not always be the most lucrative offer.
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.
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.
Job Tips For Geeks 