How about "we" quit exaggerating our skillset when "you" quit exaggerating job requirements.
Let's do a random test, shall we? Here is the very first job on Dice.com in New York metro area.
Skills required:
- Systems Development
- Systems Analysis & Design
- Systems Operations & Support
- Knowledge of Cisco LAN/WAN infrastructure
- Knowledge of data center infrastructure
- Knowledge of Windows systems environment
- Knowledge of Network Appliance
- Knowledge of Brocade SAN infrastructure
- Strong understanding of Oracle (both 10g and 11g)
- Strong understanding of DB2
- SQL Server 2005
- Experience in logical and physical design of RDBMS
- Strong understanding of .net technologies
- COBOL/Mainframe programming
- Expertise in desktop software
- 270 Terminal Emulation
- FTP
- IIS7
- Experience in implementing IT Service Level Agreements
- Experience in team management
- Experience in change and asset management
- WMS including Medicaid, SSI, and/or Food Stamps issuance
- Collaborative skills
- Conflict resolution skills
- SDLC Project Management
- Commitment to public service
Salary range? $50,000 to $135,000 tops (again, this is in New York where a small home barely suitable for two adults with one child will run around $800,000 plus $1,500/month in maintenance and real estate taxes).
And hey - you know what I "chuckle out loud" about? When pretentious blog authors talk about themselves in 3rd person:
I have to agree. Max says he has two degrees, but does not state from where, or what his concentration was in graduate school. That's fine, but then says he worked with Microsoft, which could mean anything ranging from being an employee, all the way to working for a company to which Microsoft outsourced some graphics design for marketing materials.
Another way the about page is misleading is that it almost reads like he helped develop Visual Studio.Net, and only after re-reading carefully, is it discernable that he's saying that he was one of the first to use .NET in pre-beta. In the end, it does not say if he actually developed anything with it, if he still uses it, or what the point of telling us the previous information is. Overall, nothing states what he has actually accomplished with all of his "eight years of professional software experience", and that is the biggest problem of all in many resumes.
Personally, I got burned listing far too many skills on my resume without quantifying my experience. After that, I got rid of anything that I didn't have strong experience and I think that helped the credibility of my resume.
That's a very reasonable assumption but you don't know that. A more realistic scenario is that your new, pared down resume lost major points as far as making it through the headhunters' and HR's dumb keyword filtering software, lost minor points as far as impressing generalist managers, and gained minor points as far as impressing technical managers.
I'd say when you tally it all, you get more points than you lose by listing non-core skills. Technical managers are usually the very last in the process and if your resume gets rejected upstream, you don't get to impress or un-impress them at all. Personally, I have never had anyone question my non-core skills. People usually look at several most recent projects to get an idea of your actual strengths.
I customize my resume for each job. If the company is small, I submit a tight, super-honest resume, and omit the buzzword-bingo.
If submitting to Inittech Corporation, I submit a keyword-optimized resume guaranteed to please the screening software (then swear never to do that again...)
In my particular case, I doubt I really lost any points on HR screening because the skills I took off my resume were not skills that were even being asked for in the job postings I was looking at. But, you are right that I don't really know what is the impact of the change. That's probably what I've found most frustrating about job hunting and interviewing, its very hard to tell what is and isn't working.
Eh, I think listing some sort of 'skill level' (for example, my resume lists lisp under programming languages, but notes that I'm a novice.) The best of both worlds, I think, because it gets you noticed by the keyword seekers, and sets reasonable expectations for the technical person who actually interviews you.
I do also list a skill level. The skills I removed were ones where I had very limited knowledge. I wouldn't list lisp on my resume even though I have some basic lisp programming, but I don't think listing novice lisp experience on your resume will hurt you either. I keep my resume down to a page, so I only want the most interesting information about me.
... I wouldn't work for a company that lets HR drones write job descriptions - and honestly most companies I've had contact with from an employment POV actually have technical people recruit technical employees.
Depending on where you are having HR people write the job descriptions is very common - or pro forma job descriptions are common... This shouldn't necessarily put you off. Many large corporates would have this as policy - but doesn't necessarily make them a bad place to work.
Additionally, this article fails to recognise that in a lot of scenarios there are recruitment agents acting as middle-men.. It's happened to me in the past that I'm going for a quite specialised role and an agent has said to me "but you don't have HTML on your CV". Basically they have a list and they're indiscriminately checking it off. Poor - but it's an unavoidable part of the system.
Additionally - having technical people write job descriptions isn't the answer. Technical people could have a tendency to overemphasise specific technical points, whilst ignoring the (more important) fit into the team and other aspects...
So whilst you call them "HR Drones", if you have a good one, they'll produce an excellent job spec - after all - this is what they do.
It's not a great idea to assume that a HR drone will know nothing about the area he's recruiting in. A good HR guy will know all about it. Will know about trends & moods & jobs & projects.
As you say, it is what they do. I know many do it poorly. But I'm sure many do it well.
Agreed. The best job descriptions I've seen are two-parters. One being details on the kind of technical skills they expect for the job (and not just a laundry list of everything but the kitchen sink), and the second part being the soft skills desired.
Seems to work quite well, the way I see it. I would really rather have people from the team that's hiring write the job description - it is beneficial for both parties. They get to specify precisely the position they want to fill (as opposed to casting a generic net), and I get to know a lot more about the job that I'm applying for.
No, I am not an expert in all the things I have put into my skills section. However, I have enough experience with them to know that I can deal with them like an expert in no time (< 1 week).
In fact, I don't think there are "experts" for programming skills. These days, the job mostly requires digesting lots of documentation fast, for new libraries, new languages, new tools, whatever. It is unlikely even for an expert to be confronted with exactly the same problems as in the last job, even with the same underlying technolgies. So focussing too much on the skills section is counterproductive for employers.
Hear hear. I picked up PHP again this past weekend after laying dormant on it for the last year or so. Yeah, I was rusty for the first hour or so, but within a few hours I was as strong as I had ever been and cranking out code like mad.
I have TONS of languages and skills that have been put to the side and unused for some time simply due to the lack of need, but that doesn't mean I can't restore my former competency within hours of jumping feet-first back into that pool. I haven't written C++ for months now, but give me a few hours in front of a terminal with an interesting problem and it'll all come back.
And you know what, if I'm applying for a job with VB.NET, and having not worked with it for a while, you can bet your ass that I would have taken the time to refresh my skills before I step into that interview. The author is complaining about a non-issue.
My advice is to put a keywords section at the bottom of the résumé so that it will getthrough the keywords searches but only brag about your highly competent skills in the body and/or skills summary.
Either that or here's a really novel idea: Attend and present at local networking events. Find your next cofounder or job there.
I put together a simple resume website experimenting with ways to add context to skills on resumes. I list a number of projects, and when you hover over each project then the corresponding skills in a word cloud change color and enlarge. In my mind it does a much better job than a paper resume as clarifying which skills are actually in active use and which are paper skills.
I like it a lot, but maybe you could have a dedicated area for the job descriptions on the right side, just above the keywords? Right now, it is very difficult to scroll through the list of technologies used because the location of each job title moves back and forth while moving the mouse down.
One way around this is to include the technologies used along with each project on the resume. That way, a prospective interviewer can cross-reference your skills list with the particular project and see if it was 10 years ago, or if you only had a cursory role in the project.
You need to include all those skills, because so much headhunting is done by automatic keyword searches. I usually include anything where I would be comfortable writing code of that technology on the whiteboard with minimal reference support. I've dropped some skills over time (eg. Perl, which I last used when I was 19), but I try to keep everything that I wouldn't mind taking a job in. Otherwise, your resume will tend to get dropped on the floor of HR's automated screening machines.
My last/current resume has a skill matrix of sorts. Along the top I have "experienced, intermidiate, begginer" and along the left side I have categories like "Software Development, databases" etc. I think it looks nice and gets the point across.
I disagree with the article where it says: Tools and languages are like foreign languages - if you don’t use it, you lose it.
You don't lose it, you just get rusty. I haven't coded in C, C++ or Smalltalk in years. If I started again, it would take me a few days to get up to speed. But after then I'd be just as productive as I was.
I've been surprised how quickly it comes back. When I was working with a YC company this summer, I had to do some PHP. I was up and running in about an hour and a half - everything was familiar, I knew where to go to find API calls, and I wasn't all that much slower than when I was doing PHP daily. And I hadn't written anything in PHP for about 3 years before then, and had been actively trying to forget the language.
I used to list every single thing I ever used on my list of skills when I first started looking for a job since I didn't really know what I wanted to do so I thought I'd be safe and list everything. Since then however I've gotten a very clear picture of what kind of jobs I want and started to remove things that would likely lead to a flood of calls from recruiters about jobs that I'm not at all interested in.
But I still see the raw list of skills as nothing more than SEO optimization for keyword searches on job sites. I'd expect any competent hiring manager to skip right past that and focus on the specific details that I mention for each of my past positions.
The word "Familiarity" is a joke; what does that mean anyway?
I once interviewed a guy who had HTTP on his resume. Just for kicks I asked him to name 3 HTTP verbs. He could only name GET and POST. I know that's petty, but if a candidate is going to list something on their resume, they better know what the hell they're talking about.
The most atrocious phone interview I conducted, I could hear the guy Googling the answers to some of the questions I asked. Towards the end I asked what his experience was with DOA web-services. He of course responded that he knew all about them and was very "familiar" with them. I quickly ended the interview and said, "thanks, but no thanks."
The long list of skills is a symptom of a much larger problem. Too many companies are just clueless about hiring technical staff.
These things don't work: using HR, resume databases, keyword searches, creating an overlong and too detailed list of requirements and then treating them as a checklist.
Yet, this is the approach taken by far too many companies. The result, of course, is a stack of resumes a mile high that each contain a list of as many buzzwords and skills as possible. How do companies expect to find a good match in all that?
The way out is simple. Create a simple resume, with a small focused set of "skills". Leave out anything that's irrelevant to what you actually want to do. Then send it to a small handful of companies that run reasonable adverts. There may be fewer such opportunities, but I think a focused approach works better in the long run.
good advice (well, I think so) but then, I've been doing this for some time. I use xmlresume and use the skilllevel=tag. (which reminds me, I should probably update my resume.) http://xmlresume.sourceforge.net/
Let's do a random test, shall we? Here is the very first job on Dice.com in New York metro area.
Skills required:
Salary range? $50,000 to $135,000 tops (again, this is in New York where a small home barely suitable for two adults with one child will run around $800,000 plus $1,500/month in maintenance and real estate taxes).And hey - you know what I "chuckle out loud" about? When pretentious blog authors talk about themselves in 3rd person:
http://www.codesqueeze.com/about/