[mikeblas]

Through my involvement in the hiring process at the companies where I've worked, I suppose I've read a few thousand resumes during my years in the industry. Every company looks for different things; a company might look for different things to fill different positions at different times, too.

There are some universals, though, which make a candidate face an up-hill battle going forward.

Appropriate experience for the goal. If your resume includes a goal statement, make sure that it is congruent with your previous experience. I'd love to be a Formula One driver, but I'm just not going to get there. And nothing on my resume implies that I'm on a path to that career, either. If you're working on web development, saying that your goal is to run a hot social networking site makes sense. Saying that you want to work on databases doesn't. I look for execution--real progress--towards the goal.

Thoughtful goal statement. Largely, I worry that goal statements do more harm than good. I'm left wondering why the candidate chose that goal (and if they thought their previous work was really getting them there, as above). The I read goal statements like "work on large internet-scale systems" and realize the candidate hasn't thought through why such systems exist. Goals are to serve customers, or solve problems; doing the work necessary to deliver those solutions is secondary to the solution. Your goal should be about solving a problem or filling a need; not riding a particular technology.I look for a clear meaningful goal, which is measureable, realistic, and sensible.

Your involvement. Resume writers don't serve themselves well by failing to describe their exact involvement in a project. Were they the brain child that came up with the original idea? The technical lead? The architect? Or the water boy? Did they just happen to be on the team when the work was being done? Spelling out what you did and didn't do is very important; it lets the people do the hiring see what you're really all about--what you really do. I want to learn what you did, how much of it you did, and how many other people were inolved. Metrics help; 50,000 lines of code in a 2.5 million line system, and so on.

Forget the altruisms. Self-descriptive altruims are just too trite to read. "Quick learner", "enjoys challenges", "Self-starter", and so on, are all things I'll find for myself in the phone screen when we drill into your past experience. Writing about your ideals in your resume doesn't make it true. I find reading through these tedious and nearly insulting.

Document slingers. Larger companies, in particular, seem to promote particular methodologies; scrum, agile, XP, or even plain old waterfall. Pointing out that you're a document slinger does nothing for your chances. You need to be able to think through problems even when your Scrum is failing you, or when you don't have a pile of documents reminding you what the right thing to do really is. I'm not looking for documents slingers at all; when I see this, I just think the person was a cog and not really influential in the project. Maybe some companies--those who are involved in these methodologies--are eager to see this stuff.

Experience and buzzwords. Lots of technical resumes list buzzwords. You shouldn't enumerate every language you've ever used; you shouldn't list every OS you've ever heard of. If you're truly experienced with that technology, then fine--list it. If you can't answer simple questions about it, or compare it to competing technologies on your resume, or aren't at least "very good" with the skill, then pass it by. I look for buzzwords that match the rest of the experience.

Errors. Spelling, formatting problems, and even clearly shitty layout style count against you. We'd like to think that people would overlook such things when evaluating us, but they don't. Particularly in a field as exacting as software development. One or two subtle errors aren't a big deal; but many, or an obvious problem in formatting, are distracting.

Explain why. Did you write a compiler for your own language? Build a cool electroncis project in your spare time, or for a contest? Implement a thing that talks to the servers from some other thing? Why did you implement it? Why did you choose the language you used? What did you learn? If you're just sitting around doing what your boss tells you to do, or shoving in the assignments your professors give you, what value will you really add? Did you make your own web site, or register your own email address? Are you prepared to explain why you went through that trouble and expense? I look for solid, explainable answers. Even if I don't agree with the reasoning or the result, some thought needs to have gone into the decision.

If you get past the resume reading, you'll probably get a call back; a phone screen, or maybe straight to an interview or an interview loop. Then what?

Check your arguments. Going on a rant about a particular technology or language is a bad idea. Be pragmatic and comparative. Everything has it's place; are you good at identifying which tools and techniques to use, and when? How will you demonstrate that? Again, I'm looking for thoughtful reasoning and measurable results.

Research the company. What are their products? Who are their competitors? What good questions can you come up with about their business model or history? What's their direction? You'll want to be able to converse about these things during down time in the interview, or when offered an opportunity to ask questions. I like to hear about strategy; "why doesn't the company do such and so"? is pretty dumb, unless you can explain why such and so would be a great idea.

Think aloud. I covered this in the other thread about questions, but what you want to do is show how you approach problems and the way you think things through. Generating ideas is important, but you also need to know when to pare down the good ideas an start making progress. The trick here is when to when to give up; if your approach isn't going to yeild results, you need to be ready to give up on it.

Humility. Nobody's perfect, particularly people who think they are. You should be prepared to discuss what you did that went wrong, and what you learned, and why you'd change. That you've made a gaffe isn't the issue; that you can learn from it and understand it is what's important. I like answers which are introspective, and still realistic.

The rest of your resume--the actual content, not the delivery-- is going to be what gets you your new job, in the end. The way you present yourself, and your knowledge, really does matter, though.

I hope this helps you think about your resume and the hiring process. If you've got questions, I'm happy to try and answer them.

[c0mrade]

Excellent write up.. should be 'featured'

What about length? I hear a lot that a CV should detail my involvement in projects, but I also hear "if it doesn't fit on the first page it won't be read".

I suspect their is truth in both sides.

[mikeblas]

A resume should be concise. Your goal is to explain why you should be hired; why you're not a risk, why you're going to add to the company and be a good long-term investment.

If you've got lots of experience, then you need to write it; as concisely as possible, that can add up.

My own resume is three pages, and that's only my resume proper--if I include my bibliography and catalog of speaking engagements, I end up at nine pages. When I apply for a job or post it around, I include all nine pages. For other cases, I just send the resume, which has "writing highlights" and "presentation highlights" sections.

So, I guess I'm walking the talk--I don't think there's a length limit. The thing is, the content is important. If the resume is long because of goofy spacing or huge indentations, then that's a problem. If the resume is long because it's full of vapid drivel like "self-starter, eager to learn, extremely helpful and friendly", then it's too long.

Some resumes are like mine; they'll include ancillary material. Artists include parts of their portfolio, some writers include writing samples, and so on. There's no reason to not include this kind of material.

That said, I don't think code samples are meaningful at all. There's really no way for me to know if I'm reading code the candidate wrote, or if it's code that he downloaded from Pirate Bay. Even if he did write it, I can't tell how traumatic that was. Did he knock out this impressive routine over a weekend, or did it take nine weeks of tedious debugging and trial-and error? What's more important to me is the ability to write the code that's for the right job. (Of course, I mostly interview candidates for more senior positions; that might not apply for entry-level positions or internships.)

And, of course, everyone is different. I don't care how long a resume is, and read them if they're interesting. If they're not, then I stop reading. It's not about page length; it's about quality and relevance. I'm sure the same lot of people who think that free email addresses are a mark of low-quality would bin my resume because it's too long.

I hope that helps.

[c0mrade]

Quote

I hope that helps.

Helps a ton, thank you.

I guess I'll just pull a little more info out of you then.. I'm really early on in my career (not even in college yet), but I have done quite a bit of freelance projects. These projects are generally around one month in length (part time).

Do you think I should even list these projects? Should I, instead of listing each project as a seperate job, have one section under 'Experiance' for 'Freelance Work' and just list highlights?

EDIT: How do you see freelance work listed (if at all) on resume's you review?

This post has been edited by c0mrade: 18 April 2009 - 08:32 PM

[maffelu]

Heh, this was a good follow up on the previous thread.

How do you view resumes that point to a website for more details on experiance, say if you have a site with solutions to problems in your language or forums to discuss them? Is it worth adding or should everything be on that paper?

BTW, do you look for people on community pages?

[Imdsm]

A very nice article mate!

Question 1: how do you view open source experience as opposed to commercial experience?
Question 2: how do you view self taught experience as opposed to academic (university) taught students?

[mikeblas]

c0mrade, on 18 Apr, 2009 - 07:32 PM, said:

Do you think I should even list these projects? Should I, instead of listing each project as a seperate job, have one section under 'Experiance' for 'Freelance Work' and just list highlights?

If that work is the experience you have, then you should list it. Some people will list their work with a date range and job title. You might list your regular job and its work, then with an overlapping date range list your freelance or consulting projects.

Whatever you do, make sure you check your spelling before you send your resume along.

maffelu, on 18 Apr, 2009 - 11:17 PM, said:

How do you view resumes that point to a website for more details on experiance, say if you have a site with solutions to problems in your language or forums to discuss them? Is it worth adding or should everything be on that paper?

I can't imagine sifting through a forum to read stuff like that. I just don't have the time, and I'm not sure input it would give to my decision. If the resume has made me interested in the candidate, I might review some of the linked material to get a better feel for their work, or ideas for questions to ask them during the subsequent phone screen or interview loop.

Funny thing is, what you do online might also be a negative. Candidates sometimes link to a blog in their resume or cover letter, for example. The blog is full of venomous, ranting posts that are nonsense; sometimes even flaming the company where they're applying.

maffelu, on 18 Apr, 2009 - 11:17 PM, said:

BTW, do you look for people on community pages?

No.

[Prague Hotel]

This was a helpful post. I guess I should not list my hotel experience in Prague and say that my goal is to develop a booking system for hotels then.

[mikeblas]

Imdsm, on 19 Apr, 2009 - 02:29 AM, said:

Question 1: how do you view open source experience as opposed to commercial experience?

Largely, I evaluate it the same way I do commercial experience. Are you just poking around and fixing bugs? Are you just working to deliver the ideas that someone else had? Then I'm not too impressed. Are you pushing the project or product towards completion and delivery? Are you implementing things that make customers of that project really happy? Then I'm more interested.

I think open-source work is at a bit of a deficit when it comes to shaping someone's ability to work on a team. Sure, open-source projects get big and end up being successful; but mostly they involve working on a shared code base remotely. Generally, this kind of work doesn't foster team skills, doesn't build rapid communication and dispute resolution skills, and so on. There certainly are exceptions, but that's the broad-brush answer.

Most of the people who I meet and involved with open-source projects seem incapable of delivering world-class software. Sourceforge is littered with half-baked, unstable projects that aren't going anywhere. They also tend to carry prejudices against commercial software or projects, and end up sabotaging themselves when those views are exposed in interviews or screening conversations.

These are all pretty big generalizations, of course -- which is why I try to evaluate open-source guys individually, on the same merits that I evaluate commercial guys.

Imdsm, on 19 Apr, 2009 - 02:29 AM, said:

Question 2: how do you view self taught experience as opposed to academic (university) taught students?

I'm not really sure I care about academic background. Lots of people are successful without it, myself included. The are also lots of people who get degrees in some un-related subject, find computers, and then switch to that field. Perhaps surprisingly, I'm not too interested in post-graduate work. My company is more interested in generalists, and a focus in a masters or doctorate program doesn't really lend itself to learning broad reaches of technology or technique. Other companies favor that kind of study, so I think it's situational.


BTW, I should make it clear that all my answers are about the way that I hire, and pretty much the way my current company hires. Other companies, and other people, have different goals for their company and employees and hire differently as a result. For resume writing, I think it's pretty easy to make generalizations about how the resume should be written and the goals you should have in mind when writing it. For these more specific questions about experience, I think it's important to realize that the answer is very much dependent on the company or position for which you're applying and that my opinion on it might not completely apply to some other company's hiring practices.

[Imdsm]

mikeblas, on 19 Apr, 2009 - 05:58 AM, said:

BTW, I should make it clear that all my answers are about the way that I hire, and pretty much the way my current company hires. Other companies, and other people, have different goals for their company and employees and hire differently as a result. For resume writing, I think it's pretty easy to make generalizations about how the resume should be written and the goals you should have in mind when writing it. For these more specific questions about experience, I think it's important to realize that the answer is very much dependent on the company or position for which you're applying and that my opinion on it might not completely apply to some other company's hiring practices.

Of course. Nevertheless, thank you for interesting and enlightening answers!

This thread is a great read for aspiring and achieved programmers alike. Good job!

[jjsaw5]

Very Nicely done! This is one of the better write-ups I've read dealing with Resumes.


Great job!

[ibichi]

i have to say... your thoughts on "document slingers" show your ignorance of these processes.

my team started scrum, and i must say... (after 7months) that because of the skills/discipline i have gained from scrum, i could walk into any non-scrum shop and be immediately viewed as a total bad-ass, not a "cog". it turns work into a sport, almost -- and it forces you to be able to set clear goals and give REALISTIC estimates on how much time it will take you. these skills are extremely valuable... especially to your boss.

if you turn people away for that, you are making a mistake.


other than that, sound advice & great read.

[mikeblas]

I've spent plenty of time with the processes you're accusing me of being ignorant of. Perhaps you're assuming I'm ignorant of them because they don't appear on my resume.

When a candidate describing experience with formalized process instead of the ability to manage himself or his project, it tells me that he's just following the process, not working to the situation. It implies that he won't know what to do when the process breaks down.

A resume should tell the recruiter or hiring manager what makes the candidate exceptional. I don't consider the ability to set goals or manage one's own work exceptional in the slightest. I view it as something that's a core competency. Most of the formalized processes are about putting core competencies in clown suits so that people with less weak management skills can use those tools to manage the team.

At the end of the day, the goal is to make happy customers. Being held to the rules of a process in order to deliver on that goal means that the rules are in the way and an aid.

At the company where I work now, writing a resume like that it isn't fatal --but it means that we'll push pretty hard on project and self-management questions in the interview as we don't use formalized processes. If a candidate can demonstrate competence outside of the framework that process gives him, then that's what we want.

[ajaymatrix]

Here is another one, albeit a lighter take : http://www.hanovsolu...esume_comic.png

[KYA]

ajaymatrix, on 4 May, 2009 - 08:14 PM, said:

Here is another one, albeit a lighter take : http://www.hanovsolu...esume_comic.png

That's what spawned this thread.