* mention in the initial e-mail whether you're applying as local or remote

* mention in the initial e-mail your availability (immediate, two weeks on notification, etc)

* have a non-generic cover letter/e-mail that shows me you spent at least a couple minutes finding out about my company and tailoring your application to match

* don't namedrop languages in resumes: namedrop libraries/APIs you're familiar with

* pdf, text, or webpage: no .doc

* if asked to provide code in an archive, don't splatter files inside my pwd (I open in /tmp anyway, but it's still annoying)

* if asked to provide code, vendor everything you can (ie make your code as self-contained as possible) and provide a README for how to get it up and running

I like your page at http://yangman.ca but it would be better if you went into detail about what you did for the various projects. Don't say you "actively contribute" to the radeonhd project -- describe 2 or 3 of your major contributions.

Another suggestion: make use of the fact your resume is web-based. Instead of linking directly to linkedin etc, link to a uri on your domain which redirects. That way you can find out your clickthrough rate, and alter your online profile accordingly. For example, if no one ever clicks your LinkedIn profile, you may want to put your employment history on the page itself. If you apply to companies in different locations, you can roughly figure out which ones look at which pages via a geoip lookup.

I personally think this is being overly picky, but as long as you make it clear that you only accept resumes in these formats there is no problem. I once sent a cold job application to a company that had no resume format requirement on its career page. I sent my resume in .doc. I could have sent it in PDF or something else, but in my experience most companies prefer to receive resumes in .doc unless otherwise stated. This company also sells a product for Windows (and other platforms) so I expected it to use Word internally. A few months later I found a job ad from them on Monster where they very clearly stated that they would only accept resumes in PDF. To this day their career page still does not specify a file format preference for resumes.

The only safe advice is to ask ahead of time; unfortunately for you, there was no one to ask. Dysfunction is unfortunately common.

Yeah I do think that is equally stupid as well. To me doc, pdf, text or even odf is fair game.

I think that displays the typical pickiness of people that do hiring. I mean, you could just type 'unzip -l' to check the contents of an archive. Similarly, the resume format. Practically every hirer requires a different format nowadays - pdf/txt/doc/odt/html - that simply maintaining a CV becomes a massive time sink.

As for resume format, it is an open source job and my main machines are all MS-free, so it is extra trouble (especially if it is docx). Just a preference, that's all. I didn't advertise otherwise.

Tip for maintaining multiple formats: asciidoc/markdown = text you can generate html with. And once you have html you can print to pdf from a browser. 3 formats for the price of one.

Bear in mind I wasn't trying to write a list that's canon -- just what I like to see. I'm not going to chuck applications simply because they missed a point in that list of recommendations.

AFAIC, the most important thing for any candidate to do is to identify my problem(s) and present themselves as the solution. The problem could be:

- We just got a bunch of new business and need someone to do <xyz> immediately to satisfy those customers.

- We just acquired another business and need to convert/integrate from technology <abc> to technology <xyz> and need someone who knows both technologies (or either one) and has done that before.

- We have a new business problem and one possible solution is to build/enhance/maintain an app. Can you do that? Have you done that?

- We plan to grow x% over the next 24 months and we need people to do more of what we already do which is <abc>. Can you do that? Have you done that?

- We have a problem and frankly, we're not sure what to do. What would you suggest? Can you do that? Have you done that before?

You kinda get the picture. The tricky part for any candidate is the research. How do you find out what my problems are? Ask! Ask me. Ask someone else in the company. Ask anyone. The simple act of research shows that you're a serious candidate. The follow up with a solution to my problem puts you at the top of my list.

If you're right out of school or don't have a lot of experience, you should still do this. You may not have as long a resume as others, but you have every bit as much to offer to solve my problems. Maybe a smart person who works hard and knows how to deliver is just what I need. You must find that out and present yourself as such. Remember, it's about my problem, not yours.

This was I great question to ask here at hn. I've never seen it before. The fact that you thought enough to ask is a huge first step. It shows that you're thinking about me, not just yourself. Keep thinking like that and there's no telling how far you'll get. Thank you and good luck.

You can also play the old mentalist trick.

The mentalist knows nothing of his audience, yet it appears he has amazing powers of telepathy.

How does he do it?

He throws out a lot of information, then closely watches for a response, keying off of positive responses from the subject. As he gets more and more subvocal, body-language, and affirmations from his subject, he closes in on information that only the subject knows.

You can do the same thing in an interview. When asked a question, tell a story about how you solved a problem (which is why you're there) While telling it, listen closely for clues that you have touched on something of value. If you hear them, next time you tell a story keep close to that sore spot. Usually over a period of six or seven questions you can hone in on what the problem is while reassuring the interviewer with stories that you know how to help them.

Here's an example of what I mean. Suppose you're a Java/Struts developer historically, but have some serious Ruby on Rails experience recently. You come across a job listing for a RoR developer, with all the right RoR talk in the description with "experience with Java/Struts a plus" at the bottom.

You go into the interview and just nail all the RoR questions. They are happy, you're happy, and they ask you if you have any questions, so you ask them to describe their project. As you play mentalist you discover that they really are using Java 1.4 and Struts 1.38 and want someone to come on and maintain that old code while hoping that some day management will let them rewrite the whole app in RoR. They want you there in case management agrees and to "train" the others in RoR just in case it happens.

They extend you a job offer. You decline and go after a real RoR opportunity with a hot startup. Life is good.

To me, acting haughty is a good indication that you're going to be a pain to work with. You're going to make a fuss when asked to do easy work, rather than just getting it done and moving on to the more interesting things.

That's my pet peeve and the pet peeve of several others I know, so apparently it's fairly common.

I've noticed that trend in many interviews I've been in and had interviewers bluntly tell me they will keep asking harder questions until I miss one, so see my technical depth.

I've found that if you say you know language/api/framework X you had better be able to answer all the basics with concise answers in a friendly (non-condescending) tone. That may mean some studying and practice on the job hunter's part, but it pays off two ways: you're already ahead of the arrogant candidates and you may convince an interviewer you know your stuff quickly, so they skip the hard questions.

* At your level of experience, you should ABSOLUTELY have only one page. If your LinkedIn profile is a reflection of your current resume, there's a fair amount you can cut from that if you need to make room. Things like "Tool was eventually taken up by QA team" isn't terribly relevant, and the BCCampus Research Assistant unfortunately sounds a bit like fluff.

* Don't expect anyone to have given your resume more than a cursory overview. Instead, plan on that and make sure that your most important bullet points stand out on the page. You can do this by re-ordering your information or by varying your whitespace, verbs used, and sentence length.

* Think about implementing a template from http://www.oswd.org/ for your personal website. You may not have design skills (and even those majoring in design often lack them out of college), but at least show you can recognize good design and follow directions by implementing one of the free templates there

* I normally hate to flaunt my own stuff, but I wrote an article recently on some of my personal pet peeves on resumes - http://citizenparker.com/post/Spray-and-Pray-Developer-Resum...

I would be happy to give your resume a more in-depth review and follow-up with you personally. Get in touch on my website if you're interested. Either way, good luck and don't give up.

Regarding interview attire, people ask because some teams are flip-flops and gym shorts casual while others wear suits every day. Wearing a suit to the flip-flops team interview is almost as bad as dressing down for the business formal team. Given the interviewee can't divine ahead of time with which type of team he's interviewing, the only safe thing to do is ask.

if you do manage to get to the interview process, ask about the job you are being interviewed for so you can get a better understanding. a job interview is a conversation, so it goes both ways. try to find out why they are looking for a new employee. for example, they may be looking for a system administrator to do sysadmin tasks, but if you ask further, they might tell you that they are in the process of trying to scale their systems, at which point you can talk about your past experience or what ways your might go about developing a scalable architecture. make yourself relevant.

all too often, candidates just come in and sit quietly, waiting for the interviewer to ask them question after question, trying to pull information out of them and then it simply becomes checklist of questions to tick off (while looking at your watch) before thanking the interviewee and showing them the way out.

I would recommend putting some personal pics of you and your friend’s mountain biking on your webpage. It will make you come across a little different than the other candidates.

Also, the page looks very 1998-notepad-hand-coded html. Not the best calling card for a computer geek dude. Go get some Dreamweaver time somewhere and make a nice layout. Focus on an eye pleasing font and page color. If you are not layout talented look into using one of the templates out there on the web. Make it nice and professional then add some fun interesting looking personal pics and head your resume with your webpage address. It might help your job prospects.

http://yangman.ca/

But I still think it's sad that someone's personal home page must be directed by the current perception of what's the "cool" thing to do (for that matter, using Dreamweaver is more what the "cool" thing was in the late 90s). A plain HTML page says "open-source hacker". But it only says that to other hackers, so this will only help you if the person doing the hiring is technical. A "generic HR person" might prefer a "generic stock template".

Sure, you're looking to get hired for your code chops - and your employer is looking to hire you for your code chops, but in a sea of new grads something has to make you stand out. Given that traditionally hackers have been very bad at design, UI, and aesthetics, being one who isn't blind to these virtues is very valuable indeed.

And image is everything, especially when trying to get hired.

I think the submitter is off to a good start - he doesn't portray himself as the stereotypical hacker. He's active, he loves mountain biking, and his life doesn't revolve around sitting in front of the terminal. Great. Having sifted through piles 'o resumes before, I can tell you he's already on the top half (yeah, it really is that simple to get in the top half of the pile, especially for new grads). Oh, it's not just the mountain biking, it's the fact that he appears to have substantial actual code experience (as opposed to "I took a class on that").

Uhoh, I think this about to turn into a short essay:

For the submitter: I grew up in Metro Vancouver, and before graduation I did make a concerted effort to find code jobs there - the pickings are truly slim. Have you applied to jobs out east? Toronto, Montreal, and Ottawa are all epicentres for tech jobs in Canada - far moreso than Vancouver. Also do not neglect the good old US of A, as a Canadian citizen getting a TN visa is almost trivial so long as you have a job offer. Oh, and for some odd reason Nova Scotia is also pretty rich in programming jobs...

I see you went to SFU and seem to have a co-op term of experience - this is good, but to be perfectly honest may not cut it against other candidates who have more fleshed out co-op experiences through university. Your cards have been dealt and you must play them, but remember this as a potential comparative weakness and try spin your open source contributions more strongly.

To address your concerns directly from my own pre-grad job hunting experience (as well as 6 co-op terms of sometimes insanely difficult job hunting): do not expect companies to call you back, or be overly timely on most contacts. In this market there are far more employees than positions, and while it would give everyone warm fuzzies to give personal callbacks for failed interviews, this realistically isn't going to happen. Not calling you, for better or worse, is the de facto standard for most jobs. Also, being disappointed at your lack of experience is not really lacking in courtesy - it's a fair observation that may actually be correct.

If you want a response, call them. No, I'm not being sarcastic, condescending, or facetious. I've opened more doors cold-calling people than any job website or spiffy resume has ever earned me. Differentiate, find out who will be reading your resume (cold calling works wonders here) and pen a cover letter with their name on it. Talk to your interviewer, ask questions, make an impression outside of the interview room. This goes back to the point about differentiation - it makes all the difference in the world (it is worth noting that this works both professionally and romantically ;)). DO NOT treat the job like "yet another job" - for the interviewer that leaves a very bad taste. Failing to be knowledgeable and curious about their work and their company is very bad for this reason - you are communicating that they have yet-another-generic-position-at-generic-company. Showing enthusiasm about what they do, and asking good question, especially pre-interview (e.g., during the job fare) is a very, very good way to make a good impression. It may shock you how few people do this.

Whatever you do, do not treat the job finding process as mechanical - that you toss your resume in one end, follow the handy on-screen instructions, and kablammo! Job! No, it doesn't work that way - every worthwhile job I've ever had has been hard fought and won. Following the "rules" (submit resume, wait for response, go to interview, wait for response) is honestly for suckers, and you'll be one too if you follow it without deviation.

So because thechnology gives us the excuse to be rude? Just opinion here, but if a business takes the time to bring a candidate in for a day of interviewing they are obligated to fnish the process which incldes delivering the bad news i they are not selected. I feel that anything less is bad manners and unprofessional, even if that has bcome the norm.

Sorry for being a bit off-topic there, but I'd like to comment on that bit. 1998-style code would be a non-semantic mess of tables and other elements thrown in just for a visual effect. Code of yangman.ca however is very clean and semantic. I wish all those zillions of web agencies and "professionals" who are stuck in last century would be able to write code as good as this. Getting DW won't help a bit there. Adding some niceties via CSS may.

- Any effort you make to show interest in the company goes a long way. Use the software, come prepared to talk about what you did/didn't like, and have questions for me. Are you interested in working here? Then you should be full of questions!

- Have a personal home page. Doesn't have to be flashy, but it should suit its purpose. An appealing website is nice (it says, I have some design taste, and I can do basic design tasks on my own), a sparse website can also communicate something (here is a list of my impressive projects, I am very technically knowledgeable). If you can combine both, even better! :)

- Work on cool stuff. This is the #1 differentiator (and it's all about differentiation). If you have 3 links to something really neat you worked on in the last 3 years, that places you well above most other candidates -- it shows that you love what you do.

- Be excited! I know you're probably nervous (most people in interviews are, and hey, your interviewer might be too), but get yourself excited about the job, and show it. Startups need enthusiasm and commitment, and this is a great way to show that you're going to be someone who ups the energy level.

You'd be surprised how many people fail here on some basics. Getting hired is a differentiation game. Your resume doesn't get you an interview (it can only prevent you from getting one). A short email along the following lines places you in the top 90% of candidates who apply:

"Hi [company person],

Josh [mutual friend] sent me your job listing for a web developer, and as I was reading it I kept thinking that it sounded like a perfect match.

I'll be graduating from [school name] this spring and am currently looking for a full-time position. I've been following [company name] for a while and love what you guys do.

I've attached my resume, but even more importantly, you might want to check out some of the projects I've been working on recently: [really cool project 1], [really cool project 2], [really cool project 3].

Feel free to call me anytime at [cell], or email me back.

Looking forward to hearing back from you.

[name]"

- Any effort you make to show interest in the company goes a long way. Use the software, come prepared to talk about what you did/didn't like, and have questions for me. Are you interested in working here? Then you should be full of questions!

- Work on cool stuff. This is the #1 differentiator (and it's all about differentiation). If you have 3 links to something really neat you worked on in the last 3 years, that places you well above most other candidates -- it shows that you love what you do.

I was interviewing someone for a mid-level systems engineering position, and the interview seemed to be going well-enough. I always wrap up with a few minutes for the candidate to ask questions about the company, and the only question this candidate had was "Have you guys ever considered building a website where people can design and order business cards?"

Blink; blink; WTF? Uh, yeah, we did about $250M in business that way last year, so I'd say we've given it some thought.

An employer is going into the interview with some need that they're hoping you can fill. That need is almost certainly not "I need to make sure the next person in the door can pay rent and buy food." so you shouldn't go into the interview focused on that either. By all means, you have your own set of needs that you need filled, but in the interview, focus on the employer's need, not your own.

If given a programming problem, don't stand/sit quietly while you work out the solution. Give the interviewer some insight to your thought processes. It would be nice if you could answer the question correctly. What would be best is if you can express to me that you're going to try different approaches to solve a problem when you hit a roadblock.

If you need help and it is offered, take it. Quite a few candidates got very close to the solutions but were too stubborn to accept help when it was offered. That sealed the deal on me not hiring a handful of people.

If you really don't know the answer to a technical question just give it your best shot. Admit that's all you've got and ask the interviewer how he would solve the problem. What I'm looking for in that situation is that you can show me honesty and that you are genuinely interested in learning that which you don't currently understand.

If you wrote your own resume, have it edited and cut down to size by someone completely non technical. Less is more as far as resumes are concerned.

Be prepared to answer ad hoc questions based upon things you put in your resume that you profess to be an expert in. For example, if you put Javascript on your resume instead of just jQuery or some other framework I'm going to ask you about the prototype, variable scope, and closures in the language.

Quite a few candidates just stared blankly near the end of the interview when I asked them if they had any questions for us. Ask questions about the technologies we use and why. Ask us what hard problems we've had to overcome. Engage with us, your future coworkers.

Smile. Be sure to smile.

I think most of us are much more naturally going to sit and quietly do our work, as we have done all our lives, unless you're asking us to talk you through what we're doing.

I'm not in the habit of shouting out what's going through my mind as I'm working.

This is an interview, your "customer" is the interviewee, and the answer you are trying to impress on your "customer" is that you are smart, articulate, personable, etc. Even more important, can the candidate look at an obvious question (the quiz) and see the underlying real question (is this candidate outstanding?).

All the things that don't come through on a paper-and-ink resume.

P.S. I've worked with lots of engineers that answer the question that is asked, but never think about what is underlying the question - sometimes the question is wrong. That is the difference between "smart, and gets things done" http://www.joelonsoftware.com/articles/fog0000000073.html and "done, and gets things smart" http://steve-yegge.blogspot.com/2008/06/done-and-gets-things... (a GREAT rant).

As for me: I hired recently for an open-ended contract position through Craigslist. The pay was pretty good, given the area I'm in. However, the vast majority of the applicants couldn't be bothered to tell me anything about themselves. Most of the responses were along the lines of, "Here's my resume". That was it, nothing else, and the resume just included their work history.

I'd like to know a little bit about the person applying. Just a paragraph would be fine. Don't limit it to your work experience; your hobbies and how you spend your free time tells me a lot about you.

Good luck. It's ugly out there right now.

I also look for people who know why rather than just how. I'm looking for someone who understands the platform (generally a flavor of Linux) rather than someone who is great at rote-learning commands (which a lot of lower-quality Unix people get by on).

Another poster mentioned APIs rather than languages, and I agree: on both sides of the table I've bonded with the other person over specific Python APIs and their benefits and drawbacks.

I use progressively harder questions like a lot of candidates but make sure that the interviewee understands this, so they don't feel as if we're wasting time on the simple stuff or above their heads on the really difficult final questions.

I also look for people who are still passionate about technology outside of work. This rare, but sorely needed, in corporate environments.

What I worry about most is whether someone will be easy to work with. I assume most people have made it through the resume sorting process by the time they get to me (I'm just an engineer were I work, we're a small company, the boss did the initial vetting).

They were both so worried about making a good impression, I couldn't get them to open up and talk to me. I couldn't tell if they had a sense of humor, or if they were flexible enough to learn something new quickly, or anything else really.

So, my advice.. BE YOURSELF. Write a resume that reflects who you are, This will make you attractive to people who would want to hire you. When you interview, just BE YOURSELF. If you are goofy, let it show. Talk about your enthusiasms, show that you aren't a cookie cutter job applicant. Stick out...

You don't want to work for someone that doesn't want to hire you, it'll make you miserable. I've had several really cool jobs (911 dispatching software, glass panel cockpit displays, digital music encoding/distribution, designing paper airplanes...), and I got all of them because I went in to the interview knowing that the guy doing the hiring interviewed me because he could think of me as someone he could work with from my resume, and we 'clicked' when we met in person.

Everyone is going to give you a list of things you should/shouldn't do in resumes and interviews, but except for the obviously universal ones (spelling/grammar/personal hygiene...) these lists are full of exceptions and personal taste. Do what YOU think is the right thing, this will innately sell you to the kind of people that you want to work for.

One of my previous bosses is a regular on here, he's probably going to laugh himself silly if he reads this (I wasn't always the best employee once I got hired -- but that's another story...)

Good Luck!

* Most interviewers, especially at big companies, don't take the time to read a resume in detail. Also, it is usually difficult to access websites if all they have is a hard copy of your resume. Make it easy for the interviewer to access your work during the interview. Use a URL shortener and have links ready to - your online resume with links, rich info (images, charts) about your work etc. It helps to be prepared if the interviewer brings along a laptop. Talking someone through your work when they are looking at it is always better than just talking about it.

* Research the company before the interview. It's always a red flag if a candidate doesn't have any questions about the company they are about to work for. The more you can show the interviewer that you've done your homework, the more likely they are to consider you seriously.

* If possible, learn more about your interviewer before the interview. Google and LinkedIn are your friends. It helps to have some context.

All the best!

The second point, I think, deserves some more discussion.

There's no denying it: I consistently fail at coming up with questions to ask when an interview nears its end. Although I do try and ask small questions along the way, after the whole thing is done, there's just nothing else I care to know about that's appropriate at this stage in the process. In terms of work environment, if it was interesting enough to talk about, the interviewer would have already given me a spiel or the topic comes up naturally. The actual work gets discussed in some detail regardless, so there's not much else there without actually working on it. Having some opinions about the product in question would be nice, but no such luck there either: they've all been doesn't-exist-yet, enterprise apps, and generally things the general public doesn't have enough access to to be able to have an informed opinion about. That said, if the other side cooperates, I generally try and make the interview into more of a conversation, and seem to leave a very positive impression on the interviewer. Doesn't really help with the having-a-question-to-ask at the end, though.

What sort of questions do you really hope a keener would ask?

* What would you consider the average size of a working team, here? (You'd be surprised- sometimes the answer is '1', sometimes it is '50', and the discussion this generates is usually worthwhile. )

* What kind of kid buys Armor Hot Dogs? (Fat kids. Skinny kids. Kids who climb on rocks. )

* (to a developer) Tell me about what _YOU_ do. Could you describe your day-to-day routine to me? (It's open-ended, and certain answers, like 'rock back-and-forth, in the corner, in the fetal position, cradling a rifle' or 'ASP.NET programming' are sure signs that you might want to stay clear. Good answers include 'something different every day' and 'sneaking into homes to steal pens'.)

* What would you imagine that I would be doing, here? ("Mopping.")

* What are your opinions and policies on ongoing education, here? Do you have resources? Do employees attend conferences? (Some companies will laugh you out of the office, and/or point at their tiny 'reference shelf', many others support this sort of initiative. It's best to gauge this before you ask the question.)

* Try to identify things that your interviewers seem especially proud of, and ask them about those things - even if you already know the answer, they will be happy to talk about them. (Say, for example, the HR person repeatedly mentions the innovative "80/20" policy. Despite that you know what an 80/20 policy is, like the back of your freaking hand... ask questions about it, to show interest. )

* Who, exactly, put the ram in the ramma-lamma-ding dong?

* What sort of source control do you use? (This is seriously important. You might get stuck using something vile like CVS or SourceSafe. On top of that, asking this question demonstrates that you are aware of the importance of source control, a point that you could always drive home.)

A couple of more-precise but ultimately not-that-useful technical questions can help, too. If a company is doing web technology, ask them what sort of hosting arrangement that they have, whether or not they have a dedicated sysadmin, whether or not they have a development/production split, how changes get moved from development to production, if they do code reviews, what development methodology they prefer, etcetera, etcetera.

And you must always, always blow on the pie. I mean, ask at least one question. You must always ask at least one question.

Asking for a tour is always good(Not just the spot where you'll be working). You can pick up a lot of things from looking around. Coffee quality and the state of the server room are two particularly important areas to look at.

Comparing where any execs are working to where the devs are working is also pretty useful for getting a pretty good idea of how power relations work.

On questions, you can always ask about -

* the team you'll be joining

* if it's a small company / startup ask about their business and competition. An engineer who shows that he understands how his work fits into the larger picture is far more valuable than one who is happy to just write code.

* learning opportunities - large company or small, dig into what it is you can take away from the job

Of course, there's no point in making it a formality. What would you like to know about something you might be doing for the next few years of your life?

You're a job candidate yes, but you're an interesting person with tastes and opinions, so act like one. Don't be overly formal in dress or manner, be ready to ask the interviewer tough questions of your own, and indicate that you are not your average candidate. The candidates I like best are the ones who act like they are sitting on the stool next to you at the bar, and keep it friendly and open rather than playing into the interviewer-interviewee roles.

I think aaron swartz summed it up pretty well too: http://www.aaronsw.com/weblog/hiring

My opinion is unlikely to match with big corporations. Also, I'm not a skittish woman, so I don't care if you Google-stalked me to figure out what to give me. Besides, I think everyone I've interviewed in the past year has anyway, so I'd rather I got something out of it.

I did send my HR contact at my last employer cookies, and she just loved it. It's not a huge place, but it's big enough to have an HR dept.

I never wanted to make this about myself, but I thought it appropriate to point out that I just received and accepted an offer from a place I interviewed with last week (one of the few fantastic interview experiences I've had). Much thanks to all the encouragements and good lucks, and even queries.

Now, please ignore this message, and return to our regularly scheduled discussion. :)

The fact that I walk into the interview room knowing less about your resume than you do is your problem/opportunity, not mine.