Unconventional Career Advice for Developers from an Unconventional Background

Introduction

My career has been weird. I’ve done a lot of different things (law, engineering, management) and gotten picked for many jobs that I was probably under-qualified for. Over the course of my career, I’ve stumbled on a couple of tricks that have helped me do this. I’ve written before about the idea of leverageable experience: jobs that gives you more experience per year than another might. This article picks up where that one leaves off: what are actual tactics for leveraging your experience.

What follows is a set of very unconventional career advice. It’s mostly aimed at people early in their careers and specifically for developers who have recently graduated from a coding bootcamp. That said, the lessons should apply more generally.

Don’t need a resume

All the career advice you’ve heard up to this point has probably assumed you’d write a resume. But this misses two very important facts about how the world works:

1. Resumes suck and no one likes them or actually uses them
2. The best jobs are not ones you apply for

In fact, I would go so far as to say that needing a resume is a negative signal that you want to get past. The goal of the first few years of your career is to get to a point where you don’t need a resume.

Resumes are a terrible way of sharing your experience and skillset. They’re awful to read and no one actually looks at them. When I first started hiring developers, my manager taught me to completely ignore the resume and just go straight to their personal website and GitHub account. We didn’t really even look at the personal website for very long. Instead, when something interesting caught our eye, we opened up the console and started digging through the code to see how they’d implemented it.

But there’s a larger point here, beyond how terrible resumes are. You want to get to a place where you don’t need one. You do that by having a network and a good reputation.

I experienced this on a small scale when I was hired to lead instruction for a coding bootcamp in DC: one of the full-time instructors was a student in a part-time class I taught, the hiring manager worked closely with my manager, and my manager at my full-time job had previously been both of their managers. I had (accidentally) stacked hiring in my favor. For most jobs, you really just need one person on the inside who can vouch for you. Two people dramatically increases your odds of getting a job.

I experienced this on an even larger scale when I worked with someone who had a large following on Twitter: she regularly had people reaching out to her with opportunities for jobs and freelance projects. All she had to do was keep tweeting and publishing articles and she was able to build an enormous network of people who knew who she was and what she was good at.

Resumes are terrible and you want to get to a place where you don’t even need one. Instead, rely on your reputation to do the work for you.

Start your own company

My students are always shocked when I give them this advice. In their minds, starting a company is this huge monumental task that will require a mountain of effort. They, like most developers, are also juggling a couple of side projects on top of their jobs. All I’m really saying here is: go the one extra mile to polish up your side project into a legitimate product.

Early on in my career, I met someone who was also learning how to code by building an Evernote clone. Functionally, it was the same as Evernote, but they made the design different. They got a job very quickly. The thing to understand is: if you have a working side project, you’ve already done 90% of the work. All that’s left is to integrate Stripe and build a landing page.

And here’s another kicker: it doesn’t matter what your company is or even if you work on it full-time. Having a great idea doesn’t matter either, in fact it’s probably better if the thing already exists (there’s an exception here for social media apps - stay away from social media apps).

Going the extra mile to polish your side project works because it makes it look legitimate. It’s no longer a thing you’re hacking around on, it’s a company. Functionally, the difference is minor. But the impact on how the project will be perceived is enormous.

I think this advice stands, even if your goal isn’t to start or run a company. Take one of your side projects and treat it like a business anyway because you’ll get the end-to-end experience of building, launching, and running a product. Best case scenario: you have a profitable business on your hands and don’t need a job. Worst case scenario: you’ve made yourself extremely hireable.

Publish

Blog, publish a newsletter, Tweet - anything. Like with the business you’re going to start, it doesn’t actually matter what you publish, as long as it’s good and you published it. Being able to send someone 2-3 articles that I wrote on a specific topic has done far more for my job prospects than any resume ever could. Furthermore, publishing will help you build a network of people who know your work - people you don’t even know will be aware of who you are and what you’re good at, which can lead to some opportunities that you can’t think of.

All it takes is a little bit of consistency and meeting a baseline level of quality: publish a good article every week, publish one good tweet every day, publish a good newsletter every month, etc.

Most of my students get hung up here: they don’t know what to write about and don’t think they have anything original to offer. I have two things to say about that. First, you don’t have have anything original to offer, you don’t have enough experience yet. It’s good that you’re aware of that, but if you let it stop you you wont get anywhere. This applies to publishing as much as it does to making pull requests. Second, writing original content is not actually Step 1 in this process. It’s maybe Step 10. Step 1 is to imitate others, so you can learn the process. When you’re starting out, find 3-5 articles on a topic you know a little bit about, read and take notes on them, then write your own article (with your own explanations and examples). There’s a fine line between plagiarizing and imitating - I’m suggesting you imitate to learn the process, not that you plagiarize. Overtime, you’ll develop your own process and way of writing articles that works for you. As you grow as an engineer, you’ll be able to offer an original perspective.

Publishing creates a virtuous cycle where - after a while - you get some positive feedback on the things you’ve published. That inspires you to write and publish more, which leads to more positive feedback. Feed that cycle and let it compound and in less time than you think you’ll have a body of work you can point to and a group of people on the internet who know who you are and what you’re good at who will advocate for you.

Make it really easy for people to say yes

A big unlock I had when interviewing was realizing that the person on the other side of the screen wants to say yes - they want to hire you.

Hiring is a nightmare. No one enjoys doing it. It’s a miserable, time-intensive process where you have to work your way through a haystack of annoying duds to find a maybe handful of interesting candidates. Resumes are awful, remember? There’s no correlation between how good a resume is and how good a candidate actually is when you get them on the phone or in a coding challenge.

So if they’re talking to you, then they think you are probably qualified. This is not your chance to tell them about yourself or to answer their questions, like most career advice would have you believe. This is your chance to make it really easy for them to say yes to hiring you.

How do you do that? It's all in how you prep. For a job I really wanted and was a little under-qualified for, I put together a growth plan with 3, 6, and 9 month goals that I would hit (I knew in advance that I'd be able to hit these) that included project ideas I could take on to pick up the technologies I hadn’t worked with yet. It sounds like a lot, but it took an hour to put together and got me the job. For another job I really wanted, I built a simple version of one of their projects in Codepen and sent it over to them right before my interview started. I got that job too.

In both cases, the conversation was no longer a question and answer about what I did and didn’t know. It was about something that was way more interesting to me and the interviewer. It also made it really easy for them to say yes. They could go back to their boss and point to the 9 month growth plan or the Codepen and advocate for why I was a good candidate - easily. Just the fact that I’d put those together was maybe enough.

In Sum

By now, you can see how unconventional this advice is. How many career advisors are going to tell you to try and not need a resume? The advice is so unconventional, in fact, that you might be tempted to ignore it. But if you’re coming from a coding bootcamp, then you’re already coming from an unconventional background. Most of your peers applying for junior-level engineering jobs will have a computer science degree. Your unconventional background gives you the freedom to try unconventional things.

These are all things I feel lucky to have discovered over the years and my hope is that you’ll try them out and see if they work for you.