Let’s talk about your career as a web developer.
I’m the head of front end web development for a rapidly growing boutique consulting firm. We do fantastic work, which means not only consistently delivering our projects on time, on budget and with zero defects, but making our customers just generally very glad that they chose us.
One of the ways that we make this happen is to be very picky during the hiring process. As I’m the lead for front end/web development, it falls to me to do the technical interviews for anyone coming into that space. In this post, I’m going to take a look at the different skills that I think you should have acquired by this point (or be working on) in order to be considered baseline acceptable. You don’t have to be a master of these, but you should have at least touched them and be able to integrate them into an intelligent conversation.
Now, depending on your current job, there might be constraints on what tech and processes you have actually gotten to use in a professional fashion. But here’s the rub: I don’t care. Learning and experimenting with this tech is free. If you show up and tell me that you have a “passion for web development” or some such, but follow that up by saying that you’ve never actually used jQuery because they don’t use it at your job, that’s bad. This stuff is all free to do at home. The curious, the intelligent, the driven, those who really have a passion for this technology will do their own work on it, finding the standards and best practices on their own regardless of what their employer mandates on the clock.
With that said, here we go:
Here are some resources to get you up to speed:
- JS basics can be learned at Code Academy.
- The Mozilla Developer Network has a page full of content broken out for beginner/intermediate/advanced. Pretty much all of the stuff there is great. It’s also a good way to see where you fall. Find that you’re completely lost reading the intermediate stuff? That should tell you something.
HTML should be used as the informational structure of the page, not the design, and not to store data points for scripts. Using DIVs for logical grouping is fine, but don’t be putting them in there “just to make some space” or to serve some kind of visual goal. Likewise, don’t store your data in element properties, like adding a “clicks” property to a button to track how many times it’s been clicked.
Learning: when looking for resources online about this, don’t simply google “semantic HTML.” There are actually a set of tags for something called “semantic HTML” that in general you will never need. It is more the conceptual framework that we’re looking at.
Styling through CSS
This goes hand in hand with the previous point. You would not believe how many people I’ve interviewed who show up with a portfolio that uses tables for page layout. Seriously. Don’t do that. Also, make sure that you understand the hierarchy of effect of applying CSS at different levels. What takes precedence: ID, style class, in-line? If you think that is advanced voodoo, you’re going to be in trouble. Folks who already know this, please don’t laugh. There are plenty of people who think that because they can bang out a stylesheet and make the screen look right that they know CSS. A large part of web development in a professional environment consists not just of creating an initial style sheet for a simple web site, but of working with and troubleshooting CSS that others have produced, extending it, and creating well-structured styling work on which others can do the same.
Learning: More than a real skill set, this is more of a discipline. You either do your design this way or you do not. I honestly can’t believe that anyone is still not doing this, but if you’re … using … (gasp) … tables for layout… start here.
jQuery (or some other toolkit)
jQuery is the most popular helper toolkit right now. It actually doesn’t take that long to learn, and once you learn it you gain expertise rapidly with frequent use. If you don’t use it, it tells me that you want to work harder than you have to. There are some other toolkits around that can make your work easier — MooTools, dojo, and underscore to name a few. But if you’re looking to start with one, make it jQuery. The main reason that you need to know this sort of thing is because it’s a bit of paradigm shift to read someone else’s code that makes use of it. Having no experience with it whatsoever is kind of like trying to read someone else’s Perl code. It’s going to be prohibitively difficult.
XHR and AJAX
The modern web is built on making calls to services and displaying the results in the existing page. This is all based around the XHR (the XMLHttpRequest) and AJAX tools. You don’t need to be an expert in these, but you should have the basics down of making requests and dealing with the responses.
Learning: Once you get jQuery and Dojo down, just use their tools for dealing with AJAX/XHR. Most of the AJAX tutorials you’ll find on the web have you building the calls and handlers “by hand,” when in practice you will probably never actually do that. It’s not bad to know how to do it the hard way, but not necessary in my opinion. Once again, Mozilla Developers Network has a good intro here.
Cross browser issues
If you’ve never had to support IE7 (or 6 for that matter!), and only ever made things for Firefox or vice versa, you’re going to have some serious problems in a professional environment. Not only do many of our applications have to play nicely with the big 3 (IE, Firefox, Chrome), but have to also represent well in Safari, Safari mobile and the Android browser. Of course, four of the mentioned browsers use the same rendering engine, which is something you should also already know.
Learning: You learn this one on the streets, man. If you’re just starting out, try this development pathway: develop on Chrome or Firefox, and spend the last hour of your work day trying to retrofit what you did so it works in IE. When doing project estimates, I generally assign a 20% premium for IE support.
Some kind of non-web programming
The company that I work for is specifically a Java shop, so anyone with real Java development experience is going to get bonus points here. But to generalize things, I’ve found that web developers who have a general programming background get up to speed in an enterprise environment much more quickly than those who came from, say, the art and design side of the world. They have already been introduced to the concepts of object oriented programming, re-usability, supportability, the model/view/controller structure and the ins and outs of the software development life cycle. That’s not to say that you cannot succeed without coming in knowing those things, but it’s going to mean you have that much more to pick up on the fly than everyone else.
Isn’t this kind of picky?
That’s “the list,” as I see it right now. Next year, it will probably look a little different. I want to stress the point that it’s not a factor of “if you don’t know this stuff, you won’t do a good job.” It’s the fact that this stuff is all available to you, for free, and there are copious resources around that point you to it. If you are really into serious web development, you will have run across this stuff and tried to educate yourself. If you don’t know this stuff, it tells me that you’re maybe mediocre, or just at the beginning of your path of discovery. Either way, you probably shouldn’t be referring to yourself as a Web Developer. Rather, you might want to say something like “I’m getting in to web development.” I wouldn’t throw a fit it I heard that.
So, use this list as an indicator of how much more information you need to pick up before you’re ready for prime time. Or, to be less pejorative, use it as a list of interesting things that you should learn about that will make you a much stronger web developer. These are skills that you will have picked up (at some expense of training and lost productivity) through your first year on the job in a professional web development environment. Having them on your resume, and being able to talk about them intelligently and demonstrate your knowledge in an interview, indicates that you care about your craft.
If you’re missing some of these, don’t panic. Like I said, you can learn all of this stuff for free, on your own. You don’t even need a server to do most of it – just use Chrome, write your code in something like Aptana studio, and do File->Open to test it. Cool things abound such as jsfiddle.net and dabblet.com for writing and learning to code directly in the browser.
Have this skill set down? From our perspective, the most attractive knowledge base afterward includes deep knowledge JS event handling, asynchronicity and closures, HTML5 and CSS3, optimization for mobile, and PhoneGap/Cordova. Once again, those aren’t meant to be items on a checklist, but represent a look at what the industry is using and the kinds of things that I think a curious junior level web developer might be interested in next.