Breaking into a new industry or role is difficult. Learning a new set of skills and getting a job using them is just that, difficult. You could even say it’s
Now try competing for that same role in a market saturated with other folks in your same shoes. Most good things in life aren’t easy, but they are worth fighting for.
In my case, my new job gave me a 20% pay increase from my former role as a project manager. And now, I’m also doing work that invigorates me.
I’ve seen a bunch of posts with technical breakdowns of what folks did to get to the finish line. This post will take some broader strokes and talk about soft skills that are also important to help you land that first job. Don’t worry, there’s a break down at the end of this article with the technical skills I achieved along the way.
Programming is hard. Finding a job is hard. Don’t give up.
Learning how to program is a journey in itself. You’re telling a computer a detailed story so that it can then tell the same story to other folks at a higher level. As developers, we need to be very detailed and specific, because computers are dumb.
Learning to give instructions to computers is a journey. Enjoy it. If you don’t like learning how things work, this might not be the path for you (which is totally cool!). But, it takes time to get on the same page as a computer. They need details!
Programming is about solving problems and understanding how things work. That’s why the salaries of developers are high. People who solve problems using a skill set that is difficult to acquire are expensive to employ.
Finding a great place to work takes time and luck
I really lucked out on my job hunt. Not only did I get a job (at Dexter) that I wanted, but I also found an organization that values engineering, learning, and personal growth, and is filled with fun people. Finding an organization that has all of these qualities is not easy.
Let’s take Dexter’s senior designer, Michael Rado, for example. He worked through the freeCodeCamp challenges. He googled a lot, learned the docs like the back of his hand, and asked for help from some members of his team. As a result, he was able to build a chat bot based on a version of the classic DopeWars game for TI-83 and PalmPilot on our platform. Hopefully, he’ll have a blog post soon detailing some of the Phantom.js magic he used to dynamically generate images of a player’s score.
I found something that worked for me and committed to it
That something for me was freeCodeCamp. Working through difficult problems is the name of the game. Gradually raising the bar on those problems is what the curriculum at freeCodeCamp does best, while focusing on web development.
I spent a lot of time getting stuck and figuring out how to fix issues. I did it today at work — broke down a challenging task, fixed something that wasn’t working correctly, and built something that’s on the roadmap.
The real value in freeCodeCamp is the projects. They’ll get you thinking and give you something to add to your resume. Code challenges in a web editor are valuable, but making something on your own is addictive and forces you to dig deep.
While I haven’t finished the program just yet, I did pick up enough knowledge to get through multiple technical interviews with a bunch of companies and to land a job as a developer at Dexter, which was my goal.
Bonus points for freeCodeCamp because it’s open source. I was able to get my first pull request merged, which was pretty fun. If you want to contribute, grab an open issue and sink your teeth into it. Or you can find another open source project that you’re interested in.
At the end of the day, you want to show folks the work that you did. Not some tutorial or book project. You want to be able to show them the problems that you solved. Working through projects does just that.
Another reason I’m a big fan of freeCodeCamp’s project selection is because their projects slowly increase in difficulty and scope. If you don’t know where to start, don’t worry — freeCodeCamp will guide you.
The other resource I’m a fan of is a tool’s documentation. Tutorials are great, but documentation is even better for large open-source projects like React and Redux. Throughout the day I look at documentation.
I found a mentor who was interested in my code
For me that was my friend Chris Roth. I met him at the Recurse Center. Because I worked on his side project, I was able to review his codes while he spent his time doing more challenging things. I was able to see how someone who is more senior on the job works and sets up a project. Meanwhile, I just poked, picked, and learned. Additionally, once the product is out, it’s something I can put on my resume.
Also, having a project you’re working on with someone else is a great talking point during interviews. The idea is to always play up that experience. I always want to be learning from other folks, regardless of how much time they’ve been programming. Folks with more experience can show you things you didn’t know or give you a new perspective on things. Folks who are newer will force you to really know what you’re talking about. By you explaining concepts to them, it will make you better understand and reinforce the knowledge you already have.
The more I can pick up from someone, the better. Stand on the shoulders of giants and your peers. You’ll have great stories about how you worked with others to get the job done. You know what you will be doing at your day job.
Also, knowing when to ask for help is a skill. Working with tools, libraries, and frameworks you aren’t familiar with and working with others, especially people who have more experience, is a solid learning path.
I found a network of like-minded people with the same goal
That was a physical place for me. It was the Recurse Center. Before that, it was freeCodeCamp’s NYC Meetups. You’re not on this journey alone. Nor should you feel like you are.
Recurse was particularly interesting because it did have a curriculum and a teacher was not present. You could work on whatever you wanted to and with whomever. It’s like a writer’s retreat for programmers.
I chose to work on a combination of freeCodeCamp projects and my personal projects with other participants who were above my skill level. Finding projects you’re interested in is super important (and fun).
I wrote code every day
I can’t stress this enough. Building momentum is huge. Doing something every day, no matter what it is, will help you get into a groove and gain momentum. It will help you grow.
Even if you don’t feel like you’re making progress, you are. Keep it up.
I really dug in
You don’t need to know everything. Having a solid grasp of key concepts and being able to talk about them are not only critical to the interviewing process, but also to doing the job. For example, if you don’t know you have a hammer, you’ll never use it.
When you dig into a project, it shows. Figuring out a solution to a new problem (it doesn’t have to be something that’s non-trivial) is a great talking point during an interview. Again, it’s more about the journey.
I should’ve had a stronger web presence
This was an area that I really should have focused on more. Writing blog posts about what you’re learning, things you’ve built, and your takeaways from projects shows that you’re passionate about what you’re doing. It also shows that you can communicate online and that you are knowledgeable!
Hiring directors look at your blog posts. So write them.
I casted wide and often
I submitted 91 job applications, and attended 4 job fairs and many Meetups inbetween. Before I even started to apply for jobs, I had a couple of people look over my resume and projects. While I had a bunch of
.DS_STORE files that I should have deleted, at that point, I felt I could apply to junior roles and be taken seriously.
Applying for jobs takes time. I never tried to apply to more than 3 roles in a day. Go the extra mile when possible. If you can find the information of a hiring manager, reach out to him either via email or Linkedin. Show passion for the product and technology. Create an account, go through a demo, or ping the company about a bug you found (I did!).
Also, try to keep it short and sweet. They’re busy people too! My resume and cover letter are both about a page each. My cover letter is about 7 to 10 sentences long. You just need a quick intro. The hiring managers do not need to know your life story. Save that for your first interview :D.
While knowing the run time of a specific algorithm is great, it’s not everything. Knowing the core concepts at a junior level is key, as I had touched upon earlier. Knowing the foundations of your tools well and being able to communicate and understand what’s going on within an application is expected.
Have a positive attitude. Being able to show your thought process for breaking down issues is the other part. What are you like when a challenge is thrown your way? This is basically what your day-to-day is going to be like. Show them that you not only enjoy being challenged, but that you’ll push yourself.
Know when to ask for help and take direction. If you’re not willing to listen to other developers, you are wasting everyone’s time.
The Recurse Center’s motto is “never graduate.” Above all, that’s what I’ll be doing everyday at work and at home — learning something new.
Here is a list of my current goals:
- Stay active and commit to writing 1 blog post a month. I didn’t do a very good job of this while searching for work. I know the blog would’ve certainly helped with my job search.
- Set goals at the start of each month. This month I want to focus on improving my debugging skills. It’s a large part of my day job. Investing in getting better at it is a low-hanging fruit. Hopefully it is an easy win.
- Work on one large project that uses the skills that I picked up from work.
- Look back at the end of the month to see if I’ve pushed the needle forward at all. I’m not sure exactly what my metrics of success are just yet, so this first month will be an experiment.