Silicon Valley loves to disrupt things—including people’s careers. I learned this firsthand in 2013. It was four weeks before my 30th birthday and six weeks before my wedding. I was working on a top-notch product management team at a high-profile software company. I had interesting problems to solve; bright, friendly coworkers; and all the free snacks I could want. It was Silicon Valley at its best.
After five years of trying to make it in the Bay Area, the job had seemed to be my big break—until it wasn’t. After a little more than a year, the company shut down the product I managed, sold off the assets, and laid me off.
At first, I wasn’t that worried about the job search. I had a good resume and had always interviewed well. I figured I would easily find a product management job at another company. But as the months went on, my optimism started to fade. By the fall, I had applied to 104 different jobs and had yet to get a single offer.
After such discouraging results, I began to reassess my options. It was becoming clear that I had not achieved what the industry might call product-market fit. If only I knew how to code, I thought, life would be easier. And so I decided to take the plunge.
Who, me? Code?
Knowing how to code holds a lot of clout in Silicon Valley. There are roughly six engineering jobs for every product manager position in Silicon Valley. Companies frequently complain about the shortage of engineering talent—and they’re willing to pay handsomely for it.
There are more intangible benefits to being a coder, too. As a humanities type living in the Bay Area, I’d noticed that engineers received an immediate (and entirely undeserved) level of respect. Strangers assumed that coders were smart. On the job, managers and coworkers assumed their time was valuable. In meetings, software engineers’ assessments carried extra heft. They could get away with making inappropriate jokes, keeping irregular hours, disregarding dress codes and generally bungling interactions with other human beings.
But while it sounded nice to be treated as an infallible genius, I’d never imagined myself as a coder. My entire personality seemed out of place in a city dominated by coders who wanted to live off Soylent and launch the next billion-dollar startup. I had a bachelor’s degree in Sociology and had never taken a computer science class. I didn’t watch sci-fi movies or laugh at the right nerdy jokes. In a culture that rewards people with highly-focused obsessions, I dabbled in bird-watching, books and sports. I’d worked in sales and politics, and considered my communications skills to be my biggest strength. I was a people person!
But the market was strongly urging me to reconsider this identity. Without a change, my options seemed limited.
In some ways, my timing was good. Not only was there strong demand for coders, plenty of resources had sprung up to help people learn the skills to land a job in Silicon Valley. There were free online classes through Udacity and Coursera, free self-guided tutorials on websites like Codecademy, and free eBooks with big promises and intimidating titles like Learn Python the Hard Way.
There was also an emerging set of training programs billing themselves as coding boot camps. For tuition in the $15,000-$20,000 range, these programs claimed to teach students market-ready engineering skills in about three months. They boasted a range of impressive statistics about their graduates: hiring rates well over 90%, six-figure salaries and “get a job or your money back” guarantees. I had even worked with a few graduates from one program, Hackbright, at a previous job.
Still, I was terrified. While the total immersion experience of a boot camp seemed like my best chance to really learn to code, I worried that I would spend a lot of money and time and emerge no better off than I’d been before. But I didn’t have many other good options. So I signed up for Hack Reactor, a coding boot camp in San Francisco, and began my career as a software engineer.
Making peace with error messages
The first thing I discovered was that learning to code is hard. It takes hundreds of hours. Most of those hours are spent staring at an error message. Code almost never does the right thing the first time you run it. You would think that someone who had just been rejected from 104 jobs would be accustomed to failure, but I still felt nervous—especially when I was not at all confident that I’d be able to make the error message go away.
What helped was bonding with the other stressed-out coders in my cohort of 30, which included a lawyer, a neuroscientist, a Navy helicopter mechanic and a professional video-game player. Our ages ran the gamut from early 20s to 40s. Some students already had degrees in computer science or related fields, but wanted to refresh their skills. Others had little or no college experience at all. What we all had in common was a shared commitment to helping each other make it through the program alive.
We met six days a week for 12 weeks. Official hours were 9 am-8 pm, but everyone stayed late into the night to work on assignments. All those hours of practice added up: by the end of the program, we’d built full-featured web apps.
The biggest lesson of Hack Reactor was to make peace with those error messages. Students were constantly asked to work with problems that they didn’t know how to solve. We learned computer-science fundamentals, but the deeper emphasis was on learning patience, humility and perseverance. Whatever Hack Reactor graduates lacked in formal training, they made up for in grit.
Still, there was always more to learn: an overwhelming number of languages, libraries and tools. As I approached the end of the program, I remember wondering–how many of these things do I have to know before I can call myself an engineer?
The career reboot
There is a very practical answer to this question. You are a software engineer if you can pass a coding interview. Coding interviews are four-to-six-hour marathon sessions wherein job candidates are asked to write code to solve various puzzles. Often, the candidate is expected to stand at a whiteboard and write out the solutions by hand while interviewers scrutinize their solutions. There are many variations of this process, but it’s the basic approach every company I’ve worked at has used to hire engineers.
There are plenty of problems with this method of assessing candidates. It doesn’t reveal much about how well an engineer works on a team or develops a complicated system over time. It over-rewards confidence, and draws broad conclusions about a candidate’s abilities based on a tiny sample of code. Even great engineers can have a bad day.
But the coding interview is also closely tied to the democratic myth of Silicon Valley. There’s a vision of meritocracy here. If we believe we have one test that can discern engineering ability, then only the results of that test matter. Companies can disregard formal credentials, professional backgrounds, how a candidate dresses, the formatting on their resume, and just about everything else. A lot of companies still filter for computer science degrees, online portfolios, and previous work experience, but increasingly they are willing to give the non-traditional engineers a shot. All they have to do is pass the test.
After six months of studying and 12 weeks of boot camp, I was ready to give the interview process my best shot. It didn’t start well. My first interview was at a giant, well-known company—and I bombed it. The second interview wasn’t much better. But, much to my surprise, it got better from there. My nerves calmed down and I got used to answering questions in the high-pressure interview format.
Within a few weeks, I had received generous offers from multiple companies. I still didn’t feel like an engineer, but the fact was that someone was willing to pay me to write code. The plan had worked. It took months on the job before my self-perception caught up with reality.
Make way for the humanities
What I know now is that a significant number of engineers working in the field do not have a computer science degree. One recent survey put the number at more than 50%. Whatever the actual number is, it includes my last boss and many of the best engineers I’ve worked with.
While boot camps can be a controversial subject, self-taught coders are not. Lots of Silicon Valley startups believe that if you can teach yourself to code without the help of a university computer science program, it shows you are motivated, resilient, curious, and resourceful. It is exactly the kind of scrappiness that companies are looking for.
Moreover, engineers are increasingly expected to have design experience, business savvy and project management skills. They need to be intellectually curious and adept at collaborating with people who work in other areas. In my experience, companies are starting to value these traits almost as highly as traditional computer science training. The fact that engineers like me bring experience from other careers is often seen as a bonus rather than a deficit.
It’s now been more than two years since I became an engineer. I still sometimes feel like I’m wearing a disguise. But I’ve received a steady stream of promotions and increasing responsibility, and I’ve now moved onto my second company.
I rarely mention my boot-camp experience to my coworkers, wary that they’ll look down on me from the perspectives of graduates with four-year computer science degrees. But when I do mention Hack Reactor, I often enjoy the look of surprise on my colleagues’ faces—surprise because these days, I sometimes seem to know what I’m doing. “Yes,” I think, “I’m surprised, too.”
As I think back on the time I spent becoming an engineer, I am struck by how lucky I was when I made the career leap. I had no kids, little debt, a supportive spouse and close proximity to the biggest tech companies in the world. Yet even with all those advantages, I hesitated.
What I came to understand is that Silicon Valley is always changing—with or without me. I could stick to what I knew and get left behind, or decide to try something different.
Ultimately, I found out that becoming an engineer is mostly about practice. For me, the real challenge was giving myself permission to do the work.