mark.itpimps.com

i’m an avid reader of coding horror and the author, Jeff Atwood, is an advocate of programmers (and professionals in general i believe) to not only practice their art, but to write about it as well. so, i thought i’d share some stuff about being an interviewer. note: this is my view and pertains mostly to the IT field, so your mileage may vary

i guess i should preface this by saying that finding someone you want to interview is very tough in and of itself. for me, it seems like 80% of the work really. sifting thru resumes and cover letters and, often, emails with only attachments. i don’t know if there is some sort of predefined etiquette nowadays on applying for jobs thru email (how many jobs are applied for nowadays, especially if the job is posted on craigslist), but this is how i would like to see them:

first off there is the whole notion of cover letters. i believe it is acceptable for the actual content of the email to be your cover letter. if you don’t use it as your cover letter, then attach it, but say something in the email. many emails i received just had the position as the subject (perfectly acceptable), but just left their cover letter and resumes as attachment with no sort of greeting or introduction. just say: Hello Sir/Madam, my name is blah blah and I’m applying for your position. Attached is my cover letter and resume. Thank you.

now onto the cover letter… those are quite tricky really. the cover letter shouldn’t be too long, and it shouldn’t be too short. maybe 3 paragraphs are good enough, and it should be well written! no misspellings please! i would do the following: first paragraph - introduce yourself, say your name, the position you are applying for and maybe how you found the posting. second paragraph - say why you feel you are qualified for the position. reference some of your past experience (or schooling, if you’re new to the field). last paragraph - summarize! remind the reader that what you wrote shows that you fit the position. and for kicks, i would say that it’s a good idea to thank the reader for taking the time to read the cover letter AND consider the resume.

so now the good stuff: the resume. i’m not really going to say much here other than the following - do a google search on building and refining a resume. there should be more than enough information out there to help you get a decent-looking resume. have your peers look at it and give feedback. and for godssake, PLEASE NO TYPOS. typo = didn’t take enough time to carefully prepare it.

make sure that when you send your email, that you have your resume (and optionally your cover letter) attached, and note what format the resume is in.

no here’s the scenario: i’ve READ your email, LOOKED at your cover letter, and GLANCED at your resume. see what i’ve done? at each point i’m paying less and less attention, but still enough to notice your mistakes. please be careful with those things.

so let’s say i want to bring you in for an interview. great! some places have time to give you a phone call, i typically don’t so i’ll send an email. try and respond quickly, the same day if possible even if it’s later in the evening. make sure you have directions and a phone number to call just in case. show up 10-15 minutes early. and, make sure you know what you have applied for and are prepared to be asked questions pertaining to skills required for the position. make sure you have questions to ask. be nice, relax, be honest, and don’t BS. i much rather a person say “I don’t know” than try to fumble thru a question i’ve given.

ok, so that is my advice so far. now for some insight from the round of interviews we’ve done in the last few months.

it’s very different interviewing people for a programmer position than it is for a systems position. maybe it’s because i don’t really know the kind of questions to ask a systems person, as i’ve never interviewed for a systems position before. so it’s more difficult for me to figure out whether a person would be well-suited for the systems position than to figure out whether a person is good for the programming position.

kimmel holds this notion that you can tell if you’ll want a person within the first handful of seconds in the interview. i was skeptical at first, but after going through a good number, i think his notion does hold true, at least for us.

in our interviews i am usually the one asking the technical questions. i like to start off with a programming problem that’s pretty basic: a simple loop, some control statements (if/else), and some basic math. i don’t even require it to be in any specific language, and i usually give the option of pseudo-code or even just writing out the steps in an ordered list. this is usually the deal breaker for me because it’s an easy problem that should not baffle any decent programmer. i am often worried about how i phrase this question to candidates, and i’m not sure if the low passing rate on this problem is due to my inability to ask the question clearly, or the candidates inability to solve the problem. very few people ask any sort of question for clarification, so i tend to think the latter. additionally, very few people take the option to pseudo-code it.

if you haven’t gotten close to the answer, then i’ll usually just throw some other easy questions out for the heck of it. i try to give the benefit of the doubt and give another chance on the follow-up questions, but, usually, i’ve already decided i’ve had enough. i’ll then just run thru the normal set of questions i ask everyone, not trying to dig deeper. then we’ll end the interview soon after.

now, this has worked really well for interviewing the programmers. the systems folks, all i can really do is try to judge their skills by what they tell me they’ve done. i also like to ask them the programming question, as it shows me that that person can describe the steps to solving an issue we might have with the systems (or, alternatively, describing data flows in the network, interconnectivity with systems, etc). but still, interviewing systems people has been super tough regardless.

from there it’s pretty easy to make a decision on whether we want you or not. kimmel and i are usually pretty good about letting people know about our decisions, but some other companies aren’t so be aware.

i guess i didn’t really cover what i usually look for in a candidate huh? first off, they need to cover the requisites for the position. second, they have to show interest in the position and the company. third, both kimmel and i like to make sure the person will fit in with the team. we have a very eclectic team, and we all hold super high standards about each other, so it’s important we get someone who fits in well.

so that is my experience as an interviewer thus far. i’m sure this whole thing will get refined as i go further in my career, but for now this is how i see it. if anyone has questions, feel free to leave a comment or drop me an email.

-m