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.
I regularly hear from and read about technologists in a career rut. Unless one is both lucky and adept at predicting the future, experiencing some temporary stall can happen to professionals at any career stage. It may be the feeling of being stuck in an unchallenging role, feeling burdened by an undesirable skill set, or trapped in a company that seems difficult to escape.
Career stagnation in technology could be defined as a prolonged period characterized by limited project variety, no advancement or even lateral movement, few tangible accomplishments, and little exposure to any emerging trends. Some managers are aware that workers in these situations generally leave, so the managers may proactively try to satisfy staff by shuffling teams and providing more interesting tasks. Many managers have to focus on deliverables and may give little thought to the career development of their charges, perhaps throwing money at retention problems instead of providing challenges.
To “level up” could mean a promotion into management or technical leadership, a new start at a firm with increased opportunity, a role with autonomy and decision-making responsibility, or the ability to make significant improvements to skills and marketability. People that think about the leveling up concept often know what they want (or sometimes what they don’t want), but don’t necessarily see the best paths to get there.
Leverage the skills you have to get the skills you want
Most professionals view their current skills as a means to getting new jobs, but it’s useful to also think about skills as the key to acquiring other new skills. This tactic is most relevant when a skill set is dated and a previously strong marketability level is now questionable. Some will attempt to make a clean and immediate break from their old technologies or responsibilities into the new, usually with mixed results.
As an example, many COBOL programmers tried to enter the stronger Java job market following Y2K. Some applied to jobs with no Java experience hoping their COBOL years would be deemed transferrable, while others pursued certifications and self-study to ideally be viewed as a somewhat “experienced” hire. One overlooked strategy was to approach companies that were using both COBOL and Java in some capacity, with the understanding that the candidate was willing to write COBOL if provided the ability to also work with Java.
Most job seeking technologists have at least one ability that will help them contribute immediately to any other team or organization. It could be an obscure technical skill, leadership experience, or domain knowledge. Even if the skill is not something the person wants to use forever, it could be a key component to getting hired. Try to identify companies that may be looking for some specific expertise you can provide, even if it isn’t the most attractive tool in your bag, and be transparent about your willingness to do that less desirable work in exchange for exposure to skills that are in demand.
For those in the most stagnant of technical environments, taking on independent projects or open source may be the best way to gain experience and increase marketability. It’s usually preferable to learn new things on the job (because money), but being proactive about your career and keeping abreast of current marketable technologies will also show initiative to potential employers. The level up from personal projects almost always comes from an employment change.
Sometimes to level up you need to take a step back – or sideways
Careers aren’t always linear, and the expectation that trajectory needs to follow a strict continuous and incremental level of responsibilities is perhaps naive and potentially dangerous. Job seekers are often prone to placing too much weight on a position’s salary or (gasp) title without fully considering the position’s potential opportunity as it relates to future marketability and career development. Somewhat frequent movement between jobs is accepted in our industry, so positions can be viewed as stepping stones to future opportunities.
When evaluating new roles, whether with a current employer or another firm, imagine what a three or four year tenure in that role at that company will look like on future résumés. Will the skills likely to be acquired or improved in that role be marketable and transferrable to other firms? Accepting positions that come with lateral responsibility and compensation is usually a wise long-term decision when provided a more favorable learning and growth environment.
This week I was approached by two individuals seeking advice on finding employment in a programming capacity, yet both lacked the traditional standard requirement for entry-level positions – the BS in CS (‘BSCS’). I get asked about entering the industry often, and each scenario has a unique wrinkle.
The most recent candidates were a fresh Ivy League liberal arts grad and a Physics Ph.D. The former had brief hobbyist programming experience and the latter gained light exposure during school. Both are immediately employable in other industries, but perhaps not in the field they now target.
Of course, both may still be able to earn a BSCS (or MS) and take the traditional route. For our purposes here, let’s take that option off the table. For a Ph.D., the thought of additional classes might be hard to swallow, while costs might serve as a barrier for many others.
Non-BSCS candidates are often at a distinct disadvantage when competing with BSCS grads for entry-level positions. It’s becoming more common for CS grads to enter the workforce with multiple internships and code samples to bolster their candidacy. It’s reasonable to assume that typical non-BSCS grads have nothing comparable, in addition to what may be considered a less attractive degree.
One important point to remember is once you’re in you’re in, meaning that the most difficult job search for non-BSCS grads should be the first one. After gaining a bit of experience, your risk factor subsides (assuming you didn’t perform horribly in your first job). After three years no one cares about your major, and after five no one cares about your degree.
What are the common approaches for a non-BSCS grad to break in?
DIY and self-study (AKA GitHub, apps, certifications, blogs, and sites) – This method is based on the philosophy that you get a shot if you have a body of work. The wealth of freely available resources makes this method attractive to both the confident and the frugal. There can be a fine line between rigorous code immersion and post-graduation idling, so it’s helpful to set tangible goals, a schedule, and practice self-discipline.
When given no direction on what to build, people usually struggle to find projects ideas. Look for suggestions like those on Martyr2’s Project list, and improvise. As for reading material, there are extensive lists of free programming books that may be helpful. All the material you need is out there and easy to find.
Bootcamps – Any conversation today about breaking in for the non-BSCS will include bootcamps, and I have mentioned thoughts on them before. Bootcamps may be regarded as a compromise, where the investment of both time and money rests between DIY and degree programs. Some view bootcamps as an accelerated BSCS, or a hybrid internship and apprenticeship with classwork included. Most bootcamps appear as preparatory schools for startups based on the skill focus and instructors. Do your homework, and use caution when discussing the value of bootcamp experience versus degrees to avoid insulting employers.
Internships, or cheap/free labor – Some organizations (think small businesses and non-profits) will let a non-BSCS perform development tasks as an intern or volunteer. This can be a clear ‘win-win’, as the organization gets productivity while you get somewhat valuable real-world experience. A combination of volunteer or internship and personal projects starts to level the playing field for a non-BSCS.
Training in – There are companies that hire non-BSCS for entry-level programming jobs, and the first months include corporate training programs designed for non-CS grads. The positions may pay less than entry-level programming jobs, with curriculum intended to produce effective employees instead of versatile engineers. For example, instruction could focus on proprietary technologies and frameworks instead of popular industry offerings.
What are some key items to consider?
Get out of the basement! – Some DIY’ers bury their head in code and books with no human interaction. Make community learning events and outside communication a part of your diet. This will help you measure your knowledge in a live setting while also providing the opportunity to make some industry contacts.
Don’t enter the job market too soon – For CS grads, the natural time to start the search is around graduation. No mystery there. For the non-BSCS, there is an instinctive rush to start applying to jobs early in order to take the temperature of the job market. Fight the urge. If you apply to a desirable company today and are subsequently deemed unready, don’t expect to be reconsidered in three months (when you are ready). Make sure you know enough to succeed in technical interviews, have your GitHub code clean and optimized, have any apps or sites tested and fully functional, and are prepared to make a strong impression.
Leverage the skills you have to acquire the ones you want – Bringing useful abilities and experience that can pay immediate dividends (no matter how small) to an employer mitigates their hiring risk. If you are able to contribute to an organization beyond just code, providing both a learning opportunity and a decent wage is easier for firms to justify.
Be realistic – Your three months of self-study or bootcamp are not likely to get you the dream job at Google. Be willing to start towards the bottom and pay your dues to move up.
Beware certifications – When faced with a choice of proving abilities with either code or certifications, always pick code. Many industry pros attach a stigma to those who focus on getting certified instead of just doing.
Make learning opportunity your #1 job search criteria for first jobs – The money will come. Trust me. If provided multiple job opportunities simultaneously, opting for a job due to an extra $2K or a commuting difference of five miles will be regretted. Find a place where you can learn and grow.