Hacker News new | comments | show | ask | jobs | submit login

I'm an independent recruiter, and I see resumes all the time of people who probably look like "flakes", but here's how you differentiate a flake from a person who hasn't found their niche:

Flakes lack accolades. They leave jobs at the sign of trouble, or they get fired. It really is that cut and dry.

On the other hand, you have individuals (like me, prior to striking out on my own) who consistently find jobs they excel at, and produce results. What any hiring manager, and any recruiter who is worth the salary they are paid should look for are results. Is the candidate simply listing job duties that they are expected to accomplish, or do they go into detail and educate you on the accomplishments and success they've experienced at each job?

There is a difference, and if you're unable to make that distinction, I won't be sending anyone to work for you because that indicates to me you're looking for grunts. Not team members.




I like the idea that tenure and accomplishment are like quantity and quality. But I disagree about how you measure accomplishment. At least for developers I want to see evidence in working code. What have you built? What open source projects have you contributed to? It's not just about making 'a good resume'. In fact the best candidates spend 0 time on the resume.

Mark Suster implicitly is thinking about sifting through a thousand resumes. In that context this is a perfectly valid heuristic. If you end up in a thousand-resume situation you have no major accomplishments. If you have no major accomplishments you had better have at least shown staying power.

Outside of this scenario, though, I imagine this heuristic can be mis-applied.


And you are one-hundred percent correct. Working code works well with resumes, but it's not entirely practical to send a CD-ROM with every resume you send out there, especially when IT departments are already cautious about software they don't directly support as a means of protocol security.

On top of this, you have to consider that hiring managers and recruiters are just the first barrier to defense when it comes to the process of making hiring decisions. Often, they have to place individuals in departments that aren't development, thus, expecting them to look at any code you've produced or software you've written is almost moot. They don't know what the code means, if it's good or bad code and whether or not it's a fair indicator of how your contributions and work ethic can impact the department needing a vacancy filled. At the same time, they have no idea if the software you've provided a download link to is software you wrote over a weekend by copy and pasting tutorial code, without actually learning how to employ critical thinking skills as a developer.

In my work process, when screening clients, a resume entails everything from candidate discovery to candidate placement, it's entirely in the candidates ability to sell to me that they are the candidate for the job vacancy. The physical resume is just the bridge I use to connect that candidate to the hiring manager.

Sifting through resumes is admittedly tiring, but the moment I come across one that has actual accomplishments and enables me with a feeling that this person did more than clock in, crunch away at an IDE, and clocked out, that's when I set that resume to the side and make a mental note that "John Doe deserves a phone call".




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: