This is my guide to landing a developer job. This is just my opinion, or judgement based on a little experience and some research. Love it or hate it. Take it or leave it. This is long and probably not organized well enough.
This is meant to be a living document. When I learn something new, I will add it. If you see something that you think should be changed, drop me a line.
This is the part you can skip over if you want.
That is an excellent question: Just who the hell do I think I am that I feel qualified to write this article? The answer is that I'm not. I'm just a guy. I'm not an expert on the tech industry or the job market. But I'm a guy that went from (nearly) zero to a web dev job in two years, did a lot of interviews, talked with a lot of hiring managers and interviewees, and read a lot of articles on the subject. And when I've posted pieces of the information I've gleaned on forums, it's been generally well received so I thought I would put it all in one place. This is not meant to be a definitive guide. But these are some thoughts that might help people.
Take all of this with a grain of salt. There are very few indisputable laws of getting hired - at least ones that aren't already incredibly obvious. Different companies will have different cultures and their hiring managers will have different personalities and different things that impress them and that turn them off. And there may be regional/country differences. But this is what I've experienced or learned and it may help others.
I ask that people not plagiarize this document. If you quote sizeable sections, please give credit. Feel free to link to it.
I'll briefly explain my background so you will know from where I'm coming.
I began learning computers in junior high school, learning the programming language Basic. In high school, I took AP Pascal (and did poorly, being an unfocused student).
After high school, after goofing off for a few years, I got a job at a high tech firm working as a technician in the cleanroom. I'd always been good at science and math and they hired me and paid for me to go to school part-time, studying electrical engineering. At work, I found a need for a program to assist in work so I wrote one in Pascal. They loved it. I saw a need for another program so I wrote that - teaching myself C in the process. I started to think I was good at programming, so I took a disproportionate number of coding classes, studying a smattering of Fortran, Cobol, Assembly, and some data structure classes in C.
Then I quit my job. Don't get me wrong - it was a great company. I had some personal and personnel issues and I think my immaturity combined with a little wanderlust got the best of me. I'd gotten up to about the middle of the junior year of my engineering degree but I quit that and my job to pursue my other love: music. I became a jazz guitarist. I immediately got an associate degree in music, then worked as a musician on cruise ships for years, got married, settled down, and eventually got a master's degree in music. I supported myself by playing, but mostly teaching. I mostly taught music but also did some teaching of chess and tutoring.
But I'd always kept my interest in science, math, and technology. Over the years, I'd dabbled in VBA to get some things done in MS programs, and I'd always heard about "object-oriented" and was curious so I'd dabbled in Java and C++. But I never took it seriously until a friend from high school messaged me that he was starting law school. What?!? At his age?!? In his mid 40s? It sounded insane. But then I thought: If he can do it, with no legal experience, then why can't I do it for programming, something in which I had a little experience and an aptitude? I researched it and found that web dev was one of the few careers where someone has a chance to do pretty well without a degree. Money had gotten tight. That may not seem important when you're young, but as you get older you start to think about things like, "Where am I going to end up?" My wife and I had a dream of moving to Barcelona and having a more portable, lucrative career would really help.
I found Free Code Camp and started there. I worked my butt off. I set goals as to how many challenges I would do a day and usually crushed them. I struggled through a lot of things, but some things started to click. I did this before the React section of their curriculum was fleshed out so I had to teach myself, the same with Node/Express/Mongo. I decided I liked React so I also learned Redux, Redux-Thunk, and Redux-Router. I also made a few things in React Native.
I started applying for jobs like crazy. I probably sent out 500 applications, did 30 coding challenges, 20 phone interviews, and about 10 times I got to the second interview. Along the way, I did a few freelance projects in React Native. In the last week of the job search before accepting an offer, I was in the final stages (down to the last two or three candidates) with three companies, all at once. That is a testament to the fact that job hunting is a skill - in a year of job hunting I only made it to the final stage 3 times, all in the last couple weeks.
So I landed a dream job. For those of you in the job hunt, that translates as "any job that pays me and allows me to keep learning." But it really is a great job. First, the negatives. I had to move 1000 miles to a semi-rural area (I'm a city boy), and it separated me from my wife (physically, not emotionally, and hopefully temporarily). On the positive side, it pays really well, I'm learning a lot, and it is a great bunch of guys and gals - really, they are the best, I couldn't hope for a better work environment.
There is a lot of BS being said about web dev jobs. I once read someone say about the web dev job market that it was so starved that if someone spent 24 hours with JavaScript for Dummies that they could land a job. I wish I could slap that fool.
There are also a lot of bootcamps telling you that you will land a job after their course. That is questionable. Don't get me wrong - I'm sure you can learn a lot there and it will increase your odds of getting hired, but there is no guarantee of a job or a quality job.
And there are a lot of blog posts saying as much. "I learned to be a web dev in two and a half months!" These are comical. I once saw one of those and read it and found out that he'd spent a decade in IT. Sheesh. I'm sure there are a few people that land a job that quickly. It's maybe not the best job but it is a foothold - good for them. Maybe it's an incredible job - I'm happy for them. But you also read about people that fall out of airplanes without a parachute and survive. Good for them. But that doesn't make it a good idea.
Unless you are very lucky, this is a marathon and not a sprint. It may take years. You will fail many times. Thomas Edison was once asked about failing 1000 times before getting the light bulb to work. He famously replied, "I didn't fail 1,000 times. The light bulb was an invention with 1,000 steps." That is how you have to think. Another great joke I like to use:
Two guys are walking down the street. A beautiful woman is walking the other direction. The first guy says, "Hey, wanna have sex?" She slaps him and storms off. The guys keep walking. The second guy asks, "Man, you say that to all girls you meet? You must get slapped a lot". The first guy smiles wryly and replies, "Yeah, I do get slapped a lot, but every now and then..."
That! That is the attitude you need. It doesn't matter how many times you fail. What matters is keeping at it (and hopefully learning and getting better) until you succeed. It doesn't matter how many jobs you don't get. What matter is the one job you do get.
But disabuse yourself of the idea of getting a job fast. There are great jobs out there and one (or maybe a few) has your name on it. But it's going to take time and work to get to it. And learning coding is only part of getting the job - there's also your resume, your interviewing skills, networking, your portfolio, etc.
And I would argue that it is a good thing that this is so hard. (That's what she said?) If this were easy, everyone would do it and it would pay minimum wage. The more we have to struggle to get the job, the more our salaries and job security will be.
This question gets asked a lot. Is it worth it? I would say that in the degree program, you are going to learn a lot, and a lot of technical things that you may not pick up otherwise. You will also meet a lot of people to add to your professional network. And having a degree tells the employer that you can learn, set goals, and finish something.
Do you need it? There certainly are jobs that will only hire CS grads. I think these tend to be larger, more conservative companies. Is it a BS (no pun intended) requirement? Maybe sometimes. But maybe they know that they need people familiar with concepts that non-CS grads don't tend to get. Maybe they've had a lot of bad experiences that have taught them. Maybe they are concerned about liability about someone getting hired and making a big mistake. Some of these companies deal with vast sums of money or even people's lives - that's a lot of liability. At least if the gal they hire has a degree, they can say they did their part. If they get into court, they may not want to have to explain why they hired some 22 year old with a year and a half community college that made a mistake that cost a client 17 million dollars because he never really learned about hashing algorithms or blockchain but thought he understood them because he watched a few YouTube videos.
Do you need the degree? No. Does it increase your chance of success? Probably. I will say though that there is probably no technical field where you are more likely to land a good job without a degree than web dev. I think it boils down to your personality and what kind of work you want to do. One nice thing about going to college though is that you will make a lot of connections and be guaranteed of a well rounded base of knowledge.
These have grown over the years. And as the market has flooded, some have gone out of business. They make outlandish promises. And sometimes they deliver.
I can see the advantage of getting into an environment surrounded by people who want to learn to code and that's all you do for 12 weeks (or whatever). To be honest, if my life situation had been different, I might have done this.
Does it land you a job? You certainly learn a lot. And you network a lot and many bootcamps help their alumni find jobs. I've seen several ads for people that specifically want bootcamp grads. I've also seen a few that specifically don't want bootcamp grads (or at least with only the bootcamp). One hiring manager told me, "If I have to interview one more bootcamp grad with only a superficial knowledge of Angular and Ruby and a few cookie-cutter apps, I'm going to kill myself."
Again, I think it boils down to personality.
There is also the self-taught route. This is the one I ended up doing, with the help of a free online bootcamp, a few books, and a lot of YouTube videos. Granted, it fit my personality well as I have always been curious, am methodical, love to learn, and love researching things. (These are great qualities for coders, btw.)
There are a lot of resources out there: books, blog articles, YouTube videos, pay videos, Stack Overflow, etc. Really, there is nothing you can learn in a CS degree or a bootcamp that you can't learn at home. The question is will you learn it. Do you have the will power to learn things, even the boring parts? Some people do, some people don't.
There are also some negatives to being self-taught. It is hard to gauge your progress. In a forum where I regularly participate, you have no idea how often I have to help calm down new self-taught coders because they are freaking out because they cannot understand JavaScript closures after a three minute lesson. They think they're the only one - they assume it is easy for everyone else. And you miss out on networking possibilities and learning opportunities from interacting with other coders (Don't underestimate this.) If you live in a developed area, you can find a meetup to help with these, but if you don't it might be more difficult. It can get lonely.
Should you self-teach? Again, it's going to depend of life circumstances and personality.
There are so many great resources out there.
- Books - You can buy books, but there are also books at the library and free e-books you can download. You name a subject, someone has written a book on it.
- Videos - There are plenty of wonderful YouTube videos out there. Seriously, once my student loan is paid off, there are a few guys to whom (if they have a donation button) I will be sending a c-note. There were many things I would have never gotten through without their help. I loved to code along with other people as they built something. Granted, they're not all perfect. Sometimes they would be using deprecated versions of a library. Sometimes they would add unnecessary complexity by using other libraries that were not required by the problem. Sometimes they would go too fast or skip steps. But still, if you look hard, you can find something.
- Pay Sites - There are definitely sites out there willing to charge you money to learn something. Granted, there is probably nothing on there you can't learn elsewhere, but it might be organized and packaged nicely. I've done a few of these and enjoyed them.
- Free Sites - I have to plug Free Code Camp here. Without them I wouldn't be here (they probably should get a few c-notes once the student loan is paid off). It's a non-profit, open-code tutorial site focused on the MERN stack. I'm sure there are others out there. Even some pay sites have some free stuff - I learned redux by watching some free Dan Abramov (the guy who invented it) videos on egghead.
This can't be stressed enough. Some people get the idea that if they study for a year or whatever, they will know what they need to know. But the field is too immense with too many branches and specialties. It is unlikely that you are going to find the perfect combination for the job that you want. Even if you could, it's going to keep changing - language specifications change, libraries evolve, APIs get revamped. You need to keep learning. If you don't love learning, this may not be the field for you.
This also can't be stressed enough - build stuff. This is from where your real education comes. I always say, "You can't learn to swim without swallowing a little pool water." By that I mean that you could read all the books on swimming in the world, listen to lectures by experts, and watch videos of olympians - but until you get in the pool and struggle and almost drown a few times, you're not really going to learn. The equivalent of this in web dev is building things. You've got to build some apps and sites. You'll make mistakes - that's OK, you'll get better. You won't believe the number of people with whom I spoken that want to know if they are ready for the job market but don't know how to set up a simple static web site.
Don't get me wrong, all those tutorials and such are great at getting you ready. But you actually need to build things - actual apps and sites. And the apps and sites you build from tutorials don't count. Interviewers can smell those from a mile away and roll their eyes. They don't want to see if you can copy the Mona Lisa. They want to see if you can create your own work of art, from beginning to end, choosing the subject, the medium, the style, the tools, the paints, and execute it like an artist. That's what they want to see. When I interviewed and they looked through my portfolio that's what interested them. 90% of their attention was on the stuff that I'd built of my own volition, even thought that probably only represented 25% of my portfolio.
I'm not saying not to include tutorial stuff in your portfolio, but only the best stuff and you want some "from scratch" stuff at the front. Ideally you will keep creating stuff and gradually that tutorial stuff will get pushed off.
Most people start out with the frontend. That's fine. But you want to learn at least some backend at some point. I don't think there are many jobs now for people that are strictly frontend or backend. Let me rephrase that - those jobs may exist, but you will often be expected to know something about the other side. I often see ads for a "frontend position" but then tell me I need "Ruby/Rails and SQL". And backend people are often expected to know the basics of frontend.
I would argue that learning the complete stack (even if only partially) will greatly increase your understanding. After learning the frontend, there were many things that I thought I understood that really didn't truly make sense until I started building my own servers.
Any Game of Thrones fans out there? They have these scholars called "maesters". They wear these necklaces/chains with metal links in them. As they learn a new field, they get a link for their chain that represents that knowledge. If you see a maester with only a few links, you know he's a novice. If you see an old guy that's almost being crushed by his chain, then you know he knows his stuff. That's what you want to be. You want to collect new libraries, frameworks, paradigms, languages, etc. You want to always be thinking about what you want to add to your collection next.
You can't learn everything about everything. Should you learn everything about one stack (if that's even possible) or learn a little about everything (if that's even possible).
There was this old TV show called The Love Boat. It took place on a cruise ship and the ship's doctor (a generalist) was talking to another doctor/friend (who was some kind of a specialist). His friend teased the doc that a generalist was someone that learned less and less about more and more until he knew nothing about everything. The doc chided back that a specialist was someone that learned more and more about less and less until he knew everything about nothing.
My advice would be to focus on a stack, one complete set of tools from front to back, and all the libraries that go along with that. Once you get pretty darn good at that, start getting at least a superficial knowledge of what else it out there. Maybe also pick up a new stack. But in the beginning, I think it's good to focus on one stack. Become a specialist in one stack before becoming a generalist in some other things.
You need to "brand" yourself. You need a professional email (I know your friends think booblover69@hotmail.com is funny, but it will land your resume in the trash.) Create an email account, separate from your personal account, with a professional sounding name. If you want it part of your portfolio site account, even better.
Get an email, web domain name, LinkedIn, Twitter, Facebook, YouTube channel, etc. Even if you don't plan to use them right away, claim them. Ideally they should all have the same or similar name. There are sites that will check all these things to see if a name is taken on them. If you are cursed with a very common name (like me) you may have to find a way to make it unique.
A professional portfolio site is an important tool, it is your primary form of advertising. Whether you want to work as a freelancer or are trying to land a "real" job, this is your billboard. It needs to be a good site. Here is what I think a good portfolio site should have:
-
Your Name and Contact Info You should have some contact links, probably in the navbar and probably repeat them at the bottom of the page. Maybe the most important links at the top and the full list at the bottom.
-
Who You Are A brief description (1-3 sentences) describing yourself. Who are you? Where are you based? What do you do? What is your goal?
-
Sample Projects This is perhaps the most important part. You need good projects. Every project should have a screenshot, a description, a link to a working version, and a link to the code (assuming it isn't proprietary). In the description there should be a description of the techs used. If you are still learning you can talk about the things you learned or challenges you overcame. If this gets big, it may need a "more" link and a modal or something.
-
A List of Techs You should let them know what you have used before. You don't have to be an expert in them, but you also shouldn't pad this with libraries just because you cut and pasted some code off Stack Overflow.
-
Who You Are (Cont.) Maybe this is optional, but I think it is a good idea, especially if you are job hunting. Include a few paragraphs about who you are as a coder, what was your path. This is your chance to personalize yourself to them and invest them in your story.
-
Resume There should be a link to a downloadable resume. Yes, there are still some people using paper.
Things to avoid in a portfolio site:
-
Coding Mistakes: I've seen many portfolios with horrendous errors in them, throwing errors in the console that they never see because they don't even know how to read the console. At the very least, all your code should go through a linter and validator. There are sites that will test how fast your page loads and even suggest optimizations.
-
Bad Site Design Never stop developing it. Every few months, you are going to be getting a little better - go back and check out the site and see if you can make it better. Have some friends (coders or not) check it out and see what they think. Go and see other coders' sites to get ideas.
-
Kitchen Sink Sites I've seen a few sites where some coder wants to show off every trick he can think of - everything was blinking or spinning or shaking in different directions. Yes, they know you can do basic CSS. Don't overdo it. Less is more.
-
Spelling/Grammatical Errors I know it's hard to proofread your own stuff. I'm actually a pretty good proofreader - of other people's stuff. When I try to proofread my own stuff, I just hear what I meant in my head. But read slowly. Double check the spelling of any word you question. Run the text through online sites that check spelling and grammar. Have friends read it. Make sure all the tech words are spelled and abbreviated properly. They might roll their eyes if you write "Javascript" instead of "JavaScript". It may seem petty, but every little thing matters. You're trying to show them that attention to detail is important to you.
-
Useless Information They don't care that SCUBA dive or love Thai food. I once saw a site where the title listed four occupations, like: DJ - Freestyle Dancer - Comic Book Artist - Web Developer. I suppose he thought that sent the message that he was creative and multi-dimensional. To a potential employer it screams of being unfocused and not that serious about coding - he has too many interests and coding is the last on his list. There will be plenty of chances to fill out the image of who you are in the interview process. You don't need to scream it at the top of your site.
-
Clutter Often more is not better. Keep in mind that potential employers are often looking at dozens or even hundreds of sites/resumes a day. They may just scan your site for five seconds (or even less, I'm not joking) and decide if it is worth their time. You want keywords to jump out at them. If your site is cluttered (with bad design or irrelevant content) you just lost that opportunity. Everything on that page should be towards communicating what kind of coder you are, as effectively and efficiently as possible. Anything that gets in the way of that is hurting you. Seriously, look at it and see what you can get from it in five seconds. What jumps out? Is it formatted enough that your name, what you do, and what techs are your strengths jump out? Seriously, you often only have those five seconds to get that information across.
A resume is also an important communication tool. Some employers will see this first and this will be your only chance to make an impression.
There are a lot of different opinions about resumes. I tend to fall into the "conservative" camp. I'm not saying you can't have a little bit of fun, but you need to keep things within reasonable bounds. I see plenty of resumes that are just inscrutable messes. It reminds me of that line from Shakespeare: in making fun of someone who thinks they are being more clever and learned than they are but is in fact impossible to understand, a character sarcastically described him as "too cunning to be understood". I've seen several resumes where the candidate tried to be creative and clever but ended up making a puzzle for the hirer to parse before he can begin to glean the information that she needs. Your goal should be to make things as easy as possible for them, for them to quickly and easily find all the information they need and not get distracted by things they don't need. Being a little artful is fine, as long as it doesn't prevent the reader from getting what they need quickly - that is the most important thing.
Resume or CV? What is the difference? Here in the US, we tend to use them interchangeably, but they really are a little different. A CV (curriculum vitae, "life course") is really a look at your life. It tends to be a little longer and can be more chronological. A CV will never (in theory) change depending on the job you are applying for. On the other hand, if one person is applying for programming jobs and journalism jobs, their resumes for those two categories will be different. I think most employers (at least here in the US) are looking for a resume, even if they say CV. If you really, really, really want, you can include both, with the resume on the top. But you'd probably be better off without it.
Your resume is a technical document. Who are you? What is your contact info? What is your relevant education history? What is your relevant employment history? What other relevant skills do you have? In the case of a coding resume, you might list some sample projects with some links. Links can be good - many employers will view an electronic version links to your work could be handy. Yes, you included a link to your portfolio with your contact info, but they are too lazy to look for that. Always assume that they are lazy. Always. (OK, to be fair, maybe assume that their too busy.)
Things to include in your resume:
- Name and Contact Info
- Relevant Employment History
- Relevant Education History
- Relevant Skills
- Languages Spoken This may seem trivial (especially with the ranting I'm about to do about things not to put on a resume) but it can be a relevant skill, will be important if you apply for international jobs or if the company does international business. And it only takes up one line.
What not to include in a resume:
- Every Job You've Ever Had I once saw a resume that listed every summer job he had through high school. They don't care that you were a "ticket confirmation engineer" at the movie theater at the mall one summer. Only jobs relevant to your position should be listed. The exception is if you have a long gap in your employment history. For example, I had two decade hiatus from technical work, doing many jobs. Originally that took up ten lines of my resume. I eventually parsed it down to two. It was enough for them not wonder if I was unemployed for a few decades, but not enough to distract them from the meat of what I want them to know.
- Too Much Information About Irrelevant Education History You may be proud of your BA in Icelandic Art Studies, but you don't need to dwell on it. Include it, by all means, but it should be one or two lines.
- Irrelevant Skills Again, they don't care about your CPR certification. Only things directly related to coding and the job. Don't tell them you are adept at Word and Excel - so it everyone else. (If you write professional grade macros, that is something else.)
- Hobbies or Personal Interests Really, you breed tropical fish? You think that's a good thing to waste on the five seconds the recruiter will be scanning your resume? If in the interview, they ask what you do for fun, then you can tell them you love to SCUBA dive. But on a resume they don't care.
- A Photo of Yourself Unless this is common in the country where you live, don't do it. I know they do this in some countries, but not usually here in the US. I once heard of a resume with a picture of herself as a baby. Creepy.
- Inspirational Quotes
- Marital Status or Religion or Disabled Status Basically you shouldn't include anything that might be the basis for illegal discrimination. This isn't so much to protect yourself against someone discriminating against you, but it might make them a little uncomfortable. "Now that I know that she's a Muslim in a wheel chair and married to another woman, is she going to try to sue me if I don't hire her?" They might even think that you're trying to do that to get an advantage. Your job is to make them as comfortable as possible. True, a disability may eventually require a special accommodation, but you that can be dealt with later. Certainly wait until it is necessary to discuss or until they broach the subject in an appropriate manner, at an appropriate time. Let me be clear, I'm not saying that you need to be ashamed of any of this - just that there is a time and a place for this to come up.
- Distracting Designs I've seen crazy, distracting curly-cues. I've seen a resume where the background was a photo of the applicant (leaving the text almost impossible to read.) I've seen resumes where nearly every line was a different font. (Please - one font for headlines/titles and one for body text and logical hierarchy of a few font sizes. And be consistent.) I saw one where it looked like a video game screen with "power levels" for each of his skills. (What do you think that told the employer about the applicant's mental age?) I saw one where it took me a minute just to figure out how things were organized.
- Lies Don't flat out lie. A little puffery is OK, but don't just make stuff up. It will come back to bite you. I had a friend who referred to himself as being a master at SQL. That month before they finally fired him was hell.
- References Don't include references in your resume, and for the love of Thor, do not put "References available upon request." at the bottom. They know that. You're just eating up valuable real estate and wasting their attention.
Some last thoughts on resumes:
- It must have a white (or really transparent) background! Seriously, some people still print these things out. How do you think their going to feel about you if you just drained all their color toner because you wanted an indigo background color on your resume? If you print your resume, an off-white quality paper is fine, but the base background color in the file should be white/transparent.
- Number of Pages If you have an extensive relevant work and relevant education history, then two pages are OK. But if you're reading this, you probably don't so try to cram it into one page. This will also be a good exercise in parsing things down.
- Multiple Formats A pdf copy should be your go-to, but some places will insist that you give them a Word copy. It is also good to have a properly formatted text version - some online applications will only allow that. So, write it in Word (or something that allows you do save it to a docx format), also save it to pdf, and spend some time exporting it into text and then making sure the formatting still makes sense - it may take some major adjustments. It's handy to have these formats ready in case you get a last minute scoop on a job, but they insist on a txt file - you don't want to be hastily figuring out how to convert your nice columned Word document into something that makes sense in a top-down text document. You want to have it thought out and ready to go. And every time you update your main document, you want to update the others too.
The cover letter is a different animal. Whereas your resume is a technical document, a cover letter should tell a story. It is the story of how you found out about the job and why you are the right person for the job. Why are you the right person for this job? How would you fit in the team? You can also talk about your work history a little in a more narrative style. If you don't have a long work history, talk about your path to coding. Talk about projects relevant to this job. This document is a chance to connect with them as a person.
Unless you have an amazing story to tell, this should probably be one page. It would be nice if it had the same header as your resume. Whereas the resume is general, this can (should) be specific to the job. If you know the name of the person doing the reviewing, address them (formally) by name. Did you research the company/job? Can you use some of the actual words and phrases from the job posting?
A lot of places don't ask for cover letters anymore, but I think it's a good idea. The worst they can do is ignore it. But it also imparts a level of seriousness. Traditionally, the cover letter should be adjusted for every job posting. Or course (if you're like me) you're going to end up doing hundreds of job applications so you can't really do one for each posting. I had a general one to which I would make minor adjustments for each application. If it was a job where I felt I had a good shot, I might spend some more time on it.
For references, just make a nice list of people's names, their contact info, what their position was, what your position was, and a when you worked with them. Make sure they know you are using them as a reference! And make sure they will be good references. Some workplaces has a "no references" policy for legal/liability reasons and will only confirm that you worked there and if you quit, were fired, or where laid off. Also keep in mind that these are professional references, not personal references. They want people for whom you worked, or at least people with whom you worked. They don't care if your buddy "Spazzy Mike" from high school thinks you're a "cool dude".
Not all, but some employers rely very heavily on LinkedIn. Some recruiters exclusively hunt there. Many will check your profile to see if they can take you seriously. Have a LinkedIn profile.
I've said it before and I'll say it again - the odds are that this is going to be a long, difficult, struggle for you. It will seem like it will go on forever. But just remember that once you get that job, and build some experience, things get easier. Here are some ideas about the hunt.
Often the first place you look is job sites. Indeed, Glassdoor, Monster, LinkedIn, etc. Stack Overflow has a nice jobs search section and angel.io is a nice site for startups. Learn to use their filters. Apply, apply, apply. It's a numbers game. I applied hundreds of times. Don't apply to everything. Don't apply to things for which you clearly would not qualify. But if you're close - why not?
A word on job listings. Some of them are just insane. I've seen ads for entry level positions that wanted a master's degree, five years of experience, and ten different languages. I saw an ad for an internship that wanted a degree and two previous internships. In 2018 I was seeing ads requiring five years of React Native experience - quite an expectation considering it dates to 2015. I've seen tons of ads with bizarre and redundant technology combinations and things that made no sense.
The explanation that I've gotten is that these are often written by some secretary or someone in personnel. They ask the different engineers what they want so they get a laundry list and then it gets filtered through the brain of someone that isn't a coder. What you get is a mess. Take the ads with a grain of salt. If you have most of the major categories and are in the ballpark of experience - go for it. Also remember that they may have other positions available.
Once you get your name out there, you will start getting contacted by recruiters. Ugghhh. At first it seems amazing. All these people are calling and emailing me! This is amazing! Unfortunately they are largely full of crap. But sometimes they get you jobs. I think that they probably aren't usually recruiting for entry-level positions - those are too easy to fill - but who knows. I consider that there are three types of recruiters:
-
Recruiters That Work for the Company - These are your best bet. They actually talk to the devs and have a much better idea about what they need and if you have a chance. These are the rarest.
-
Recruiters That Work with the Company - These aren't quite as informed but still have a chance of getting the right information. They may be somewhat informed about the technology. This is the kind that eventually got me my job.
-
Independent Recruiters - I don't know what else to call these people. These are the ones that will annoy you to no end - and are unfortunately the most numerous. They play a numbers game. They scrape job sites for key words and spam as many people as possible. They usually don't understand the technology. They try to get everyone they can to apply for every job they have. They probably work on commission. They are easy to spot - they are usually calling from a foreign call center (you hear deafening commotion in the background), have an accent, and use overly formal language. They can often be very difficult to understand. At the risk of being accused of racism here, many of them have a pronounced Indian accent. Don't get me wrong, I've known (and work with) some great devs from India - it is a nation of 1.3 billion people with some excellent tech schools. And some of the "good" recruiters I've encountered were also from India. But a striking majority of the "bad" ones were from India. I could usually tell the difference because the "bad" ones were usually in call center, spoke in overly formal English (at least by American standards) and clearly had never read my resume. Eventually I started to hang up on them as I was getting 5-10 of these calls a day and they never went anywhere. On the calls that I took, I got good at cutting through the BS. As an example, one guy kept insisting that I apply for a Java job. I do JavaScript and explained that are different things. He excitedly kept insisting that it was probably "close enough" and should apply. I couldn't convince him and had to hang up on him. Their emails are usually easy to spot too - they often have the word "urgent" in the title, the body of a mess of fonts because they cut and pasted it, and they often have roughly the same list of boilerplate questions (many of which they'd already know if they read your resume). If you want to deal with these people, find out immediately what techs they want and how much experience they want.
This can't be stressed enough - a lot of job opportunities will come from people you know. Go to meetups and meet people. Talk about your hopes. Talk about what you're building. Ask other people the same. Try to think of dev as a social activity.
Maybe they know someone with a job for which you are qualified. Maybe the opposite is true. Maybe they can critique your resume or portfolio. Maybe they can review your code or work with you on a project. You could learn some cool things by returning the favor. Seriously, coding should be a social activity. Get out. Meet people.
Hook up with people on LinkedIn. If you want to work at a company, try to find a recruiter or dev. Find them on LinkedIn. Or email them. Ask them some questions. You'd be amazed how many of these people would be perfectly happy to spend some time giving some advice.
I divided my job search into four categories. They could be in my specialties (React, React Native, Node/Express/Mongo) or general (web dev). And they can be local (the San Francisco Bay Area) or require me to move. Those combine to four categories. You may have to consider moving. Figure out what you would need financially to move. What if it's an expensive city? What about a cheap city?
What companies to target? There are couple of factors here:
-
Tech Hubs - When I started, I assumed that living near Silicon Valley would make my search easier. I soon realized that although there were a lot of jobs there, there was also a lot of talent. And the companies often had high (sometimes ridiculous) expectations. What about secondary tech hubs? My break was a job at a big company, but in northwestern Arkansas. These are all possibilities to consider.
-
Size/Age of Company - I assumed that a small startup would be the easiest. Maybe they would be willing to take a chance on someone, especially since startups often can't pay as much. But I found that they were also often so small that they needed someone that could do everything. If you can only afford three coders, they each have to be able to pull their own weight.
-
Internships - I have mixed feelings about internships. All too often they are looking for free work. I've heard a lot of bad stories, but in all fairness I would have to admit that I've heard some good stories too. (For example, the company for whom I work now treats interns very well.) But ask questions. Find out what they will have you doing. Find out if there is any pay or stipend. Decide if you can live with it. Find out how often they hire their interns.
I think of an interview like a first date. It's a chance to show you at your best. Your date knows that you won't always have a fresh haircut and shave, you won't always have a new shirt, you won't always be on your 100% best behavior. But if you can at least clean up that well, then maybe your day-to-day isn't that bad.
Interviewing skills are often overlooked but are so important. So are things like your portfolio and networking, but people know that. I'm always amazed that so many devs don't think about interviewing skills. They just assume that a great portfolio will be enough. But there are a lot of great portfolios out there. How are you going to stand out?
I used to be a professional jazz musician. A bass player friend of mine used to say something like, "Hey, I know I'm good but I also know I'm not the best. I have reached a certain level of players and that is my cohort and we have roughly the same level of skill and compete for the same gigs. But I try to be the nicest guy on the gig, show up on time, dressed properly, ready to play - that's why I get hired first." That's the guy you want to be.
We tend to think of interviews as being a face to face thing, but more and more technology is changing that. There were times when I was literally 15 minutes from their office, but they insisted on a phone interview. It's safer, easier, and quicker for them.
Speaking of "easier for them", I noticed an odd "coincidence" with video interviews. Especially when dealing with agencies or personnel people, when doing a video interview, they start by apologizing that their camera "isn't working right now". After this happened six times in a row with different people, I got suspicious. I guess they just don't want to be bothered with you seeing them. It's also kind of a power move - they can see you but you can't see them. I guess it's their right, I just wish they didn't lie to me about it. I don't think I ever had this happen with a programmer interviewing me.
I can't believe I have to say this, but I've heard plenty of stories of guys showing up in sneakers. Now, this is the world of Silicon Valley and startup culture. Yes, maybe a 3-piece Brooks Brothers suit isn't necessary, but dress up a little. Look like you put some effort into it. Yes, some places may have a laxer dress code. Maybe jeans and a tee-shirt will be acceptable once you get the job, but it may be interpreted as lazy and sloppy if you show up like this for the interview, like you don't care. And this goes for video interviews too. Since you're in your own home, maybe a little casual is OK, but put on a decent shirt and wear adult pants. (This is from a male perspective, of course, "whatever the female equivalent of that is".)
I know this sounds odd, but this is also really important. I had a phone interview with a company in another city. I didn't get the job. But the guy called me a few days later. He said something like, "Hey, I'm sorry you didn't get the job. But I wanted to call and let you know that I think you're doing well and are on the right path. I also wanted to thank you because it was so much fun to talk with you." He explained that with so many of the people with whom they talk, it was like talking to a block of wood.
Remember, these people are auditioning you to see if they want to spend 40 hours a week with them. That is more waking hours than they will spend with their spouse or kids. What kind of person are you going to be? I've managed to talk to some interviewers and gotten to hear a few interviews from the other side. Here are some common "sins".
- Boring - Put some inflection into your voice. Sound interesting. If you're on the phone, you have to project with your voice what your body language would normally do. For some of us this is not natural and takes practice.
- Lack of Confidence - Being modest is one thing, but if you talk about yourself as someone who can't do the job, you will convince them. You can be honest that you don't know something and still project confidence and eagerness that you can and will learn it.
- Too Much Confidence - Obviously you can take it too far.
- Argumentative - Seriously, it happens. I've heard this from people. I also had a friend tell me about arguing with an interviewer about some point of JavaScript. Now, it turns out that my friend was mostly wrong. But even if he wasn't - why argue? Would you hire someone that argued with you in the interview?
- No Sense of Humor Lighten up. Have a few humorous (but short) stories to throw in. A few quips. One of my old standards, when I make a mistake and find it in a coding interview is to smile to myself and almost under my breath say, "You know, the problem with computer programs is that they always do exactly what you tell them to do." It shows that I know I made a mistake and that I have a sense of humor about myself. I heard of an interview with a guy that started cursing at himself, yelling after every mistake he made. Would you want to work in the cubicle next to that guy?
- Not Listening I made this mistake once. It was an algorithm challenge and I was just not getting it. Later, when I thought back to what was said, I realized that he was actually trying to steer me in the right direction, to the right approach. But I just kept pig-headedly trying to solve it "my way". When I solved this on my own the next day, I found out that my way would never have worked. He was trying to help me but I didn't listen. What type of an impression do you think I made?
If you're like me, you do not enjoy talking about yourself, especially not bragging. But that is exactly what you need to learn to do. Is she being modest? Is she incapable of articulating what she's done? Has she just never done anything worth saying? How are they to know?
Like anything, you need to practice. Seriously. I'm not joking. Google "common interview questions web developer". Make a list. Answer them out loud. No, I don't mean to kind of run through them in your head. I mean to actually answer them out load. Get a stuffed animal or a picture or a lamp or whatever, pretend that it is interviewing you, and answer the question to it. Sit up, pretend you are in an interview. Look it in the "eye" and gesticulate just like you will and practice speaking in a full, clear, articulate voice. Smile. Project confidence. Do this every day until it flows naturally. Find a friend and practice interviewing each other.
You also should be able to ask questions. This is often the end of the interview and is your last impression. Did you research the company? Can you ask about their tech stack? Where do they plan to be in five years? What learning opportunities do they have? What technological challenges are they facing? Another one of my favorite things to ask is, "What could I have done better in the interview? And are there some other skills I should be working on?" This shows them that I'm interested in self-improvement and can be an incredible source of information for you. I've had a few 30 minute conversations with these guys that taught me so much.
At some point you're going to get a coding exam. There are different types. You may be asked to do them in front of them. Tests can be easy or hard. You might be asked to code a basic site, write a specific function, troubleshoot existing code, or do some algorithm challenge. Sometimes you have to take a multiple choice test to assess basic knowledge.
Don't get disheartened if the exam is too difficult. Sometimes they deliberately make it too hard. If everyone can solve the problems, then how does it help them choose? Furthermore, if you are coding this live or over video, they may want to see how you fail. What did you consider? What was your thought process? Did you throw a fit? Did you calmly work through the problem and make progress or did you throw a fit and give up?
There is only so much you can do to prepare in the short term. Either you will know how to code it or you won't. I can't help you with that. Obviously, becoming the best coder you can will be helpful, or course. But there are some things you can do in the shorter term.
Learn how to whiteboard. Actually by a small whiteboard and when you have a coding problem, some little algorithm you need to solve, write it out in pseudo-code. Besides being a great skill, you may have to do this in an interview and it will look great if you do it gracefully.
Probably biggest on the list is learning algorithms. A lot of you are thinking ugghhh right now. Algorithms get a bad rap. They are not directly part of coding, per se, but they are an important part of being a computer programmer. It's the difference between being a good speller and grammarian and being able to tell a story or write an essay well. You can know all about the ins and outs of your language but still can't solve a presented problem with an efficient and elegant solution. Both are important skills. Algorithms help you develop the latter. People still argue that they aren't "the real thing". I think of them as jumping jacks. Our soccer coach used to make us do lots of jumping jacks, pushups, and run laps. None of those things ever won a soccer game. I could say the same of passing drills - we never ran a passing drill during the game. But they made us stronger players. Multiply that by 1000 for algorithms and coding.
There are so many places to get algorithms on which to work. There are great sites like Hacker Rank and Code Wars. They provide an interface for you to try to solve each challenge. You can choose a language. You can check if your solution passes. After you solve it, some sites let you see other people's solutions (this can be an amazing learning opportunity).
A word of caution: There are different kinds of sites. Some are very well run. Some use user generated content and some of it can be questionable. Some of these challenges are thrown together quickly and haphazardly. They may be poorly explained or based on faulty assumptions. They may have unexplained edge cases. Some of these people are trying to show off or enjoy the idea of trying to trick people. Cavaet programmator.
Even a well run site can be frustrating. They may have extreme edge cases that you have to assume. They may have time constraints that make your solution not pass because it is not efficient enough.
Yes, that can all be frustrating. But in some ways it's good preparation. Those are the same pressures you'll feel in a coding exam. Learn to deal with them. Learn to deal with them gracefully.
There is more than one way to skin a cat, as the saying goes. One of the most useful things is to learn multiple ways to solve the same problem. Part of being good at algorithms is being able to see in your mind's eye multiple solutions to the same problem, and use your Spidey-sense to figure out which one will be the best. This is a skill that you hone by doing lots and lots of algorithms. Lots and lots.
I don't know where you will come down on the "Should a coder learn algorithms?" debate. I fall into the "Of course, it's really important, don't be an idiot! It's not all there is but it's really important!" camp. That being said, if you don't want to actively study them and just want to wing it, I think at the very least, a coder should be familiar with these algorithms and concepts:
- fizzbuzz - This is one of the most common algorithms there is. It's the algorithm equivalent of "Why did the chicken cross the road?" If you can't solve it, you won't get passed the front door. It sounds extremely simple, but solving it elegantly can take a little thought. I've encountered this or variations on this in about 20% of my interviews. There are one line ways to solve it and more "reasonable" ones that take a few lines. Have them both from memory so you can ask the interviewer which they want.
- basic number theory - Even though they may not come up in coding as much (and certainly not web development), they are very common in algorithms. Prime numbers, squares, the Fibonacci sequence, lowest common denominator, etc. We're talking about junior high school level math here. Beyond that, do you know what triangular numbers are, for example? You don't need to be a math wiz to be a programmer, but you do need to know some basics. And if you want to be good at algorithms, you'll have to collect a few oddball concepts to be good at algorithms. What concepts do you need? Just start doing algorithms and you'll find out. And depending on your field, you may need some more advanced concepts. For example, if you are going to work on ballistics in 3D graphics, you are going to have to know some basic physics and trigonometry.
- The Sieve of Eranthosenes This is a very, very old algorithm for generating prime numbers. You should be able to do it from memory.
- permutations If you're given a string, like "abc", can you come up with all the possible permutations? "bac", "acb", etc. There are 6 in all (counting the original). What if there were 4 letters? What about 14?
- recursion This is where a function calls itself and is available in most computer languages. Whether or not recursion is ideal is debatable - there is nothing recursion can solve that iteration can't solve and usually faster - but recursive solutions are often elegant, sometimes easier to read, and (more importantly) interviewers find them sexy. They love recursion. Granted, I'm not saying there is anything wrong with recursion, it just disturbs me the way it is worshiped. But one thing recursion does show is that you have a mastery of functional programming and can think very abstractly.
- memoization This is the concept of storing data so they don't need to be recalculated. This can save a lot of CPU time on some algorithms. The solution of the Sieve of Eratosthenes is a good example.
Seriously, the more of these concepts you collect the better. They make you a better mathematical thinker and a better coder. And the more effortlessly you can do these, the more you will impress an interviewer. If you have to struggle to generate a field of prime numbers that looks bad. If you can effortlessly write out a recursive algorithm to generate permutations, that will get their attention.
I hope you learned something. But if there is one thing I want you to remember it is to not give up. Just keep at it.