
Fluffing your CV with skills - Rami114
Perhaps I get more cynical as I get older, but I get really annoyed when applicants put &#x27;fluff&#x27; on their CV.<p>I&#x27;ve recently been interviewing for low to mid level IT jobs.&lt;p&gt;To give a few examples of the things I&#x27;ve come across in the last month:<p>* SSH protocol<p>Several applicants have listed this. It always gets my attention because a) I don&#x27;t believe simply being able to connect to a host via SSH is a <i>noteworthy</i> skill, b) if you&#x27;re actually into the protocol itself I will probably love you.<p>It always turns out to be the former. I try to salvage that by asking some more pointy questions such as &#x27;explain to roughly how I would tunnel with putty?&#x27; which get blank stares.<p>* Linux command line<p>This is touch and go in terms of relevance. I guess it depends just how junior you are, as well as the specifics of the role (yes I would tailor my CV to a role). When I ask you what &#x27;cat&#x27; does I would expect an answer. Said person could not tell me what the default shell was under CentOS.<p>Again, a lot of people fall short under questioning. Being able to change directories does not qualify for a CV mention.<p>* PHP (Zend OO)<p>Very specific example but this applies to any scripting&#x2F;programming language mentioned on the CV. If you claim something specific, be prepared to answer specific questions. If you put &#x27;Zend OO&#x27; and it turns out you read the cover of a book about Zend (literally admitted) and &#x27;did a course in OO PHP&#x27; whilst your real work is fully procedural, please be prepared for a frown.<p>Now, am I being too cynical with these juniors? Perhaps working in a city like London makes it hard to see the forest for the trees, but I am sorely disappointed with perfectly capable people ruining their own chances by senselessly fluffing their CVs.
======
seanccox
I think your cynicism is merited. It never ceases to amaze me how many
competent people there are in the world who are incapable of articulating
their own competence. However, on some level, I'm rather glad for that,
because most people don't want to hear how awesome you are. In fact, most
hiring personnel don't want to hear how awesome you are, so it's better to let
your work speak for itself.

I edit CVs on the side (because I'm an editor), and I find people 'fluff'
their applications for a wide variety of professions.

The advice I generally offer is this, and maybe you can confirm/deny whether
it applies to your hiring approach?

1) Wage war on adjectives, they offer the reader nothing and merely take up
space. 2) Talk about projects, not positions or skills – in the course of
discussing the project, discuss honestly what skills you brought to it and
what your role was; articulate what you learned on the way; and tell me the
conclusion of the project. It can be bullet points, but let it tell a story
that's easy to understand. 3) Discuss outcomes. If your project was scaled,
resulted in a sale, became a template for similar initiatives, or made your
colleagues' lives easier, discuss that outcome.

It would be nice to learn whether I'm steering people in the right direction,
if you don't mind sharing... In any event, when I have to advise on a new
hire, I usually appeal to those three criteria when reading a resume, and I
toss anything that doesn't meet it.

------
dack
I remember when I was just out of college, I was terrified at how little I
could put on my resume. I had a couple internships, sure, but it just felt
really sparse. It made me really wrack my brain to come up with as many
"skills" as possible. I literally felt like I was trying to trick companies
into giving me a chance, since I didn't have much "proof" of my potential. Now
that I have plenty of experience, I have a lot more to work with, and it's way
easier (especially since I have been on the other side of the resume-reading
exercise, so I know what I'd look for).

Hopefully more students can learn what it's like from the company's side and
have a better picture for what they're expecting. If they are going for a low-
level position, I'd give them a break on the resume and experience, and really
dig for potential. Everyone has to start somewhere.

~~~
Rami114
Agreed on giving them a break in the end. I do tell them straight on that
fluffing skills isn't a good idea as it sends the wrong message. We do have a
technical component and group discussion stage to try and coax out the talent.

It's amazing how some people completely fumble the interview and sometimes
even technical component, yet convince people in the group chats.

------
xauronx
I would also note that if you're/they're using a recruiter, the recruiter
often does this stuff. A recruiter contacted me for a local start up I was
interested in, so I sent my resume along and they "made some small
adjustments" and sent it back. They added things like "MS Access", "Agile
Development", etc. Some other things just randomly pulled out of a hat.

As a side note; I can tell from your tone that you are indeed a cynical old
man. The interview processes you describe are intentionally trying to make the
person look stupid, and not ascertain what they know.

"Said person could not tell me what the default shell was under CentOS.", how
is that relevant to being able to use a linux command line? I understand that
many devs probably think being able to cd/ls counts for linux command line
ability, which obviously isn't enough.

~~~
Rami114
That followed up from asking if they knew what Bash was. Is it wrong to expect
them to know it's the shell and it's generally the default? I suppose my post
must make me come across rather horrid, but I'm generally quite nice in
interviews! :) It's not about looking stupid, I gladly take 'I don't know' or
'good question, I want to look that up' as an answer. It's embarrassing for
everyone to ask what are generally easy questions on the topic that was on the
CV and get a total blank stare.

------
creature
I think you're being overly generous here by calling it 'fluff'. I'd call it
'lies'.

I'm like you. A couple of months ago I screened a candidate who listed
'Object-oriented Javascript' in second place on his list of skills. I asked
him a really tough, brutal question to test this limits of his knowledge on
this:

"How do you do object orientation in JavaScript?"

Blank look. Silence. Okay, let's help him out: "Well, JavaScript doesn't give
you a 'class' keyword or an 'inherits' keyword. So how would we write OO
code?"

"... To be honest, I've only ever done it in jQuery." he said.

"Oh right, okay. I've never done it in jQuery. How does it work in jQuery?" I
asked. Silence again. No hire.

I have no idea why people expect this stuff to pay off. It wasn't a front-end
job; OO JS wasn't a job requirement and wasn't listed on the job ad. Why put
it so high up on your CV if you don't know anything about it? Why put it on
there at all?

~~~
mcv
Yeah, outright lies like that are definitely bad. But various recruiters have
asked me to add some skills to my CV that I personally considered not
interesting enough to mention.

Like Scrum. I've worked in Scrum, and I love it. But I didn't really consider
it a skill until recruiters pointed out that clients wanted clear Scrum
experience.

I've listed SOAP. Is it a skill? It's fairly trivial to work with. (Though I'm
amazed some people manage to mess it up. Tools do everything for you. How do
you mess that up? But somehow they do.) But I've got experience with it, so I
list it, though I'm hardly a SOAP guru.

I don't list Linux, because I'm no system admin. I do know my way around the
command line, but everybody programmer can do that, right? Right?

So I've got some skills listed that I consider fluff, but they're not lies. I
consider them fluff because they don't really add much, and are certainly not
on the same level as a language or framework, but I list them anyway because
hiring managers care about them.

------
makerops
One of my best friends does hiring at a very large corporation; one of the
tricks that he has taught me, is that a lot of companies will run a CV through
automated software, culling any CVs that do not match the keywords the job
description is looking for, so I do not see it as a major deal adding the
"fluff" to get through these (flawed) systems. In fact, if you were an
applicant, and A/B tested your resumes, I'd probably hire you straight away.

~~~
Rami114
So the moral is: tailor your CV to the type of corporation you're applying to?

------
hashtree
Not only the fluff, but the folks that put dozens of languages and
technologies that are unrelated to one another. Being a polyglot myself, I
still end up focusing on one or two languages to the point that I'd be
comfortable putting them on a resume (t spec). IMO, if you are not able to
field extremely deep questions on a language/tech you shouldn't list it.

------
Peroni
Fluff is caused by job seekers perception of what are the 'must haves' for a
CV.

Try reviewing CV's for Customer Service roles and you will be amazed at the
fluff folk put under hobbies & interests.

People assume that they need to list their skills in a nice, ordered, bulleted
list and panic when they perceive said list to be too short or insufficient.

------
1337biz
Headline made me come here to learn how to best fluff a CV. Left utterly
disappointed ;)

Let me try to answer the question: The issue is probably, that with most
softer CV skills are way harder to determine for the true level of mastery of
an applicant. Most larger organizations might anyway be only interested in one
particular element of your CV and take the rest as decision making support
supplements. Unless the applicants where specifically applying for SSH, Linux
or PHP/Zend jobs it might be just "stuffing" to signal that they have some
idea of the subject and are willing to further develop their skills in that
direction.

------
lsiebert
I am recently out of College, and I don't have a job, so let me see if I can
give you an example of the curve, and clarify why your expectations seem to be
wrong.

I don't know where I would have used CentOS (I'd guess bash is the default
interactive shell, but I don't know for sure).

Most people in Linux classes would use Putty on Windows to log into the school
machine. I installed Linux Mint, other's used bash on Mac OS X, and I know of
one guy who ran Arch. That puts us slightly ahead of the curve.

So I know local bash commands. I know enough make to compile my c code with a
Makefile that I copy and modify. As

I have to look up ssh and rsync options. When would I, as a student, really be
doing stuff across linux machines? I have picked up a bit of bash scripting
(helped by the fact that I learned perl, and perl is closer to bash then you
would think), but that's less than usual. Most people who know Python script
in python and so on, and may ignore linux commands and pipelining in favor of
their preferred language's built in's.

The Zend thing is a little weird, but most people going into entry level jobs
expect to learn the specific framework on the job. Hell sometimes the specific
language. I don't know if I would list Zend on my resume if I had only that
guy's experience, but a course in OO PHP is pretty specific for a college
course. Unless Zend is driving PHP usage like Rails did for Ruby, The guy
expected to be able to demonstrate the capacity to learn it and understanding
of the underpinnings (PHP and OO), not actually how to do it. Apparently that
guy got an interview, and more modest people probably didn't.

I certainly list Perl and will say I can do OO Perl code, but I have never
used Moose, just old fashioned blessed hashes.

At entry level, you should hire the person, not the skills. Have they written
code for something outside of a school project? Have they written code for
their personal use? Are they still learning? Can they articulate their
understandings of relevant concepts clearly? Can they program something in
their preferred language and one or two more to show the ability to
generalize?

A good entry level candidate can do most (but not necessarily all) of the
above.

Entry is about talents, not skills, and that's what you should be looking for.

Maybe my expectations aren't par for the course where you are, but remember
that the best candidates, the guys who have been programming since they were 8
and write their own lisp compilers, they have jobs lined up before they
graduate.

You can always contact professors at local schools who teach classes relevant
to your job openings, and ask them what gets a good grade, and what is an
average grade.

Calibrate your expectations. Expect people who aren't qualified will try to
get the interview anyway. Expect that people won't know as much as you, or
even as much as you did when you were just graduated.

