I’ve interviewed a fair number of web developer candidates recently, and many have followed up with me afterwards for feedback. The number one question I get? What else should I have known or said during the interview to land the job?

This is a pretty easy question for me to answer, so let me give all of you some insight into what I’m looking for, as a hiring manager and interviewer:

• Have an opinion. This doesn’t sound too tricky, right? But in order to have an opinion, you have to have some knowledge and/or experience. For example, if I ask someone what their favorite browser is and why, it’s going to be easy for the person to come back with a response — likely based on what they use everyday. So why is it so difficult to tell me what doctype you prefer to code against, or whether you like or dislike reset CSS? To me, not having an answer means that you either don’t know what these things are or don’t have experience with them. Oh wait, you do have experience, but you don’t want to voice an opinion that would be contrary to my own? Your interview is not a time to be timid! State your case and let me at least know that you know what you’re talking about. I certainly won’t judge you negatively for that.
• Know some HTML5 and CSS3. There are lots of HTML5 jobs opening up, and even those employers that don’t presently advertise the need will want these skills in the future. What, you haven’t learned any HTML5 or CSS3? You’re a professional, right? The excuse that your current job doesn’t support you trying these things doesn’t fly. There are plenty of websites and new publications out now to help you get up to speed in your own time. Plenty of shops are currently looking at switching to HTML5 and adding CSS3 features, and they want people who are able to contribute to these efforts from day one. Believe me, you don’t need a lot of time to pick up some knowledge — in just a few hours you can learn quite a lot!
• Admit that you don’t know. Sometimes interviewers will throw you curveball questions designed just to get you to say one thing — “I don’t know.” Yes, it can be mean, but it does have a purpose: are you someone who will bullshit your way through an interview, and then possibly a job? Or are you willing to admit that you don’t know something — and in that case, are you the kind of person who shuts down, the kind who asks for help understanding, the kind who says “I’ll go learn about that and follow up”? It should come as no surprise that I like the latter kind of person. But there’s an even more practical reason for this: you may misunderstand a question, or the interviewer may not ask the question in a clear manner, or you may not be able to give a direct answer to a question but you could speak about something related. Saying you don’t know, but that you’re going to try to answer the question in the way you understand it, shows patience and diligence — and may just expose some additional skills or knowledge. Don’t hesitate to say it.

Want some more interviewing tips? Back in May, I ran a session at WebVisions called Speed Interviews. In it, I gave some tips to help the audience have a great interview experience, and then I conducted a number of 2-3 minute interviews on stage. It was a fun but challenging experience for me! My slides are online and I welcome your questions about interviewing. Good luck!

Looking to learn more about HTML5?

• View source on this site!
• Read Dive Into HTML5 (online manuscript, free!) by Mark Pilgrim
• HTML5 Doctor by Bruce Lawson and friends reduces HTML5 into easy to read chunks
• HTML5 Now: A Step-by-Step Video Tutorial for Getting Started Today by Tantek Çelik is an awesome 2.5 hour introduction (and at $30 on Amazon, the cheapest personal instruction you can get)

O’Reilly’s HTML & CSS: The Good Parts by Ben Henick is a new book to educate and aid web professionals in building quality web experiences. A quick disclaimer about this review: I worked on this book as a technical reviewer and the author is a colleague and friend.

This book is primarily for those who have some experience with HTML and CSS and want to refine their skills — but even front-end code ninjas will find some valuable reference material in this book. While the title implies a focus on HTML and CSS, Ben takes the time to touch on a number of related topics, such as the client-server model, creating usable interfaces, image optimization, and web typography — thus giving the reader greater insight on the wider range of knowledge and skills it takes to build a quality web site.

One of my favorite sections of the book is chapter 4, “Developing a Healthy Relationship with Standards.” Ben gives an excellent explanation of the history and benefits of standards adoption and then wraps it up with 10 rules for “standards-friendly” development. If you’re still trying to make the case for adopting standards where you work, definitely check out this chapter.

If you’ve read any of the “Good Parts” books then you know that these books also highlight the “bad parts” and “awful parts” of the subject matter. While Ben gives a good overview of the browser wars as context, he spends a number of pages calling out the various issues with Internet Explorer. (I like to think that I helped tone down some of the harsh criticism he originally wrote by reminding him of how advanced IE6 was at the time of its release.) He goes on to explain the concept of graded browser support (something near and dear to my heart) and hits on a number of seemingly nit-picky but important concepts which standardistas care about.

It’s really amazing how much information Ben packed into this 352-page book — far too much for me to address here. Besides touching on HTML5, there’s a helpful glossary and numerous reference tables. As I’m writing this review, in fact, I’m sticky-noting the book so I can easily find reference information that will help me in my day-to-day work. That said, you can also sit down and read the book cover-to-cover. (Ben’s an incredible writer.)

If you’re looking to enhance your skills, improve the quality of your work, find a better job, or even if you just want to have a backup brain handy, I recommend HTML & CSS: The Good Parts.

• HTML & CSS: The Good Parts
• by Ben Henick
• Published by O’Reilly Media, ISBN-13: 978-0596157609
• Companion web site
• 

Is Internet Explorer 6 an old, outdated, hanger-on of a browser? Yes, absolutely. Does it require the use code hacks in order to achieve semi-parity with more modern browsers? Yes, it does. Should this be such a problem for web professionals? No, it shouldn’t.

Thanks, Tracy Apps!

For a moment, forget about all of IE6′s issues, security, how much you dislike Microsoft, or whatever baggage you’re carrying around. Instead, think about IE6 as an unknown browser — perhaps as a random blip in your browser stats, or maybe as an interesting piece of tech you’ve seen on a blog or at a conference. You don’t know much about that browser or how your site is going to work on it, so what do you? You code it using web standards goodness: you create a base with semantic markup (and any server-side tech for forms), add on design via CSS, then layer on client-side interactivity with JavaScript and Ajax-y goodness — et voilà, you have a lovely, robust web experience.

Now, with some new or unknown browser, you hope for the best. But with IE6, we know what the issues are. If you’re using PNGs with alpha-transparency in your design, you’ll need an alternate solution. If you’re adding horizontal margins to floats, you know you’ll run in to a double-margin bug. If you’re trying to clear floats within a parent, you know you need to set height. You’ll need to plan for handling unsupported CSS selectors. And when it comes to JavaScript, you may not even know what to plan for (unless you spend most of your days working with JS).

But again, you’re a web professional. You know your craft. You know this platform and its issues. (If you don’t, you need to know your craft better. No, I don’t buy “newness” to the field as an excuse — this is still a present concern, so you need to understand it! Why not start with my CSS tips for IE6.) While some venting may be in order, I find the outright hatred for this browser (and other versions of IE, also bashed on a regular basis) to be downright unprofessional. Here’s why:

1. IE is still #1. While recent reports cite that its market share is shrinking, IE (all versions combined) is still the number one browser in use worldwide. The snide comments I’ve seen people make about IE (which I won’t link to) often extend to remarks about IE users, which is just about the uncoolest thing I’ve witnessed. Respect the user, regardless of browser!
2. IE6 use is shrinking. With the growing number of sites proactively messaging that support is being discontinued for IE6, its share should continue to shrink, which will lessen your burden over time. (You do have an actively managed browser support policy, to help you identify when you don’t have to support it any longer, right?) Celebrate that people are upgrading instead of harping on the stragglers.
3. Promote the best experience. Instead of complaining about having to make a fancy widget work perfectly on IE6, engage with the client/product/design team to explain how you can deliver the best possible experience to every user by honoring only what each browser is truly capable of, rather than let one browser hold you back. You now have plenty of real world examples (Google Apps, Digg, Facebook, YouTube, etc.) to back you up on this!
4. Help prepare for the future. Remind those in decision-making roles that the more time you spend looking backwards at the old, the less time you have to prepare for the new. Since I haven’t met a business owner (small, corporate, or otherwise) who doesn’t like “new”, this should snap them back to their primary focus of strategies that save money and provide for the future.
5. Don’t make yourself look like an ass. If I’m one of those poor souls still stuck supporting (or, perhaps worse, using) IE6 and I’m trying to hire someone, do you think I’m going to hire the person who’s been hating on that browser all over the interwebs? Umm, no.

I know folks are going to jump in with all sorts of comments about me not thinking about Ajax-y web apps or super beautiful design-y sites. The thing is, I do work on and continue to lead a team which works on these types of sites and apps, and yes, we’re supporting IE6 in all cases. No, it’s not to pixel perfection. No, the functionality we build for a new browser isn’t 100% replicated. But these sites aren’t as far off as you might think* — and in the cases where I’m using hacks or JS shims to get IE6 into compliance, I also have easy code management techniques for dropping support.

*In fact, very recently, after preparing business and design teams to accept far less functionality in IE6, my team delivered a cool animated design-y thing that worked perfectly in that browser! (It’s not live yet, but I’ll update this when it is.)

So take the time to inform and to educate about browser differences and support strategies. Enthusiastically suggest alternatives to your team. Track your browser metrics and get happy about those numbers changing. Say a small thank you to those at Microsoft who are working to improve IE. Get inside the IE6 user’s head and present their story, not your own tale of woe. If you need help, ask for it.

Seriously, it’ll save you from looking like an ass.

If you’ve never interviewed for a web development job before, or if it’s been a while, you might be wondering what to expect. Rather than list a whole slew of questions here, I’m going to give you access to a real screening questionnaire — one that I’ve actually used as a hiring manager to help identify which applicants have a solid understanding of core web development knowledge. (Harder questions get asked over the phone, and the hardest ones in person.)

What are you waiting for? Check out the questions!

Interviewers and hiring managers, what other questions do you ask early-on in the recruiting process?

A Resume

I don’t care whether I get one page or three pages from Web Developer candidates — as a hiring manager, I do review the whole thing. Just don’t fill it with fluff. I’m looking for dates of employment, size of company/product/team, type of work performed, and skills utilized. The general stuff which you do on a regular basis (emailing with Outlook, writing documentation in Word, slicing of assets in Photoshop or Fireworks, etc.) can just occupy a general skills section rather than be repeated for each job. Starting the resume with a technical skills overview gives me a quick snapshot of what you say you’re capable of, and is a likely place for a hiring manager or recruiter to start with questions — so don’t list technical skills which you can’t back up with experience! (Saying you have experience with HTML 5 when you haven’t done much more than read a few blog posts is a sure-fire way of getting your resume nuked in a company’s recruiting database, thus removing you from future consideration.)

While a beautifully formatted resume is always nice, don’t agonize over it: using a Word resume template is just fine. Keep in mind that your resume doesn’t always get through to the hiring manager in the format you sent — so prepare a plain text version for textarea uploads. I know that typos sometimes make it in to a resume, and the occasional one will be forgiven or overlooked — but do make sure to spell and grammar check everything! After all, if you don’t QA your resume, how will a hiring manager know if you QA your code? (Need help? Read this and this.)

A Portfolio

To me, your resume is a formality of the hiring process, just metadata. Your portfolio is the real content which will be reviewed with a far more critical eye. The fact that portfolios aren’t requested 100% of the time when seeking Web Developer positions only speaks to a hiring process which still treats the Web Developer role like a traditional programming job. Web Developers know otherwise, and if you truly want to be seen as a professional Web Developer, you’ll have a portfolio at the ready. Do not slap something together on an as-needed basis — proactively prepare a portfolio and send it even without request!

A portfolio should highlight your best work — not all of your work. Don’t include every project you’ve ever worked on. Choose three to five of your code samples which exemplify things like your coding style, ability to reconcile project requirements versus technical constraints, attempt to put HTML 5 into practice, etc. No one project will demonstrate all of those things, obviously, so make it clear why each project is included — give a short narrative for each project to point someone to what you want them to focus on. Remember, you won’t be the room when the portfolio is reviewed (unless it’s brought up during an interview, which the portfolio will help you to score), so hand-hold the reader a bit.

I’m going to write a more in-depth post about what should go in a portfolio and how hiring teams review portfolios, so stay tuned.

A Web Site

May I vent for a moment? I can’t believe how many Web Developers apply for jobs and don’t have a Web site of their own. Where, pray tell, do all of these folks do their testing and noodling with servers and code? Why would you not want some online repository of your code? OK, venting done.

Yes, I do realize why some Web Developers don’t have Web sites, but when you’re searching for a new job, you need to have one. No, you don’t need to have a blog with a lot of profound blabbering about technology, but yes, you should have an online copy of your resume and portfolio. When a recruiter or hiring manager Googles you (oh yes, we do!), you should want something more than your Facebook page to come up in the results.

I really think the most important reason for having the Web site is to host your portfolio. With an online portfolio, you can still highlight a few key projects while hosting copies of all of your code. This way, at a moment’s notice, you can direct someone to (or, in an interview, walk someone through) a code solution that exemplifies a point you’re discussing. Plus, you can preserve your code as it was when you finished it (delivered it, launched it) — no longer will you have to make statements like, “I made the templates for the CMS but someone else maintains them now, plus the content folks don’t know XHTML, so I don’t know if the pages still validate.” Worried about keeping copies of your code online? Just password-protect your site. If you give each recruiter a unique username/password to access your site, you’ll be able to check your server logs to determine who’s actually checked it out.

How will having all three of these things prepared and submitted help you in your job search? First and most importantly, it will get you in the door faster — literally. If you have decent experience and great code samples which are hosted online, I’m more likely to tell a recruiter to just bring you in for an interview, rather than go through the preliminary phone screen. Why would you want to wait and let someone else get interviewed (and possibly get an offer) first?

If you’re looking for your first Web Development job out of school, as a new career, or if you’re switching from freelance to full-time employment, the portfolio can be especially helpful in leveling the playing field. If you’re able to demonstrate strong skills but have little or no job experience, you’re more likely to get an interview than someone with years of experience but no portfolio.

Of course, while you’re in the midst of a job search, all of these tools are equally useful for getting short-term contract work, too!

What else do you think is crucial to a Web Development job search? Leave your thoughts in comments. If you have questions, I’m happy to answer those in the comments as well. Best of luck with your job search!