Getting a Job as a Front-End Web Developer

A post to centralize the advice I keep telling various people.

I’ve had a number of people in the last several years approach me with questions on how to get into web development as a career.

This will be less a step-by-step guide and more a conceptual overview. There are a billion websites out there now that teach you the detailed “how”. I’ll try to elaborate on the “what.” [0]

Practically: Why Tech?

  1. I can't think of an industry where the job market is as good without a steep educational cost of entry. It's simple enough to see why. Look at how many people are glued to their phones. Look at how much commerce and media is delivered through the web. I could provide market research/statistics here, but common sense is sufficient.
  2. Depending on local cost of living you can easily make six figures as a mid/senior-level web developer. [1]
  3. You (largely) control your own destiny. But more on that later.

Why Front-End Development? What About Back-End?

I'm writing about front-end development for two main reasons:

  1. It's what I'm most familiar with technically and professionally.
  2. I think it has a lower barrier to entry when it comes to the speed at which someone new to web development can obtain enough skill to do meaningful work. The need to fix front-end (FE) bugs, while tedious, is almost always necessary and available. As long as Internet Explorer continues to exist there will be work for junior FE devs. And the nature of many FE bugs are that they're self-contained; an in-depth knowledge of a code-base is not necessarily required to fix a mis-floated div.

Note: This isn't to say that FE work is easier. Working on the FE and BE of an application can both be very complicated at a production level, and good developers are good developers, regardless of a FE or BE designation. In fact, many of the best developers can do both.

Who You Are

You are X years old and studied Y in college.

I say X years old because it doesn’t matter how old you are. And I say Y in college because it doesn’t even matter if you went to college. It’s not too late to start and nobody cares that you studied English/History/Art/beer pong.

Tech is a meritocracy. [2] Prove you can make something people will pay to have made and someone will employ you so they can get paid once you make that thing for them. [3] Or, even better, cut out the middleman and do it yourself.

Tech is not an industry that cares much for formal credentials. Formal credentials are typically encapsulated by letters that follow a LinkedIn name (e.g. “MBA”, “PhD”) and the $150,000+ piece of paper that you may have hanging on the wall of your bedroom.

The most important metric by which you will be evaluated by potential employers is what you can build. Sometimes formal credentials help with those skills but often they don’t. It’s the beauty of the industry: there are no shortcuts. Credibility isn’t purchased through tuition, it’s proven through effort and delivery.

The most important characteristic you will need is to want to be good. It’s the only thing that will carry you through the frustrations of learning the skills of an industry you’re completely unfamiliar with. It’s what will keep the job fresh and exciting when you’re forced to trudge through less-than-desirable assignments on the job. And it’s what will keep you investing in your own skillset over the course of your career and consequently in your own job security.

The second most important characteristic is don’t be an asshole. Every industry has horrible people to work with and tech is no exception. Being kind to others will take you a long way (both in tech and in life). A positive or negative reputation will follow you wherever you go.

How to Learn New Things

Mentality

Learning new things is not linear. Very rarely is it “I will first sit down to read 100 pages and I will next know everything there is to know about the subject.” It’s a back-and-forth, I-want-to-throw-my-laptop-against-the-wall one minute versus “I AM A FREAKING GENIUS” the next minute process.

Once you internalize/accept the reality that learning anything is an uphill battle, the pain and frustration of momentarily failing to understand something becomes less harsh. It just comes with the territory.

The most important thing to remember is that if you don’t give up, no matter how momentarily bleak it seems, you will figure it out. You are smart. Learning HTML, CSS and JavaScript is not climbing Mount Everest. Thousands of other people have learned how to do the same exact thing you’re struggling with. Everyone starts somewhere.

If you spin your tires for too long ask for help from someone with more experience. Google and Stack Overflow are a programmer’s best friend.

Small projects facilitate learning

Tutorials are great. The web is full of them. But don’t rely solely on tutorials. Complete enough tutorials on a topic that you have a general grasp over how to create something, but modify it into something novel that you have your own vision for.

The best way to learn a new concept is to create your own small project using that concept and finish it. I’ll offer examples of what I mean for each of the points below.

Front-End Development Basics

In this section I’ll cover the most basic tenets of what I think every junior level FE dev should know. I won’t link to resources unless I can vouch for their quality personally. But Google/SO will have a ton of resources on each of these topics.

Note: These lists are not exhaustive. They’re the basics of what I think you’d need to really understand to pass a junior-level FE technical screening. This is the very tip of the iceberg, and there are many more advanced concepts in each of these categories that will help round out FE understanding. Think of these as cursory guides for beginners as opposed to FE-canon.

1. Understand the basic concepts of programming

There are fundamental programming concepts you must learn to work with any language. These include ideas like data types, variables, functions, for-loops, if-else statements, etc.

Any introductory programming book/tutorial/course will cover these ideas. Don’t bother getting into anything that’s too language-specific yet. Language-specific syntax can be reviewed later, when you need it. You just want to get a grasp over the fundamentals that will help with programming in general.

Pick any language to learn these in. There are good resources for this type of thing at Codeacademy.

If I had to offer a suggestion I’d recommend learning the basic concepts in JavaScript, just because you’ll want to learn JavaScript eventually anyway.

Things to Know

  • Data types: string, int, double, char, etc.
  • Variables
  • Functions/methods and passing arguments
  • For loops
  • If-else statements
  • Arrays and how to loop over their contents
  • Key-value pairs and how to loop over their contents
  • Operations: addition, subtraction, modular arithmetic, concatenating strings, substrings, etc.

Small Project Ideas

  • (1) Create an array of numbers, iterate over them and calculate the sum.
  • (2) Do #1, but sum up the odd and even numbers separately.
  • Create a list of full names. Break them out into three lists: first, middle, and last names. Count the frequency of the names in each list.

2. Learn basic HTML and CSS

HTML (Hypertext markup language) is the markup language that is used to structure websites. CSS (Cascading style sheets) are the styles applied to HTML to add color, dimensions, spacing, etc.

If a webpage was a house, HTML would be the bricks. CSS would be the paint.

HTML and CSS are generally simple enough that any first-page google resource will help you in “creating your first webpage.” Go through 2-3 tutorials to get an understanding of different HTML tags.

Things to Know: HTML

  • General HTML structure of a webpage (html, head, body).
  • The Document Object Model (DOM) - What it is.
  • Tags - How to make links, lists, etc. It doesn't need to be memorized, but you should be able to use different tags when you need them from a reference.
  • How to structure the content of a website with divs (div-based markup)
  • Semantic markup - when to use different headers (h1s, h2s, h3s) and tags (article, section, span, etc.)
  • How to embed a .css file into a page
  • (Advanced) How to structure markup that supports accessibility compliance, like for users with screen readers.

Things to Know: CSS

  • How to target different elements on a page, at different depths (i.e. a span within a div).
  • Displaying elements - block, inline-block and inline
  • Style attributes that can be set for colors, fonts, borders, etc.
  • Positioning (relative, absolute, fixed) and floating elements
  • The box model, margin/padding, and what box-sizing: border-box does (note: it will save your life)
  • ids (#id) vs classes (.class) and CSS selectors. Good resource on CSS selectors from nettuts.
  • CSS specificity, or when styles override other styles. See a related project by a fellow hackerschool here.
  • (Advanced) Responsive design -- What is it? What are media queries and how do you use them?
  • (Advanced) SASS, LESS -- CSS compilers. This will make your life much easier, and any modern web shop will be using a compiler nowadays. I will say to only start using SASS/LESS after you write CSS by hand, to both remove the "magic" and to internalize the lesson of how much writing CSS by hand sucks.
  • (Advanced) CSS3: border-radius, box-shadow, text-shadow, etc. Good intro by SmashingMag here.

Things to Know: General

  • Tools: How to inspect a webpage using Chrome developer tools or Firebug (Firefox)
  • Be able to create this layout in HTML/CSS, with both pixel dimensions and percentages. A company I interviewed at used this as a simple FE screener. It's a straightforward and revealing test as far as applying styles, checking markup and understanding floating/spacing/etc.
  • How would you create a site navigation bar using an unordered list as the base element? This involves floating, 'inline-block'-ing, some list-style, etc.

Project Idea

  • Create your own homepage. Start from an empty file in your favorite text editor. [4] Type every line of HTML and CSS by hand. Make it nice and non-trivial enough to show to a potential employer. Consider it as a piece of your resume, because, well, it will be.
  • Buy your own web address (ideally http://www.yourname.com/) at Namecheap for ~$10/year. [5] Buy/find a year of web hosting (good option 1, good option 2) for your webpage. Figure out the steps to tie your web address to your hosting and put your website files onto your hosting. This will be frustrating, BUT YOU WILL FIGURE IT OUT.
  • Google around to find webpage designs you like for design/structural concepts. Examine their markup in a web inspector but don't steal the markup directly. For example, one of my favorite website designs is Nest.
  • Don't worry about interactive elements for now -- things fading, moving, etc. Those will be next.

3. Learn jQuery

jQuery is an enormously popular JavaScript utility library created by John Resig. Chances are the majority of the websites you visit on a daily basis are using it. It's incredibly powerful, cross-browser compatible, and has a core team of very smart engineers making sure things work smoothly. It can be used to manipulate DOM elements, make AJAX calls, handle events, and complete many other site-related tasks. As a FE developer I can say with a high degree of confidence that you will likely be using jQuery on the job.

The positioning of "Learn jQuery" before "Learn vanilla JavaScript" [6] will be a point of contention for some people. jQuery is an abstraction of JavaScript functionality -- it provides an easier way to write commands for certain operations than their vanilla counterpart. I recommend learning jQuery first because it provides an instant (and pleasing) feedback loop with effects like fade/slide/etc, and the syntax is simpler to understand. Learning Vanilla JS before/simultaneously certaintly wouldn't hurt, but I don't consider it mandatory.

Nettuts appears to have a good list of introductory resources to jQuery. http://learn.jquery.com/ could also be a good resource, but it appears to be written very tersely. Codeacademy has a "learning jQuery" course.

Things to Know

  • $(document).ready(function() { });
  • What $(this) represents (wrapping a DOM element as a jQuery object, which can then be manipulated using jQuery commands)
  • How to select classes and ids
  • Familiarity with api.jquery.com and how to look up different functions
  • How to use the various effects (fade, slide, hide, show, etc.)
  • Traversing the DOM tree (children(), parents(), find(), etc.)
  • Chaining commands
  • How to respond to and trigger events
  • What does it mean for something to be asynchronous?
  • How do people debug jQuery bugs? What is console.log() and the `debugger` command? How can you set breakpoints in JavaScript files and step in/over them?
  • (General) What JSON is, and what a JSON response looks like
  • (Advanced) What is AJAX?
  • (Advanced) How to receive data from an API via AJAX and parse the data into the DOM

Project Idea

  • Augment your website with interactive elements. Hide/show items data based on clicking buttons/menus, add scrolling effects, etc. Really experiment with what jQuery has to offer, and look up different jQuery plugins on the web.

4. Learn vanilla JavaScript

Often times you can get by not knowing real JavaScript. It's not a popular opinion but it's reality. Heck, I did for almost two years in a corporate environment, as a full-time web developer. But I will say this: without learning vanilla JavaScript you won't actually understand what you're doing. Your work will be full of "magic" and when things don't work you won't understand why. You will find yourself limited to common jQuery use cases (effects, selecting, adding/removing classes) that are not even 1% of what real JavaScript can do. Your code will never be as clean or efficient as it can be. You won't understand 99% of the incredible libraries and technologies JavaScript-people have developed to power their websites. You won't be able to contribute to an amazing and vibrant open source community. And when it comes to the skills that determine your financial livelihood, relying on "magic" is not a good long-term play.

In conclusion, learn real JS. You will not regret it. It will make you a better developer.

A lot of people hate JS. The hate is not unfounded. As a language it's full of strange quirks that aren't common in many backend languages. The scoping is weird. Race conditions are frustrating. Thinking about processing asynchronously is unintuitive.

But it is the language of the web. It's amazingly powerful and can be tamed to be very elegantly written. And as a front-end dev, JS-skill is a big differentiator between junior and mid/senior level programmers.

The best resource I know to start learning JavaScript is the free ebook Eloquent JavaScript. Read it and understand it. After that, you can move onto any number of JS-related books, tutorials, or video lectures. For a big list of resources please visit superherojs.com.

"Learning JS" is a career-long process. Everyday I'm still learning to write cleaner, more eloquent, more modular code.

Things to Know

  • What do you mean "everything is an object?"
  • What is a callback and why is it important?
  • Global scope, function scopes, what is the global namespace and why can it be bad?
  • Namespacing your code and why
  • (Advanced) Closures
  • (Building on closures) Object-oriented JavaScript -- the biggest game changer for me personally. I found the "Object Oriented JavaScript" chapter in John Resig's "Pro JavaScript Techniques" to be very enlightening.
  • (OO JS) Prototypal inheritance

Project Ideas

  • Create a webpage that invests data from an API and parses the data onto the DOM. A personal example here, which uses the flickr API to display photos of food I've taken from my phone. I wrote daniseating to learn how to work with APIs.
  • Make a JS game that uses objects. It can be any game -- tic tac toe, connect four, or even the peg game from Cracker Barrel. [7] I wrote the peg game to learn how to use JS objects.

Moving Forward

The bullet points in this document are nothing more than a list of things I’d ideally want a junior FE dev to know/be cognizant of when applying for a job, and things that I would personally look to address in an interview. You don’t have to deeply understand everything (probably not the items labeled “advanced”), but you should be generally aware of what the basic items are enough that you can learn them if necessary.

As far as future steps, the FE rabbit hole goes deep. There’s are things you’ll probably only learn on the job (cross-browser bugs, the horror of Internet Explorer, etc.) and things that only become relevant as FE-dev work becomes more sophisticated (JS MVC, node.js, performance profiling, testing and modularity).

The JS community is vibrant and full of wonderfully intelligent people who are willing to openly share their knowledge. Learn from them and pay their generosity/openness forward. Read their well-written code. Never stop learning.

Good luck.

Personally Curated Resources

Most of these links are taken directly from my pinboard, meaning I've saved them for various reasons through the years. So they're personally curated (in that I wanted to save them) but vary in complexity. They're not specifically topical but generally related to becoming a better front-end developer.

Acknowledgements

Special thanks to Lauren and Eric for their input on this post.

Footnotes

[0] I’m more interested in the pragmatics of obtaining an entry-level position than higher-level theory: what will you actually need to know and apply on the job? So no, your first step is not to go teach yourself C, regardless of what your Computer Science PhD friend says.

[1] Cost of living is positively correlated to salary. So if you live and work in the Ozarks you may not make six figures, no matter how good your JavaScript is.

[2] Update 11/2015: When I wrote this comment a couple years ago I wasn’t intending to gloss over the tech industry’s problems, especially diversity. The “meritocracy” comment was intended to be an encouragement to those feeling like they were too late or too old to start a new career path. I now have a better understanding of how potentially harmful and short-sighted the idea of a “meritocracy” can be. I’m going to leave my original footnote below.

There’s some controversy about tech being “ageist.” Maybe that’s true, I don’t know. But personally as a coworker I don’t care if you’re 12 or 95 as long as you’re getting things done on time and not making my job harder. No matter how old you are if you’re not willing to learn new technologies to stay in line with market realities it will be difficult to find (and keep) a job.

[3] I briefly considered re-writing this sentence but it’s just too good.

[4] Sublime Text 2 is my favorite text editor, and the $70 I paid for an official license was overwhelmingly worth it. Buy software you love to support the developers of great software.

[5] DO NOT BUY FROM GODADDY. Aside from weirdly off-topic and mysogynistic marketing tactics, the customer service is horrible.

[6] The term “vanilla JavaScript” refers to plain JavaScript, without the use of libraries like jQuery. Some JS purists get upset that too many developers rely solely on jQuery and create satirical websites to make themselves feel better. They’re both a means to an end. But learning vanilla JS is very important to not only understanding the “magic” behind jQuery, but also releasing the full power of JS as a language (which far exceeds that of jQuery itself).

[7] I wrote a blog post about making this game here.

More posts

Previous post

Cracker Barrel and Hacker School

Next post

A Retrospective for Hacker School