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.
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.
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.
I’ve got some more content coming up on IBM over the next few months on some pretty exciting topics. I’m in the middle of a deadline for one right now, actually…
For starters, the following is what I’m generally interested in when doing an interview. It doesn’t represent in any official way what my current employer and my boss might be looking for in a candidate. It’s not my group, so this is only part of the picture.
Secondly, this is based on the “Front End Developer” role I outlined in my previous post. That’s what I do and what I’ve interviewed people for over the past few years, so if you’re looking for insights into interviewing for another role, adjust accordingly.
Also, and this should go without saying, the following is simply what I look for in a candidate. This is entirely personal and biased. If you look for other things or don’t care about some of the things that I value that’s cool. There are infinite ways to get to the same result here. We all want to hire good people. Read the rest of this entry »
Following up on my previous post about the generic types of front end engineers, this post will deal with the common roles that I see people trying to fill. Unlike the previous list which was written solely from the perspective of a front end engineer, looking at the actual skill sets of the people whose resumes I’ve reviewed, people I’ve interviewed and folks I’ve worked with; this list is based on job descriptions and roles designed by people may not really understand what being a front end engineer means in 2011. Hopefully a few of those people (and maybe a recruiter or two) will visit this site and come away with a better sense of how to staff these roles.
As both a hiring manager and as a potential employee, I’ve seen both sides of the interview/hiring process and have noticed some definite categories when it comes to the type of people filling the roles and the roles themselves. This post deals with the types of people. I’ll follow up with a post outlining the types of roles and who (of the following) you should be looking hire if you’re looking to fill one of those specific roles.
The Three Types of Front End Engineers
Clearly, there are people that fall somewhere in between these broad categories. Still, I think these are pretty solid as general buckets. Read the rest of this entry »
I’m going to be writing a bit more about practical development topics here over the next few weeks. Code is fun to write about but code takes time. Sharing my experience and opinions on the day-to-day life of a front end engineer I can do with a little less effort. Also, since I’ve been doing it forever and have experience all over the place I feel like I just might have something to share.
Anyway, today I’m going to continue to talk about the technical interview process. This time with an anecdote culled from my time on the other side of the desk.
I was interviewed a while ago by someone who was significantly junior to me. I think he had maybe 3 years of experience. I was supposed to have been interviewed by someone who would have been a peer at the company, but that fell apart and it fell down to a junior resource. He asked me two questions over a span of ten minutes. Both were worth commenting on, but I’m going to focus on the first one as it illustrates something pretty important about who you have interviewing people and what they should be expected to be able to figure out about a candidate.
We get on the phone, trade pleasantries and then he gets started. He asks me the following question:
“You have a div with a width of 300 pixels. It’s got a margin of 10 pixels. How big is the box?” Read the rest of this entry »
I’m a big fan of the Graded Browser Support table from the fine folks at Yahoo! It was the official foundation for our browser support policy at Cramer and I still look to it now for hints into what one of the most mass-market of all sites thinks about the browser landscape. Read the rest of this entry »