Hacker News Reader

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.

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.

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.

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.

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.

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?

There are places that pay well and don't ask many if any technical questions. If you get to the interviews and are a good cultural fit you are in. Unfortunate but true.

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.

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.

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

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.

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.

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.

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.

Fluffing your CV with skills