What hiring managers hate about your resume

So you say you’ve sent out 4 million resumes and have not gotten as much as a nibble? If you’ve got the right experience but you’re just not getting your foot in the door anywhere, maybe there are problems with your resume. I recently asked TechRepublic members who are IT managers what kinds of things make them want to just chuck a resume in the trash.

You would do well to take a look at their comments and then go back and take a look at your resume. Are you guilty of any of these?

* Grammatical/spelling errors
Too much information (or as GSG says, “I’m hiring you for a job. I don’t want to know about your 4 kids, that they are (in your opinion) little Einsteins, your dogs, your husband/wife, or your hobby of knitting little stocking caps for the poor little cold kittens.”)
* Information provided that the interviewer can’t legally ask for (marital status, age, religion)
* Unexplained date gaps in work experience
* An overstatement of technical skills
* Bad formatting (TiggerTwo hates “the failure to place the most important information in the top third of the page, lack of white space, a bunch of keywords that appear to exist only to be keywords, failure to provide a skills listing, use of less than 10 point font, and use of a difficult-to-read font.”)
* “If you can’t tell from the resume alone if the owner is enthusiastic about (some aspects of) his previous job experiences, the resume is out.”
* Not highlighting actual results delivered
* Overly long resumes. According to frostbite, “anything more than 2 pages is a hard read, more than 4 is a tome.”

wish this will help you cracking the next best job..
cheers Aurobindo

courtesy @TechRepublic

Nineteen words that don't belong in your resume

Overview: Career coaches or head hunters may have told you that creating an effective resume means punching it up with jazzy verbs and adjectives. Not so, say IT hiring managers. In fact, if you're using glitzy modifiers, you could be doing your resume more harm than good. Here's a look at some recruiters' "favorite-hate" resume verbiage.

It’s hard to believe that a few words could irritate someone enough to make them stop reading your resume, but it’s true. Some hiring managers and recruiters admit that they have their own mental lists of words that annoy them. Resume how-to books may recommend that you pack your resume full of as many verbs, adjectives, and adverbs as you can. But if you aren't careful, you could turn off more prospective employers than you entice. Effective word choice is what really appeals to hiring managers—not action verbs and glittery modifiers. Here's a rundown of some words that hiring managers say detract from the persuasiveness of resumes they see.

Term: Assist, assisted
Reasons to avoid : Hiring managers want to know what you did, not how you helped. If you're familiar enough with a task to put it on your resume, you can choose a better word than assist.
Example: Assisted marketing director by researching PDAs.
Possible rephrasing: Researched PDAs for marketing department.

Term: Experiment
Reasons to avoid : No one wants to hear about what you tried to do—only what you have accomplished.
Example: Experimented with new LAN management software.
Possible rephrasing: Tested and evaluated new LAN management software.

Term: Skillfully, effectively, carefully, quickly, expert, mastered
Reasons to avoid : Hiring managers often object to words that describe how well you do a particular task. In many cases, it comes across as boastful—and it's unnecessary. “If you aren’t good at it, why are you putting it on your resume?” one recruiter said.
Example: Skillfully managed transition from Windows NT to Windows Server 2003
Possible rephrasing: Migrated organization from Windows NT to Windows Server 2003 with no downtime during business hours.

Term: Cutting-edge, detail-oriented; coordinate, facilitate, transform; proven ability, synergy, and liaison
Reasons to avoid : Hiring managers say such words take up space without communicating much. They've seen them so often that the words have lost their original energy. Provide details and substance, not tired business jargon.
Example: Detail-oriented manager with proven ability to oversee day-to-day network operations and to implement major technology initiatives.
Possible rephrasing: Supervised an eight-member IS staff; completed two full-scale platform migrations; consolidated equipment and resources following facilities move.

Term: Responsible for…
Reasons to avoid : You’re a manager, so of course you’re responsible for something. Specify exactly what your responsibilities are and work in a few numbers to convey the scope of what you do.
Example: Responsible for managing inventory, overseeing network operations, making new equipment purchases, troubleshooting workstation issues.
Possible rephrasing: Supervised the support of 70 users running Windows XP and two servers running Windows Server 2003; implemented asset management plan for inventorying equipment; built a network operations team responsible for the internal infrastructure.

courtesy @TechRepublic

10 signs that you aren’t cut out to be a developer

Programmers make big bucks. Software developers dress casual every day of the week. Anyone can teach themselves to be a programmer. These are just a few of the reasons why people say they want to become a developer. Unfortunately, the job market is littered with people who may have had the raw intelligence or maybe even the knowledge, but not the right attitude or personality to become a good programmer. Here are a few things to consider when deciding whether you should become a software developer.

#1: You’d rather be trained than self-teach

In most development shops, there is rarely any training, even if the company has a training program in place for other employees. At best, the company might reimburse you for a book you buy. Programmers are expected to arrive on their first day with all (or at least most ) of the skills they need. Even worse, the assumption is that programmers are really smart people who are good at problem solving. That assumption leads upper management to believe that good programmers do not need training. Finally, training for developers is extremely expensive. The result? When you change positions, you will need to figure out what is going on yourself, and you will probably need to teach yourself.

#2: You like regular working hours

Software development projects are notorious for being late. Even the projects that are delivered on time always seem to run behind schedule at some point. If you don’t like (or can’t handle) irregular or fluctuating demands on your time by your employer, development is not for you. When crunch time comes, your employer is more concerned with getting the product in the hands of a million-dollar client than with your child’s soccer game or the new TV program you wanted to watch.

#3: You prefer regular raises to job-hopping

The world of development is one of continual erosion of skill value. Unless you are working at a shop that deals with slow-to-change technologies, chances are, your skill set is less valuable every day. The state of the art is changing rapidly, and the skills that are hot today will be ho-hum tomorrow. As a result, it is difficult to sit at the same desk doing the same work every day and expect a raise that exceeds a cost of living increase. You need to keep your skills up to date just to maintain your current value. In addition, if you want to boost your paycheck, you need to expand your skill set significantly and either earn an internal promotion or go to another company.

#4: You do not get along well with others

It’s one thing to be an introverted person or to prefer to work by yourself. It’s another thing to be unable to get along with others, and it can sink you as a developer. Not only that, your manager may well be a nontechnical person (or a technical person who has not worked hands-on in some time), so you need to be able to express yourself to nontechnical people.

#5: You are easily frustrated

Software development is often quite frustrating. Documentation is outdated or wrong, the previous programmer wrote unreadable code, the boss has rules to follow that make no sense… the list is endless. At the end of the day, no one wants to be working next to someone who is always cursing under his or her breath or screaming at the monitor. If you are the kind of person who goes insane spending eight hours to do what appears to be 10 minutes’ worth of work, this is not a career for you.

#6: You are close-minded to others’ ideas

In programming, there are often problems that have only more than one “right” answer. [Update: Corrected by author] If you do not handle criticism well, or do not care to hear the suggestions of others, you might miss something important. For example, a few weeks ago, one of our junior-level people made a suggestion to me. After considering it for a bit, I decided to try it. It turned out that he was right and I was wrong, and his suggestion brought the time to execute a piece of code from multiple days to a few hours. Ignoring this person due to the difference in our experience levels would have been foolish.

#7: You are not a “details person”

Programming is all about the details. If you get lost in a movie more complex than Conan the Barbarian or have a hard time filling out a rebate voucher, you probably won’t do very well in the development world. Sometimes, something as simple as a missing period can mean the difference between random failure and perfect success. If you are the type of person who might not figure out where the missing period is, your career will be limited in range, at best.

#8: You do not take personal pride in your work

Sure, it’s possible to program by the book and do a passable job. The problem is, the book keeps getting rewritten. Software development is not a factory job where you tighten the same bolt all day long, where a touch too much or too little torque makes no difference. It requires independent thought, which in turn requires the people doing the work to take pride in it. Furthermore, it’s easy to do something the wrong way and have it work just well enough to end up in production. That “little error” you turn a blind eye to since it doesn’t seem to cause any problems will cause problems. Programmers who do not treat each project as something to be proud of turn out poor quality work, which in turn makes their careers short-lived.

#9: You prefer to shoot first and ask questions later

Software developers, at least the good ones, spend a lot more time planning what they’re going to type than actually typing. Usually, when coders just open up their code editor and start banging away at the keyboard, most of what they write gets ripped out later. Programmers who ponder, think, consider, and plan write better code in less time with fewer problems. There’s a reason so many programmers barely know how to type properly: The hard part of the job is knowing what to type. People who do not invest the time up front in their zeal to get started with the “real work” are actually skimping on the “real work.” If you are a doer and not a thinker, software development is probably not a good career choice for you.

#10: You do not like the geek type of person

For a bunch of reasons (some legitimate), a lot of people just do not enjoy being around the engineer or techie personality. If you have a hard time with the Dilbert or Weird Al personality type, do not even consider going into programming. Are all developers like that? Of course not. But they comprise a large enough portion of the workforce that you would be miserable in the industry.

courtesy @ TechRepublic

Six questions that may help you solve a career dilemma

Career expert Andrea Kay has a six-question technique she recommends for anyone who is experiencing a career problem. She says that by answering these six questions (at your own pace), you’ll be able to “clarify what’s eating at you, how you want things to be different, what you need to do and whether you’re willing to do it.”

The questions are:

* What is your problem?
* Why is that a problem? What troubles you about that?
* How do you want this situation to be? If this problem were solved, what would the situation be like? How would you feel?
* What’s stopping you from making that happen?
* What do you need to do to make that happen? What needs to change? What do you need to ask of others? What do you need to change inside yourself?
* Now that you know what needs to be done, what are you going to do?

I think these questions are useful in that they allow you to step back and look at your problem somewhat objectively. (She also has a sample of answers to the questions here to see how it’s done.)

Give it a shot and let me know if it works for you.