I’ve been looking forward to writing a post like this for a long time. This Monday, I’ll be starting my new job as a Software Engineer!
I have an outline for a detailed blog post about how I got to this point, but for now, I want to share some actionable advice to help you get that elusive first developer job.
Don’t Rush Yourself
I’ve seen a lot of Internet writings about people who’ve gone from no exposure to coding to a hired developer within 6 months. Realize that those people are the unicorns. Be happy for them, but realize it will likely take you at least a year if you have a full time job. I’d spent over two years working through Free Code Camp off and on before I got to a level where companies wanted to talk to me. Don’t think of it as a competition for jobs against other developers where if you move too slow, you’ll get left behind. There are more job openings out there than you could ever hope to apply to.
Once you get good at building applications, companies will be enthusiastic about getting you in for an interview because there just aren’t many people at that level who aren’t already working for another company. It’s not a race. Once you’re ready, companies will want to hire you. I promise.
When are you ready?
When it comes to learning to code, I like to think of it like learning to climb a mountain.
Before even reaching base camp, you need to learn about what gear you’ll need, how each piece works, and how all the pieces work together. Then, you need to practice using your gear until you’re comfortable. Then, you need to learn to climb. You’ll maybe start on some boulders, then steep hills, then some short peaks, and keep building up skills from there. Over time, you’ll encounter obstacles you’ve never faced before and gain experience and priceless lessons from failures and frustration. The key is to just keep going. Learn from your failures, and move on.
Do, fail, learn, repeat.
Eventually, it gets easier and easier, and you can attempt to summit larger and larger mountains.
Can you summit a “fourteener” after 6 months? It’s possible, but it’ll be far safer and easier to get very comfortable with all of the aspects of mountain climbing (building applications) first. Once you’ve gained some experience through building many projects, and have built a number of larger, complex applications that reached and extended your limits, companies will see that and desire that same work for their products.
Kill Imposter Syndrome
Don’t waste time with thoughts like “I can’t get this to work, I must suck at this.” or “I’ll never be a developer at this rate” or “Everyone is so much better than me”.
Don’t waste precious time doubting yourself, or comparing yourself or your progress with others.
The only metric that matters is this: “Did I learn something today?”
If that answer is “Yes”, you win. Period.
It doesn’t matter if your code is still broken, or if you’re still confused about a concept. Learning to program computers is hard. You won’t get certain things right away. It may take a few days, weeks, or even months to understand certain concepts or technologies. That’s normal.
As long as you’ve learned something today that you didn’t know yesterday, you’re moving in the right direction. Just imagine multiplying that new knowledge you learned today times 365 or 730. Those lessons add up FAST.
If you’re learning, you’re winning. It’s hard to see in the moment, but if you don’t believe me, just look at the code you’ve produced last month (or even last week). If you find yourself cringing at certain lines, pat yourself on the back. You’ve gotten better at it!
Over time, those mini-lessons will add up to you becoming a developer that will be capable of bringing real value to companies and customers. If you learn new things and practice everyday, it will truly only be a matter of time before companies will want to hire you, no matter who you are or where you’ve started from.
When Are You Ready to Apply for Jobs?
In my personal experience, I began getting calls for interviews after I finished my first full-stack application for Free Code Camp, the voting application.
By that point, I’d completed my Front End Certification, finished all of the API projects, and was ready to work through the remaining dynamic web application projects.
After finishing the voting app, I decided to build a boilerplate to assist myself and others in bootstrapping the rest of the dynamic web application projects with a modern stack centered around the React ecosystem.
Get it here: https://github.com/mtrifilo/react-ssr-boilerplate
The boilerplate offers a starting point with React, Redux, React Router 4, Webpack, Express, MongoDB, and a JSON web token authentication strategy with local auth and OAuth with GitHub. I strongly encourage you to learn each of those technologies individually before diving in, otherwise you’ll hit a brick wall pretty quickly. Frontend Masters offers courses on everything I used for the boilerplate, and the subscription is well worth the $39 a month.
You don’t need to use React if you don’t want to. Plenty of companies use Vue, Angular, Ember, or even custom built front end frameworks. The important thing is that you get comfortable and proficient in at least one popular framework. They all exist for the same objective: To offer a scalable way to build client side applications. Once you get comfortable with one of them, you can learn the others pretty quickly.
At this point in 2017, the most popular major frameworks have embraced components as first class citizens, offer helpful CLI tools, have great documentation, large communities, and great debugging tools. You really can’t go wrong with any framework these days. They each have their trade-offs and frustration points, but if you learn them well, they’ll take you very far.
So, when are you ready to apply for jobs?
My simple answer: When you are capable of building a simple full stack application, and can provide plenty of code samples on GitHub that show consistent improvement.
If you’re not comfortable with Git and GitHub, do yourself a huge favor and spend some time on it. It will help you immensely.
Using GitHub as version control for your Free Code Camp projects, and other personal projects, will allow potential employers to read through your commits and watch you progress in real time. Don’t be shy! If they like what they see in your code, they will be much more confident in wanting to hire you than they would be otherwise. You want your potential employer to have a good idea that you’d be a great fit for the role before you even walk in for the interview. Open sourcing all of your projects will give good companies the evidence and confidence they need to be sure that you’re most likely perfect for the role they need to fill. Just do it!
Applying for Jobs
One downright lie that I’ve seen all over the web is the idea that job sites are worthless for getting your first developer job. Absolutely false!
I’ve had a number of interviews from companies I’ve applied to through GlassDoor.com, and that’s also where I found my current company. In many cases, companies will post ads on many different job sites that all link to the same job application either on the company’s website, or a service like Jobvite.
It’s a grind, don’t get me wrong, but if you can get one interview for every 20 applications, it’s worth it.
If you’re applying to more than 20 companies without even a phone call, don’t take it personally. There’s likely a reason you’re being passed for other candidates. Revisit your resume, cover letters, and how you’re presenting your portfolio. Google yourself. Look at how you’re presenting yourself through the lense of a hiring manager. Create a “funnel of success” so that companies visiting any of your portfolio pages will be guided to the best of what you have to offer. If you’ve gotten far enough through Free Code Camp to be ready to apply for jobs, then you already have plenty of apps to showcase. If they aren’t open sourced, put them on GitHub.
Hiring managers will vet you. They’ll look at your code on GitHub, they’ll look through your tweets, they’ll read your blog. Give them something to get excited about! Don’t bend your Internet life so it looks good for companies, but at the very least, have some recent projects on GitHub to prove you know what you’re doing, and make sure there is nothing offensive on your public social media accounts that may raise doubts about whether you’d follow company policies or code of conduct.
Don’t get discouraged if you apply to 30 or 40 companies without any interviews. It takes hard work and practice to get your resumes, cover letters, and portfolios polished to the point of getting the attention of employers. Even if you’re the best candidate for the job, employers will usually throw your resume in the trash if it has spelling errors, grammar mistakes, a headshot (Don’t include a picture, ever! It exposes companies to potential legal trouble if they contact you, so they won’t), or lies.
I think it’s safe to say that everyone hates resumes. Candidates, HR people, managers, probably you.
Unless you’re going to do something very unique and fun with it, just keep your resume as clean and simple as possible. Don’t worry about fancy garnish or flashy fonts. If the fluff makes your resume harder to parse in 10 seconds, that will work against you. A boring, but clear, concise, and readable resume will elicit a mental “Thank you for making my job easier” from every manager who reads it. Its purpose is to communicate essential information about a candidate to managers as quickly as possible.
A hiring manager will only devote a few seconds to reading your resume, so keep the most important things front and center. Make you contact information available, and easy to see quickly. Include your phone number, email address and GitHub profile address at the very least.
Offer a “Summary” section that will be your elevator speech. A few sentences each of who you are, what you’ve done, and what you can do to make the company more successful. This might need a few revisions over time. Mine certainly did.
After the summary, add sections for closely related work experience, some projects that showcase the best of what you’ve built (with a short description, and links to a live demos and source code of course), technologies you’re proficient in, and education.
Order each section based on most impressive to least impressive, but keep the summary at the top so at least that will get read.
No one expects you to know all of the hip technologies. Just be honest and open about what you know and don’t know, and demonstrate that you’re excited to learn new things whenever necessary.
Education has varying importance depending on the company. Some will only talk to you if you have a CS degree. Others won’t care if you went to college at all as long as you can prove that you can build software. If you’ve earned a degree for anything other than Computer Science, try to include any impressive accomplishments like a high GPA, or and extra curricular accomplishments.
After all of that, don’t obsess too much about your resume. Your code and your projects will speak much louder. Just make sure you’re completely honest, but highlight what makes you the candidate they should hire. (hint: you have awesome projects you can showcase!).
Be sure to have a friend, your SO, your Mom, or a recruiter pal read your resume to ensure there are no spelling errors or grammatical errors. Take their advice with gratitude, but with healthy skepticism unless they have experience in recruiting or hiring developers specifically. I’m not an expert either. Trial and error will reveal what works over time.
Just write them. If you’re applying to so many companies that it’s becoming a real issue to write cover letters, something else is probably disqualifying you in the eyes of employers. It takes time, it’s annoying, but it will also get the attention of the employers out there that do care about cover letters. There are a lot of companies that take cover letters seriously, and may interview you simply because you cared enough about the role to take the time to write a personal cover letter while the other 30 candidates just gave them cookie-cutter resumes. If this will be your first job related to software development, a cover letter is your chance to explain why you’re going to be amazing for the role, and what projects you’ve done that prove that you’ll be a great addition to the development team.
Sure, a lot of companies don’t read cover letters anymore, but the ones that do are the ones that take them seriously, and that’s one more way to set yourself apart from the hundreds of other candidates mass-applying to every company they see without even remembering the company’s name.
It’s easier to get to the top of the resume pile than you might think if you’re willing to put in some extra effort.
It helps to write a generic cover letter so that you don’t have to write the same basic information over and over again, but most of each cover letter should be unique to each company. It really doesn’t take much time after you write a few. You have a lot to gain from taking the extra time.
The Grind is Real
The hard truth is if you don’t have any related work experience and your resume lands on the desk of an HR rep, it’s probably going in the trash. It doesn’t matter if you invented the next Webpack. Many HR people aren’t technical (and why should they be?) so they’ll just pick the candidates that are most likely to be hirable based on work experience. If you have no work experience, your profile won’t even be looked at by anyone technical, and your resume will go straight into the trash. I’ve heard this called the HR firewall.
So how do you find these companies? How do you get your resume from the HR office to the desk of the Software Engineering Manager who will actually look at your code?
The fastest way is through networking. This isn’t mandatory, but it certainly helps a lot.
One of the fastest way to get your resume to the top of the pile is to contact a hiring manager directly, and bypass the company’s Careers page entirely.
You shouldn’t spam people you’ve never met, but if you go to a meetup where a local company is presenting something cool they’re working on, be in attendance. Oftentimes, they’ll mention that they’re hiring and encourage anyone in attendance to email a manager at the company directly if they’re interested in working for them. That email address could fast-track you to an interview if you’d be a good candidate. You’ll also have the oppurtunity to talk shop with experienced developers you wouldn’t normally meet day to day.
On the first of every month, Hacker News hosts a “Who’s Hiring” thread, which quickly fills up with dozens of posts by companies hiring developers. Use your browser’s search feature to find the jobs you want. Some companies will provide an email address to a manager who will take a look at your resume and portfolio. When sending a resume to someone via email, treat the body of the email as your cover letter.
“Networking” has all sorts of groan-inducing connotations, but it’s very simple. Just talk to people with shared interests. There are a lot of amazing development communities full of people who like to geek out about tech. Don’t go asking people “Hey, are you hiring?”, but if you just talk to people about cool things you’re working on that you’re excited about, and cool things they’re working on that they’re excited about, the people who ARE hiring will find you in those situations. People know people, and they talk to each other.
Worst case scenario, you’ll meet nice people, have some free pizza, hear a talk about something you’re interested in, and learn some new things. The horror.
Interviewing is stressful. There’s no way around it. You just have to go through it and realize that no matter what happens, you’ll always feel better when it’s done. It’s good for you.
Thankfully, the people who are interviewing you will more than likely be very nice, welcoming, and rooting for your success. If they act cold or condescending towards you, take that as a red flag against the company. Remember, you’re interviewing them, too. Is this a company you’d want to work for?
The process usually starts with a phone screening, which is a 10-20 minute conversation about the position, what they’re looking for, your experience, and what you’re looking for.
If the recruiter thinks you could be a contending candidate for the position, and your experience and objective match what the company is looking for, on paper at least, you’ll move on to the next step.
This is where companies vary widely. You could get a take-home project to work on for a few hours and turn in, or you could be invited to pair-program with a developer, with you in the driver’s seat, and build a small project. You could get both tests. For both take-homes, and pair-programming challenges, the interviewer will likely give you the freedom to pick any library or framework you’d like to build the project. Cool, that means you can just use React because it’s the hip thing, and you’re really good at it, right? You can, but take a step back and think for a moment.
It’s easy to think that you’ll be judged based on finishing the coding challenge, and delivering a working solution, but that is only part of what you’re being judged on.
I thought I failed my first pair-programming challenge in spectacular fashion. I didn’t come close to finishing the small app I was tasked to build, and I had to look up a lot of basic DOM API methods on the MDN. Even so, I made it to the next round of interviews.
One thing to emphasize, vocalize your thinking always while pair-programming in an interview setting. The point of the interview is to see how you approach problems, and they can’t read minds. Talk through what you’re doing. This might seem a bit awkward at first, but just practice by pair-programming with friends or other Free Code Campers, or even just talk through the process on your own to get comfortable with it.
The next phase after the initial take-home/pair-programming session is usually an on-site interview, though every company is different. At the on-site interview, you’ll generally spend the day at the company getting to know potential teammates and managers, and have a series of interviews throughout the day. Some of them may be one-on-one, others may be with a group. Some will surely be technical, others will be more culture-fit type interviews.
The technical interviews may include the dreaded white board questions, but many companies don’t use white boards anymore. If you’re interviewing with companies like Google or Facebook, count on white board questions. At this phase in the technical interviews, you’ll very likely get some questions about data structures and/or algorithms and will be expected to implement a couple. Don’t panic! If you spend a week or two learning or practicing the common data structures and algorithms, you should get to basic level of knowledge where you can implement some simple challenges. For a first programming job, you won’t be given the sort of brain-meltingly difficult CS questions that senior developers get. You’ll get there someday. For you’re first programming job, you’ll be expected to demonstrate that you at least understand how the basic data structures and algorithms work, what bigO notation is, and why time/space complexity is important. You’ll also be asked to implement at least one data structure or algorithm in some way.
Algorithms and data structures are intimidating at first, but they just take practice. If you made it through pre-calculus in high school, you can handle algorithms and data structures. The important thing is to be able to implement them on your own based on written requirements or very generic pseudocode. Don’t just memorize them! The skillset you want to develop is the ability to implement them yourself. If you can do that, your interviewer can give you any task to build out, and you’ll be able to figure it out on your own. That is a hard, hard skill to develop, and it will hurt your brain and take a lot of time to master. Senior developers make the big dollars for a reason. Don’t get discouraged. Just keep practicing implementing the common algorithms and data structures, and try out some related interview challenge questions. Over time, you’ll get better and better at it. It will be hard, but don’t quit!
For your first development role, you won’t be expected to know how to implement every data structure and algorithm (your interviewer won’t know all of them, either), so be very open and honest about what you know and don’t know. No matter what questions or problems they present you with, give it your very best shot. Don’t worry about how you’re doing, or what they might be thinking of how you’re doing. Focus 100% of your attention on the problem at hand. If you haven’t learned linked lists yet, but are very familiar with stacks and queues, mention it! They might give you a question about stacks and queues instead, and you’ll be much more prepared to nail the challenge. If you can get proficient with stacks and queues, they know that you can learn linked lists.
The most important thing to demonstrate when it comes to algorithms and data structures is that you understands what BigO notation is, and its importance. Writing a piece of code that is O(n^2), that could have been O(n), costs real money and CPU cycles in production. Prove to them that you won’t do such a thing.
Whether or not a company hires you is largely outside of your control. Put your best self forward always, and make learning and gaining experience your primary objective while interviewing. Every interview will be a challenge that will teach you a few things, and you’ll get better and better at it over time. Try not to worry too much about whether a certain company hires you or not. Every interview will get you that much closer to getting an offer from one company or another. Their will always be another company that will want to interview. If you get rejected, learn what you can from it and move on.
Get comfortable with failure. I’ve gained many priceless lessons from the moments I’ve failed interviews or code challenges. You can’t get those kind of lessons any other way, and pretty much any good developer you’ll talk to will have similar stories. It’s part of the journey. If you can reframe the idea of failure into a oppurtunity to learn something you couldn’t learn any other way, failures take on a whole different significance.
I’ve heard the adage (horribly butchered): “You either win, or you learn. The only way to lose is to quit.”
If you focus on getting better at coding and interviewing every day, you’re winning. That’s it. Period.
You can have an interview a day, and get rejected every day for a month, but if you’re getting better and better each and every day, there will be a point where you’ll be the best candidate for the right job at the right moment. If you constantly improve, it’s inevitable.