The Problem with SEOMoz's Web Developer Interview Questions

This is driven from:

a blog at Seomoz.org

I have a few problems with this kind of employer. He has to realize that not only is he picking people he wants, but the candidates are trying to decide whether they want to work for him as well. I'm a manager and a programmer, myself, so I get to hire and fire people. Therefore, I try to be fair and try to make the candidate feel at ease because I don't want to scare the good candidates away simply because they don't fit in my template exactly. We're dealing with humans, not robots. Also, just because someone is inexperienced in a field, like handling the bandwidth of high-end websites, doesn't mean that I can't stick a person in that area because they have a strong interest for it. If I've got sufficient expertise in that group and they need some extra help, having a newbie to train does have its benefits, such as not getting a prima donna but getting someone you can mold into your template a little better. Also, you never know, they may have such an aptitude for it that, given enough time, he may be your strongest player in this group, topping everyone else who was mentoring him in the first place. People are not static.

Here are some other loose thoughts:

• Although CSS is a necessary goal, tableless XHTML with CSS does have its problems. IE is one of those problems. Getting everything to look almost exactly the same in multiple browsers is in other. And, although a minor issue, consider someone who downloads the page but forgets the CSS -- they almost find they can't even read it. Anyway, in the future, tableless XHTML with CSS is the way to go, but it's too cutting edge until Microsoft's second-to-most-recent browser supports it 100% and looks the same as Firefox (at least by 80%).


• I don't particularly like prima donnas who know everything already and pass your kind of 20 questions kind of interview with flying colors. I find I can't mold them to our way of doing things very easily.
  


• Some of your questions are loaded questions. You'll end up wasting the time of your candidate and your time as well by asking them. For instance, in some cases, you only have a 50/50 chance that the candidate will answer it in the way you like it, such as the question about "do you prefer to work alone or on a team" or the question about whether someone can handle massive sites or medium/small sites. If you want to know these things, and if someone answers these wrong it's not even worth continuing the interview, then put it in writing and make it known up front in the classified or the initial phonecall. A couple years ago I called a receptionist at a French-American company to inquire about a programmer job. She said she would be happy to take my resume for the position, but then said, "You do realize, however, that you must speak, read, and comprehend French sort of okay in order to work here, right?" When I said I didn't even have a class in French, she said, "Your resume, unfortunately, is probably not a good fit here." I really appreciated she said that to me. It saved me a lot of wasted time and embarrassment.


• If one developer prefers Bluefish, while another likes Eclipse, while another likes Screem -- I say who cares. Just as long as they aren't using any kind of limited thing like Notepad or gedit, can switch pages extremely fast, have colorized text, and can turn on bookmarks and line-numbering. If they're a super-brain with emacs or vi/vim, then fantastic -- even if I don't prefer those kinds of editors. I just want editing speed and the same results as everyone else on the team. I also don't want to walk over and find the developer hitting the down arrow in their IDE and saying, "1, 2, 3..." etc. That's a developer I'd bring back to my office for a quick corrective discussion.


• I've hired an outstanding couple of programmers who did regular hours and were not passionate for coding. They came in, did what I asked, delivered on time, listened to my advice, made quick changes when I was in that kind of time crunch, and left. I can't fault someone for having a good life/work balance. However, I also can't run my teams entirely on this kind of individual, either, unfortunately. So, I don't disqualify someone because they like to go home at 5pm as best as they can, but I really do appreciate the extra stuff I get from those on the team who are passionate about coding and can show me something cool they figured out or read about at home and which could benefit our teams.


• I can't fault someone for not visiting certain websites or having anything tangible to show me that they worked out in a kind of portfolio. You'd be amazed at the candidates who don't have this stuff for your 20 questions template but are amazing employees who can grow into the position quite well and exceed my expectations.


• I do ask some of your tougher questions as a guide for me, but not as a disqualifier. I also make it known to my candidates up front what are the disqualifiers and if they pass that hurdle over the phone, I then use the interview as a guide for what I might see, right off the bat, with this kind of employee.


• My biggest seven desires from a web developer are that they can communicate properly, that they don't force their way on the team without listening and using rational dialogue to earn our respect, that they show a flexibility and an aptitude to learn new things, that they stick to a schedule, that they know the importance of occasionally having to work faster, that they not wear a frown and stick with a negative attitude all the time, even a cynical one, and that they act professional and follow company rules. Everything else is usually possible with coaching and mentoring.