On more than one occasion I’ve been interviewed by someone and they’ve told me, point blank, that they “didn’t prepare at all for this” or “didn’t even look at your resume.”
Really?
While this is lame no matter what industry or role, with front end engineers it’s incredibly frustrating.
Throughout the “Ajax era” any other experienced front end engineer has been interviewing from a relative position of strength. In my personal situation, I’ve been employed over the past five years by good companies, working with people I like and respect; but anyone with a strong background in HTML, CSS and (especially) JavaScript who is looking for a job is going to have several options available at any given time. That’s just the nature of the industry right now. We’re in an extremely fortunate place right now.
So… with that in mind it should be clear that if you’re hiring on the front end you have to actively recruit. This is just the reality of hiring front end engineers. Everyone wants someone great and there just aren’t that many great people around. If you find someone you’ve got to put forth some actual effort. I know all about this from both sides of the table. For example, we’ve had this role open at Isobar for ages and we haven’t found the right fit just yet.* There aren’t all that many people that fit those requirements.
So, what’s a candidate supposed to think when someone walks in and admits, in effect, that the candidate’s time and/or the role isn’t important enough to merit even minimum effort?
How is that recruiting?
It’s not, and speaking from experience, being on the other side of some of those comments it reflects poorly on the organization as a whole. People picked to screen and interview staff should recognize that it’s important for a team or organization. It should never be such a burden that they can’t even do the minimum, and in the rare occasions where it’s impossible to do proper set-up they have the common decency to pretend that they did so as to not insult the candidate. If the person you’ve picked to do interviews can’t do that minimum, it’s probably time to pull them out of the rotation.
Putting it simply: it’s hard hiring people that do what we do. You’ve got to take it seriously.
*Hopefully moving downtown will help us fill it (plus don’t you want to work closely with me? Wouldn’t that be awesome?)
So, as you probably noticed I did a bunch of writing for IBM earlier this year. Because of that I’ve got about a million draft posts here that I’ve got sitting in various states of completion. I’m going to work my way through them over the next few weeks. You’ve been warned (in a good way, I hope.)
Anyway, this happened a couple of weeks ago, but it’s still interesting (and important to me personally) so I thought I’d point it out again, in case you missed it the first time.
This document has made a strong impression in the year plus since Paul announced it and because of that we take it pretty seriously. To that end we wanted to update the design a little bit (just because it needed it) and have revisited a lot of the content to make sure it remains fresh and still reflects the current trends of web development.
So, check it out and let us know if there’s anything we can improve.
Get a technical introduction to Ajax programming, and discover the core JavaScript code and popular library implementations. This article presents a brief history of the technology, then outlines the technical basics of Ajax interactions using core JavaScript coding as well as three popular JavaScript libraries.
HTML5 and its Impact on Enterprise Architecture (Location: Room 1)
Although not yet ratified as an official standard, HTML5 support is showing up across a variety of different browsers. And for very good reason: HTML5 includes support for an important range of functionality – much of which has a direct bearing on Enterprise 2.0 applications.
Join a panel of experts who will critically review the prospects for HTML5 across three areas:
* Enterprise Architectures
* Social Computing Applications
* Mobile
HTML5 is not a panacea, but it should simplify application development and help enterprises support a much wider set of mobile platforms. Come find out how.
Moderator – Jarrod Gingras, Analyst, Real Story Group
Panelist – Jonas Jacobi, Co-Founder and CEO, Kaazing Corporation
Panelist – Rob Larsen, Interface Architect, Isobar
I’ll be focusing on the mobile angle. I’ll be doing a 20-25 minute presentation and then will stick around to answer some questions.
It should be interesting as the audience for this is going to be far different than my regular open source and developer-centric audience. The really interesting part is that I’m going to be able to sell HTML5 to a crowd that might not be totally hip to the fun we’re already having.
It’s a great time to be a web developer. After a long period of hibernation, the standards bodies and browser vendors have been extremely busy over the past few years, generating a torrent of exciting technology. Developers are greedily seizing on this work, producing demos and full-blown applications at a steady pace. Fed by this activity and further boosted by the growth of their standards-capable mobile browsers, companies like Google and Apple are using these new standards to market their products and services. The wider press is also seizing on this wave and pushing standards hype well beyond the normal circle of web developers and browser vendors.
This volume of discussion has obvious benefits, of course. People getting excited about web standards is a positive development for everyone in the industry. From that perspective, the persistent use of blanket terms, especially HTML5, as a sort of brand shorthand for “emerging web technology” is a useful shortcut. It allows nontechnical people to grasp—in a generalized way—the exciting work being done in the standards space right now.
Interestingly, even the W3C has gotten into the act, using HTML5 and its associated logo (see Figure 1) to publicize the “web platform.”
The standard published under the dry title ECMA-262, 5th Edition hereafter referred to as ES5, is the latest version of the ECMAScript specification. ECMAScript is the standard upon which JavaScript—the single most important language on the web today—is built. Because the language also serves as the basis for Adobe ActionScript in addition to other flavors, it’s fair to say that the ECMAScript standard is central to the present and future of interactivity on the web.
Published in December 2009, ES5 represents an incremental improvement in the language, arrived at through a lengthy, and occasionally contentious, process. Still, whatever friction there might have been in the development of the specification, the end result contains some excellent enhancements to the language. This article outlines the long history of the specification’s development, then steps through many of its important new features and concepts.
The short answer is- I don’t pay all that much attention to the sites listed on a candidate’s resume.
Don’t get me wrong, I look at sites and I prefer to see at least three or four examples when doing an evaluation. It’s just that I’m looking at sites mostly to exclude people. We see a lot of unqualified candidates at the resume level, so most of what we need to do at this point is to get rid of all the people who have no chance. Because of that, I’m visiting listed sites just to make sure the work looks professional and is done in a reasonably modern style. Basically I don’t want to see any tables, inline event handlers, or generated code and looking just a little deeper I want to make sure the JavaScript doesn’t look obviously insane. If they pass that test, then the real work of the hiring process begins. We’ll start the rest of the interview process in order to dig deeper into their front end knowledge and personality.
Why I Don’t Look at Source Code
I could view source and maybe learn a thing or two, but I’ve done this long enough to know how unreliable that can be for judging a candidate’s technical ability.
Summary: The concept of sandboxed natives, which are native JavaScript objects safely enhanced outside of the global namespace, has been circulating for several years. With Fusebox, we have a new, elegant approach to sandboxed natives—one that serves as the foundation for a new library, FuseJS.
We’ve actually hired a couple of people recently, so I’m not sure if I’ll be able to bust this one out any time soon. Instead, I’ll share it with you.
This is another one that I feel works for a lot of different experience and knowledge levels. A good, junior developer should be able to give me a satisfactory answer and a senior developer could take the same problem, decide to be clever, and give me a great answer.