Sunday, March 8, 2009

Job Hunt Frustrations

Having recently emerged from the world of job-hunting, I had forgotten almost how insanely idiotic most of the process is. From companies having unrealistic expectations in their job postings to potential employers who pride themselves on their "stringent" hiring policies, the entire experience leaves me just wanting to smack some sense into people. Here are some of the top annoyances I had with the process of finding a job as a software engineer:

  • Almost without fail, every job posting for a large corporation that doesn't have IT as its main function is completely unrealistic. Requiring three years of experience in a technology that's only existed for two years, demanding proficiency in an obscure internal technology, immediately rejecting resumes based on their inability to list a particular application that a decent programmer could learn in under a week, the insanity never ends. Most of these are the result of HR droids not really knowing what it is tech folks do being coupled with hiring managers trying to make their jobs sound more important than they actually are. Guess what? It does not take a programmer very long to learn SAP - your search for an "Experienced SAP developer" will only bring you one of the uninspired masses who has as much relation to a skilled programmer as a monkey has to a rhinocerous. If you want incompetent consultants versed in buzz words, by all means keep your job postings peppered with useless acronymns and internal products.
  • Some companies are just unable to move quickly in a field that demands quick response. If I apply to a job, I should not expect a response that takes 6 weeks - after week two, I've already written you off. If your hiring process takes more than two weeks to get back in touch with promising candidates, you are doing pretty much everything wrong. Fire your HR department and hire someone who can actually do the work you are requesting. There is no reason that candidates have to go through three or four committees before getting the OK for an interview.
  • Not providing requested feedback is one that always pisses me off. If I get rejected after an unsolicited e-mail, fine, I'm cool with that. But if I've taken the time to prepare materials, come in to your company, go through your interview process, common courtesy says you should at least be willing to answer a question along the lines of "Hey, sorry it's not going to work out - how can I improve so that next time I am a more desirable candidate?" A lack of response on something like that is a dick move. And stow your bullshit about not wanting to give the candidate lawsuit fodder - a trained monkey can be taught to not discuss the things that could lead to that kind of lawsuit. If I've committed time to something, I'd like to see a payoff outside of some nebulous "experience of the interview" bullshit.
  • Obviously fake reasons for rejection are even worse. During one set of interviews for a company, I nailed every single question they asked me. I provided every answer they were looking for, and got along well with the interviewers. Yet a few days later I get a response saying "We decided to go with someone with more experience." Bullshit. You were uneasy about something and didn't want to tell me what it was, so you hid behind some fake line that does a horrible job of making the interviewee feel better.
  • Brainbench tests. If your company relies upon these as a measure of programmer ability, your company is doomed to failure. There is no way in hell a MULTIPLE CHOICE TEST THAT THE CANDIDATE HAS TWO HOURS TO COMPLETE is an accurate judge of programmer competence. You do realize that - nearly without fail - every test taker is punching the questions into google to get their answers, right? No? Well then you deserve whatever you get. Brainbench is a worthless measure of productivity, coding ability, and general programming knowledge.
  • Excessively long interview processes. I've been through several interviews where I spoke to something like 7-10 people throughout the course of the day. You know what ended up happening? I answered the same questions 7-10 times. I'm sure you feel that each person in the interview has a reason to be there - if that's the case, put them all in the same damn room. I have no problem speaking to a panel, so let me answer everyone's questions at once. Otherwise, your process is just inefficient.
  • Arbitrary interview tactics. It's great and all that Microsoft uses logic puzzles to weed people out, that doesn't mean that the process works - just take a look at any version of Windows for proof. Nearly no-one performs well in a high stress situation, and having an interviewer sitting there prodding you with "clues" does nothing to ease the nerves. On top of that, 95% of these logic questions require that you know some obscure "Trick" to it that not only isn't relevant to the job being applied to, but doesn't even apply to anything outside of the question being asked! Tell me, how does knowing that "they don't bury survivors" make me a better developer? When will "so that they can't fall in" ever result in me writing code that conforms to spec? Why not just come out and request a copy of the candidates IQ scores and be done with it?
I'm sure there are more floating around in my head somewhere, but these offenses seem to me to be the most egregious. Anyone out there have any others?