Last week I started training a new employee. I’ve been working solo for the past few years and hadn’t trained anyone recently, so having to thoroughly explain the fundamentals of my industry has helped reintroduce me to some concepts that I hadn’t thought about lately.
The training process got me thinking about the best speakers I’ve had in 15 years managing the Philadelphia Java Users Group, and how well some presenters were able to explain concepts that were entirely new to audiences. Even as someone who doesn’t write code at a high level, I left some presentations with a firm grasp of the concepts because of the speaker’s performance.
There were a handful of instances over the years where speakers volunteered to present a topic unfamiliar to them, adding that the task of creating a slide deck and preparing to answer audience questions was a good excuse for learning something new. These were situations where a speaker decided to learn a technology just so they could immediately teach it to others.
When I give advice on public forums like Reddit’s /r/cscareerquestions, in blog posts, or in private conversations, I typically encourage people to learn new technologies by building something they can then showcase to demonstrate proficiency to potential employers. I still feel this is sound advice, particularly for job seekers who may need a bit of extra material to get their credentials to the level of their peers.
I’ve never suggested that someone learn a technology with the end goal of then teaching it to someone else. Those who learn by building have a safety net in that they can “release” their demo when it’s ready. Studying a technology in order to teach it in a group setting usually provides a strict deadline, and also gives an added incentive with the desire to appear knowledgeable and professional during the presentation and Q&A that typically follows.
Next time you are looking to learn a new skill, consider lining yourself up to present to a local user group or even offer a company lunch and learn event. You may find the additional pressure may be the extra incentive you need to dive in.
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.
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.
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?
I was recently asked to answer a question on Quora about startups and stability, and as I read some of the other replies I noticed a trend. The question was basically “Would joining a startup be a mistake for someone with the goals of stability and career progression?”. The questioner then defined stability as being able to support a family and have nice things (financial stability).
The answers ranged from a flat-out “Yes” (i.e. “it’s a mistake“) to “startups provide no stability/career progression“, while another pointed out that most startups fail. The responses were familiar, and similar to objections I’ve received when pitching startups to software engineers over the past fifteen plus years.
Before answering, I considered the many I know who spent most of their careers at startups and small companies in comparison to the people who worked for larger shops. Have the ones that stuck with startups achieved less (or more) stability and/or career progression?
Stability vs Employability
Let’s consider Candidate A who has worked for ten years at one large company, most would say that shows job and career stability. After that length of time, we might assume (or hope for) some level of financial stability and at least a small increase in responsibility that could classify as career progression.
When presented Candidate B with experience at five startups over a ten year span, most conclude this demonstrates career instability or even “job hopping”. Without seeing job titles or any duties and accomplishments, it would be difficult to make any guesses about career progression, but many would assume that a series of relatively short stints might not allow for much forward movement.
Candidate A clearly has more career stability using traditional measures. However, Candidate B’s experience, at least in the tech world, is the somewhat new normal. Job security and career stability (marked by few job changes) is what professionals may have strived for historically, but now one could argue that employability is a much more important concept and goal to focus on.
Today, Candidate A’s company announced layoffs and Candidate B’s startup ran out of money. Who lands a job first? Who is more employable?
Startups Fail… But They’re (almost) Always Around
When job seekers voice concern about the stability of some software startup I’m pitching, I may cede that most startups will fail and the conversation may end there. I might even throw in a “Startups are risky“. These candidates are more concerned about job stability (the keeping of one job) than career stability (the ability to consistently have a job).
The fear is that a company will fail, and the candidate would then be a job seeker all over again with some frictional unemployment and the possibility of worse. Given the failure rate of startups, the fear of a company closing is rational. The fear of any sustained unemployment, at least for many startup veterans, probably is not.
Anecdotally, most of the people I know who gravitated towards small/new firms had little or no unemployment, and most appear to have at least the same levels of financial stability and career progression to those at larger firms. The only visible difference is usually that startup veterans had more companies listed on résumés, may have worked for and with some of the same people at different jobs, and some have a wider palette of technical skills. It’s reminiscent of a successful independent contractor’s background.
Once You’re In, You’re In
After the first startup boom/bust some in the industry tied company stability to career stability or employability, as if being associated with a failed startup might negatively impact future employment options. Many discovered the opposite was true, as those who failed were tagged startup veterans unlikely to repeat the same mistakes twice.
I would expect that those who have worked for multiple startups would likely tell outsiders this: “Once you’re in, you’re in“. Let me explain.
While any individual startup may not provide job stability, an ecosystem of startups will provide candidates with career stability and usually increased employability.
When startups hire, most seek those with previous startup experience. It’s usually right there in the job descriptions. Remember Candidates A and B from earlier? Candidate A hopefully has a shot at a startup job, but B already has an interview.
Due to the transient nature of startup employment and the trend of startup employees to stay within the startup ecosystem, the ability for those in the startup community to get introduced to new jobs via one’s network increases dramatically. When Startup X fails, the 50 employees migrate to perhaps 3o other startups. That gives Startup X alumni a host of employment possibilities, which should grow exponentially as additional startups rise and fall over time. In smaller cities one can become a known entity within the startup community, virtually guaranteeing employment for as long as startups exist and their reputation remains positive.
The concept of career stability has changed significantly as increased job movement has become an accepted industry characteristic. When one expects a higher number of job searches over the course of a career, proactive professionals will consider employability and marketability more carefully. Job security ≠ career security. If your main concern is being continuously employed at rising compensation levels, employability will often trump job security.
The concept of self-employment is appealing for many technologists, but the path to getting there isn’t always clear. Independent contractors may cite several attributes of their work that they find preferable to traditional employer/employee relationships. The allure of money is obvious, but independents may also be drawn to project variety, an emphasis on new development over maintaining existing projects, and additional control over work/life balance.
Independent contracting has historically been a trend primarily among the more senior and advanced in the profession, but today it’s not uncommon to hear intermediate or even junior level developers in pursuit of independent work. Often the decision to become an independent isn’t premeditated so much as it is circumstantial. A lucrative contract offer is hard to refuse, and once a new level of compensation and freedom is reached it is difficult to accept a return to lower salaries. These ‘accidental contractors’ sometimes find themselves wholly unprepared for what skills and knowledge are required to build and operate a sustainable business.
Many seem to think that technical strength is the difference. Technical skills are clearly part of the equation and in unique situations superior skills can trump everything else, but many strong developers have failed as independents. Those that are thinking about exploring the independent contractor lifestyle in the future should start considering the topics below well before signing any contracts.
Communication skills – Independents need the ability to acquire clients, either through direct interaction with the client or through a broker/recruiter. Once a client is made, maintaining their business will depend upon clear communications regarding expectations, schedules, delivery, etc. Using brokers can help those with communication or social skills issues.
Varied skill set / independent learning / research – A skills inventory with some variety (languages, tools, frameworks) is fairly common with successful contractors, although advertising an unrealistic variety will hurt credibility. Independents have more incentive to invest off-hours learning new skills and keeping an eye on trends in the industry.
Comfort with interview process – For those in the salaried employment world, one great interview can result in years of work. Depending on contract durations, independents can find themselves in some form of interview several times a year. Anyone hoping to be successful in contracting must overcome discomfort or anxiety in interview settings.
Relationships – Successful independents usually know (and are known to) a number of people spread across various employers. Senior level contractors may have developed hundreds of relationships over time without any targeted networking efforts, while younger entrants will likely need to reach out to strangers. A lack of professional contacts is a barrier to entry for junior technologists and will negatively impact sustainability for senior contractors.
Basic sales – Advanced sales skills are unnecessary, but an understanding of what a close is and learning a few different ways to close will be helpful.
Basic marketing, brand management – Contractors have a brand, though many don’t think of it that way. Independents should pay attention to making their brand more attractive. Speaking engagements, tech community leadership, and publication/blogging are a few ways to increase visibility and potentially become a recognized authority.
Focus on billing – Independents become frustrated when they realize that running their small business is more than just writing code. Taxes, insurance, contract review, time sheets, invoices, and expense reporting eat into time that would be better spent as billable hours. Successful contractors try to maximize billable time and often outsource (or automate) tasks when possible.
Negotiation – When using a broker it is customary that they handle negotiation with the hiring entity, but an independent will still need to negotiate rates with the broker. A sum as small as a few dollars per hour quickly adds up over long client engagements. Negotiations for salaried positions can be easier due to the number of components that a company may be willing to adjust (salary, bonus, stock, etc.), but for contractors the negotiation is almost always a single figure.
A recent post by Y Combinator’s Sam Altman, Exploding Offers Suck, detailed his distaste for accelerators and venture capitalists who pressure entrepreneurs into critical decisions on investment offers before they have a chance to shop. The article outlines Y Combinator’s policy of allowing offer acceptance up until the beginning of the program.
An exploding offer is as any offer that lists a date for the offer to expire, with the allotted time being minimal. Altman’s article is about venture funding, but most in the industry gain exposure to this situation via job offers. This practice is fairly standard for college internships, where acceptance is required months before start date. Exploding offers may be less common for experienced professionals, but are hardly rare.
Many companies use templates for job offers where deadlines are arbitrary or listed only to encourage quick responses, which gives a false appearance of an exploding offer. Other firms have strict policies on enforcement, although strong candidates in a seller’s market will cause exceptions.
Why exploding offers exist?
The employer’s justification for exploding job offers may focus on planning, multiple candidates, and finite needs.
If a company has three vacancies and three candidates, how likely is it that all three receive offers? What is the likelihood they all accept. Companies develop a pipeline of perhaps twenty candidates for those three jobs. If six are found qualified, the company has a dilemma. The numbers and odds become ominous for firms evaluating thousands of college students for 100 internships.
The exploding offer is one method for companies to mitigate the risk of accepted offers outnumbering vacancies. They are also used to ensure that the second or third best candidate will still be available while the hirer awaits response from the first choice. Fast acceptance of exploding offers may be viewed as a measure of a candidate’s interest in the position and company, particularly at smaller and riskier firms.
Job seekers may feel that exploding offers serve to limit their employment options, with a potential side effect being lower salaries due to reduced competition. These offers may also help level the playing field for non-elite companies, as risk-averse candidates may subscribe to the bird in the hand theory.
Since they are not uncommon, it’s important to consider a strategy for how to handle exploding offers, multiple offer scenarios, and how to prevent these problems altogether.
Avoid the situation entirely
The issue with exploding and multiple offers is time constraint, and job seekers need to be proactive about these scenarios. The best strategy is to maximize the possibility that all offers arrive at the same time. If all offers are received simultaneously there is no problem.
Those applying to several firms should anticipate the possibility that offers may arrive over days or weeks. When researching companies of interest, investigate their standard interview process, the number of steps involved, and how long it takes. Current or former employees and recruiters representing the company will have answers, and when in doubt the general rule is that larger companies tend to move slower. Initiate contact with the slower companies first, and apply to the fastest hirers once interviews start with the first group.
Strategies to control timing of multiple offers
Unfortunately, job searches are unpredictable and candidates feel they have little influence on the speed or duration of a hiring process. Stellar candidates have much more control than they might expect, but even average applicants can affect timelines.
If Company A has scheduled a third face-to-face meeting while Company B is just getting around to setting up a phone screen with HR, the candidate needs to slow the process with A while expediting B. What tactics can hasten or extend hiring processes in order to synchronize offers?
- Ask – Asking about the anticipated duration of the interview process and about any ways it can be expedited. This is a relatively benign request so long as it is made respectfully and tactfully.
- Flexibility and availability – Provide prompt interview availability details regularly even they aren’t requested, and (if possible) offer flexibility to meet off-hours or on weekends.
- Pressure – As somewhat of a last resort, some candidates may choose to disclose the existence of other offers and the need for a decision by the employer. This can backfire and should be approached delicately.
- Delay interviews – This is the easiest and most effective method to employ, with the risk being that the position may be offered to someone else in the interim. When multiple rounds are likely, adding a couple days between rounds can extend the process significantly.
- Ask questions – There are many details about a company that influence decisions to accept or reject offers, and the process of gathering that information takes time. At the offer stage, questions about benefits or policies can usually buy a day or two.
- Negotiate – Negotiating an offer will require the company to get approvals and to incorporate new terms into a letter.
- Request additional interviews or meetings – Once an offer is made, candidates feel pressure to accept or reject. Another option is to request additional dialogue and meetings to address any concerns and finalize decisions.
Specifics for exploding offers
The issue with exploding offers is typically the need to respond before other interviews are completed, so the goal is to buy time. Some candidates choose to accept the exploding offer as a backup in case a better offer isn’t made. This tactic isn’t optimal for either party, as the company may be without a replacement and the candidate has burned a bridge.
In an exploding offer situation, first discover if the offer is truly exploding. As was mentioned earlier, many companies want a timely answer but don’t need one. The offer letter may give the appearance of being an exploding offer without actual intent. One response to test the waters is “The offer letter says I have x days to decide. Is that deadline firm or could it be extended a day or two if I am not prepared to make a decision at that point?”. The company’s answer will be telling.
If it is discovered that it is truly an exploding offer, resorting to the tactics listed above could help. HR reps may be uncomfortable asking for a decision if they feel a candidate’s legitimate questions are unanswered. As the deadline approaches, negotiating terms and asking for more detail will provide time. The request for another meeting will require scheduling, and the parties involved might not be available until after the deadline. As a last resort, simply asking for an extension is always an option.
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.
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.
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.
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.