| Ok, so here's the problem. None of the recommendations in this are actually actionable. Consider: - Be Interesting Well, the company either is or it isn't. If you're an auto parts distributor who needs to convert your application from Cobol on AIX to ASP.NET on Windows, then well, you aren't really very interesting. And there's not one thing the recruiter can possibly do to change that. * Care Perhaps you genuinely care, but what if you don't? The recruiter is human too. Maybe they just want to do their job and go home. You can't decide to genuinely care. You either already do, or not. And we're saying they absolutely must not pretend to care. So ... the only remaining option is not caring. * Acknowledge Applicants I don't think Matt appreciates the sheer volume of resumés that come in for an advertised position. I know some HR departments that insist on sending an acknowledgement for every received application, and they spend a lot of man-hours on it, and are constantly having to defend this practice to executives. And honestly, why does the typical badly-formatted, ungrammatical resumé actually deserve a response, anyway? Matt may be a special unique snowflake, but trust me, all those other people aren't. * Get to Know Programmers You can't do this without getting to know programming. And the whole point of specialization of labor is that you shouldn't have to. You can hire a doctor, lawyer or plumber while knowing nothing about plumbing, doctoring or lawyering. Why should it be different for programmers? As a profession, why should the rest of the world bow to our desires, instead of us creating a better product for them to buy? * Let Me Code, Dammit This is the one piece of good advice. The best way to interview in any field is to engage the applicant in job-related task behaviors and observe the results. With programming, we're lucky that this happens to be pretty easy. But I don't understand how this squares with the earlier rejection of having the applicant code a Fibonacci function. |