Why You Didn't Get The Interview, Part II | Hacker News Reader

Why You Didn't Get The Interview, Part II

jobtipsforgeeks.com

33 pointsfecak34 comments

The problem is that employers actually believe you can glean something useful from a resume. In my hiring experience, the quality of a resume is very rarely correlated with the quality of the candidate.

The majority of the time candidates look much better on paper than in person. I gave up the belief long ago that resumes can be filtered meaningfully.

We are not announced publicly yet, but I'm working with a partner on a project called GeekRez (http://geekrez.com) which is trying to solve the problem you mention. There is some info up and you can sign up for notices, and we're planning on a beta soon.

Resumes are not the future of search for devs. Hiring managers want to see other things beyond your self-assessed experience levels and a laundry list of buzzwords. GeekRez aggregates data from a handful of places like GitHub and/or BitBucket, Stack Overflow, Meetup, LinkedIn as well as other relevant links a job seeker would provide (publications, blogs, etc.).

This is all brought into a single page with collapsible tabs as a public profile for a potential employer (or even someone you might be doing a side project with) to review.

Devs can use it as a way to differentiate themselves from the competition and show off the strength of these accounts - obviously there would be no advantage for devs that have weak associated accounts to use the service.

It is also set up so a manager could view several profiles side-by-side, to compare say 5 candidate profiles at once. Instead of looking at 5 PDFs and clicking on a handful of URLs in each PDF to get the full picture, it's all brought together on one screen.

Feel free to check it out now, whether you are a dev or someone who will be hiring them. I'll post about it here on HN when we launch officially.

The skills required to get a job: resume writing, professional networking, interviewing, are often not the same skills that actually qualify you for the job. One could be a very good resume-writer and interviewer (dare I say B.S.er?) but not be the right match for the day-to-day job duties. On the other hand, one may be technically qualified, but just not good at resume-writing or smooth talking during the interview.

It reminds me of back in high school, where there were always those really smart kids who were just bad at standardize testing. They risked falling through the cracks because the testing was the only method used to judge one's scholastic ability.

Perhaps the standard "personal reference -> resume -> phone screen -> interview" pattern could use some disruption. Is there a way to match candidates with jobs that's better than keyword-matching resumes and sitting in a conference room talking about a time in the past when you learned from a mistake? Given that there are simultaneously tons of companies saying they can't find talent and tons of unemployed (and under-employed) talent looking for work, you could conclude that something about the current job matching system most companies use is not working.

I rock at standardized testing; hasn't done me a bit of good in the real World. As for your "way to match candidates with jobs that's better than keyword-matching resumes", the real World already has a system it likes better, who knows whom. Having worked with the person before and knowing their strengths and weaknesses from experience.

The current system isn't entirely broken, but it needs works, and the work needs to come from both sides. Candidates need to do a better job of how they market themselves to employers, and employers need to improve how they select and evaluate talent both on paper and in interviews.

The news a couple weeks ago about Google and their alleged use of trick questions and such hopefully raised awareness of the problems surrounding tech interviews, the value of GPAs and majors, etc., for all the other companies. Google is one of a handful of shops that shape how others think they should do things.

As I mentioned in another comment, managers today are more keen on seeing code. A resume can make whatever unverified claims you want to make. I mentioned a project I'm working on (http://geekrez.com) that is hoping to change how talent represents themselves to hiring entities and somewhat trying to replace the resume submission process with items managers want to see.

A Stack Overflow reputation score is not a self-assessed expertise in a specific technology, but rather something that is assessed by others. Saying you write good code is one thing, but let's see what you have in your GitHub or Bitbucket to prove what you are saying. These are the types of things that will get devs hired in the years to come.

Personal references are a whole other story. If someone can't find 3 people to say something nice about their work, they shouldn't be in the industry. The only thing that is valuable about references is when a handful (3-5 usually) of people provide very consistent information - to be more specific, consistent with both positive and negative items. I know when I hear a few people share the same strengths and weaknesses about a candidate that I'm probably getting a pretty good and honest assessment (or they have all been superbly prepped).

A lot of times I see a resume with a laundry list of skills at the top like languages, app servers, CMS systems etc. First I thing I do is check the experience and make sure the skills are actually mentioned as having been used on a project. Otherwise, I assume you are padding to meet the req.

In the original article last year I included a reference to what we typically call 'buzzword bingo' for people either trying to claim much more experience than they actually have or trying to game an ATS (applicant tracking system). I do the same thing. People seem to be a little smarter about this now. The Java dev world had a major problem with this, mainly because of the amount of Java acronyms.

I'd name the law after the guy who told me this but I don't have explicit permission (he'd probably be OK with it, but I don't see him often and he's a well-known CS person) so let's just call it Smith's Nineteenth Rule: the quality of a candidate is inversely proportionate to the number or technologies listed on the resume.

One startup idea I've had is a scarce resume system where people are limited to 7 technologies and allocate 10 points in each for skill and interest (3-5 points means you're really good or really interested). It's like building a character sheet. More information in that than a typical resume.

Smith's Nineteenth Rule is probably spot on based on most resumes I see. The ones that list every insignificant detail are sometimes good at getting interviews (particularly in companies that use ATS or train recruiters/HR to scan for single words), but not always successful.

Again, as someone who specialized in Java for many years, this was something I'd see on a daily basis. I see it much less now in the camps I deal with regularly (Python, Ruby, FP, mobile) but that probably has something to do with the technologies themselves and naming protocols.

The Java programmers tend to be enterprise types (not to knock that; a few of those are really good) who aren't especially selective in the technologies they work with. Until about 5 years ago, using Python meant you deliberately went out there to find non-standard technologies-- you were passionate about more than just getting a job.

Short technology lists show selectivity. For example, I've dealt with XML but I'm not going to put that on my resume. I don't even know what it means to "know XML".

Java programmers tend to have longer lists for a few other reasons.

For one, the number of available frameworks, IDE's, and other tools is much more significant than other language ecosystems. There really isn't another dev group that has as many tools available between the vendor and open source options.

There is also the tendency to name every single Java API - you can't just say you know Java EE (formerly J2EE), but you have to list EJB, JSP, JMS, etc specifically to get picked up by searchers. There are many Java devs who worked with JSP and servlets that didn't use EJB, but when EJB was in high demand everyone listed it anyway.

'I don't even know what it means to "know XML".'

There's definitely such a thing: Do you understand entities and how they work? (There's more to it than just & and <. Without looking it up, do you know what a Billion Laughs is, and why it's related to entities?) What's in a DTD? Do you understand XML namespaces properly? (e.g., in the tag <x:test xmlns:x="http://blah.com/ns1" att="1"/>, what namespace is "att" in? What, exactly, does the http://blah.com/ns1 mean? How does it relate to blah.com or the content at http://blah.com/ns1?) Do you have an understanding of the various schema languages? Do you understand how encodings interact with XML? Are you familiar with the terminology (e.g., can you precisely answer "What is CDATA?", with some idea of where in the XML grammar it appears and what characters are and are not allowed)? Do you know what a processing instruction is? What is the correct way to embed binary data in XML?

BTW, the answer is generally no. "Everybody" understands a subset of XML with balanced tags and simple attributes, but I'd guess single-digit percentages of the people who have "XML" on their resume really know XML, rather than the simple subset. Fortunately, as an interchange format, since nobody understands XML, nobody uses it to its full capacity, those few who try use it incorrectly, and it turns out there isn't a heck of a lot of reason to actually know the full scope of XML, since in general you're unlikely to encounter correct advanced XML anyhow. You can easily go an entire career without ever seeing the advanced features used correctly. Actually knowing XML can be almost end up being an impediment, you're almost better off having a fuzzy understanding so that when you encounter some developer's weird half-assed dialect, you're less shocked and just get on with it.

(I am aware that some of my example questions there are themselves based on false premises. Consider them trick questions.)

Doesn't that just encourage those who do have a range of technologies at least somewhat under their belt to tweak their skill-weights on each application to bring it closer to a presumed "perfect skill vector" for that job?

(...or is that the whole point...?)

Also listed would be years of experience, in the first iteration. In a later one, I'd want to replace that with some way of evaluating directly a person's general skill level on a scale like this: http://michaelochurch.wordpress.com/2013/04/22/gervais-macle... That would take a long time to figure out, though: how to evaluate programmers in the general case.

3 points of Machine Learning with 20+ years of experience (or 2.0 level skill) is different from 3 points from a fresh college student. The first means he's probably an expert; the second means he specialized in it while in school.

Resumes have two purposes. One is to give a list of topics one is willing to discuss in the interview. The second is to project social status (i.e. lie). So you have a mix of self-evaluations and lies on a resume. The latter don't have signal, but the former do. The reason for the 10-point allocation is that self-evaluation has a great deal of signal if a person is expected to trade off one claim against another ("i.e. I know Java but I'm really good at Python" vs. "yeah, I'm an expert in all languages").

This can never work. Resume's have only one purpose - they are marketting materials for folks looking for work. Everything else has to be considered within that frame reference.

To some extent what Michael is saying is already true, but since resumes don't have a character limit candidates aren't held to it. If you were given a finite amount of space, such as one page, what would you choose to describe? What Michael is proposing is essentially limiting what you can say. If you had an online application that said to list 3 technologies that you use, that would probably be quite different than the list of 30 you may have on your resume, and it would send a strong message about how you truly value certain skills.

There is a tendency for people that are less skilled to pad their resume a bit to try and give the appearance of being more rounded and knowledgeable. This backfires for a couple reasons. The first reason is that it is fairly well-known and accepted now that people who list too much are usually trying to compensate, and are stigmatized. The second reason is that these candidates, if chosen, may be asked about the technology in an interview and will not be able to answer tech questions about the technology.

I would think that those in the know will limit the amount of technologies they list based on the job spec and their experience level. It isn't really useful to list something that you read one article about.

> One startup idea I've had is a scarce resume system where people are limited to 7 technologies and allocate 10 points in each for skill and interest (3-5 points means you're really good or really interested). It's like building a character sheet. More information in that than a typical resume.

I'm not sure if it's a good startup idea, but I definitely plan on doing something like this one my own resume next time I have to job hunt.

If you get to rate yourself from 1-10 isn't the standard approach just to make yourself a 9 in whatever you are most familiar with and weigh everything else relative to that.

So if your main programming experience is a couple of semesters of Java at university you are a "9" at Java and a "7" at PHP because you built a website for the knitting society.

the quality of a candidate is inversely proportionate to the number or technologies listed on the resume.

In some cases, maybe, but there are genuinely people who have worked in lots of technologies, and others who have stuck with the same stack (in other fields, this is also known as the fox vs. hedgehog paradigm). Making both types list the same number of technologies elides an useful distinction.

I also find it somewhat naive to advise “selectivity” and “focus” in resume writing, if said resume is then filtered by machines or humans doing keyword spotting for specific technologies (and implicitly assuming you could not possibly learn them if you haven’t listed them on your resume).

What I’d try to do is an expansive listing, but providing perspective. In my case, I’ve written C++ pretty much every day for the last 25 years; I wrote a substantial amount of Tcl/Tk for 3 years, 15 years ago; I used PostScripts for 2 smallish tasks, both of which left the customer amazed and happy. I feel entirely justified in listing all three languages, as long as appropriate qualifiers were added.

The difference here is people who have worked with a technology and people who are listing technologies that they have 2 weeks with in the same group as the technology they have 5 years in. I'd hope that you would somehow differentiate your expertise in C++ from your rusty Tcl/Tk. If you list them side by side with no differentiation, it almost serves as you misrepresenting yourself (not intentionally perhaps). If you are providing perspective as you say, you are not part of the problem here.

It is a bit naive to advise candidates to be selective when they know that a machine might be ranking their words. If candidates that have 9 page resumes and 2 pages of buzzwords stop getting phone calls and find out why, that will solve the problem eventually.

Doesn't relying on people to accurately rate themselves make their rating sort of susceptible to the Dunning–Kruger effect?

Resumes suffer the same problem, which is why something like the product I'm working on GeekRez at least takes a bit of that effect away. References are also one part, but again it's easy for most people to get someone to say they are good.

On a resume you can say you are the best in the world. You control your self-assessment on a resume, but have no control over what someone thinks of your code or what someone thinks of your answers on Stack Overflow (reflected in your reputation).

I find that having a list of technologies is useful... often people ask ask something like "do you know java?" and this makes that question easier to answer. (Because they often can't be bothered to actually read the experience section word for word.)

Or I might not take pains to find some way to mention every single technology I used in my experience. For instance there are about 17 technologies I use currently, if I were to try to name-drop every single one of them it would end up looking like a laundry list anyway, and not interesting to read. Better to focus on what you accomplished and dump the technology list into its own section, IMO.

If you list more than 10 languages, all on equal footing, and you have no portfolio or explanation for all of them to back it up, I assume you're full of shit and your resume goes in the trash. These people generally have no cover letter or explanation for why they're even applying for the job in the first place either.

Do people usually send you cover letters? No one I know of (in my tiny personal bubble of EECS majors) ever writes a cover letter.

I don't get too many official looking cover letters, but I don't want one. I want a resume and in the body of the email I want a couple sentences that tell me why I should bother to open the resume (I'll open it anyway, but I want you to tell me why I should) and also why you applied - what caught your eye.

I wouldn't waste my time on the formality of a traditional cover letter with all the "To Whom It May Concern" garbage. Just a few sentences, keep it loose.

I don't expect a full formal letter, but something explaining briefly why you actually think you're good for this position or this company is the least one can do.

I posted this because I had just been handed a resume with this pitfall. Asked him about mystery skills X & Y and he told he had done some training, but never used them on a project. Lesson is: don't lie.

Here's what I think is unsaid about the pre-interview stage. Most resumes are junk (recruiter spam, unqualified candidates, perennial candidates who continually punch above their weight class). Your job, pre-interview, is to prove that you're not one of them. Another way to look at it is to establish that your job searching doesn't reflect negatively on you. (Being employed at the time helps.) Everyone job searches, but the bad candidates spend a lot more time doing it.

For example, someone who applies to 5 unrelated positions isn't looking for a career upgrade or new challenges, but just looking for a job in general. That's not attractive.

Once you're in the interview process, you don't have to answer for the mere fact of looking for a job. You've cleared that stigma.

I'd agree. Maybe 75% of the resumes I get are, as you colorfully say, punching above the weight class. I've continued to encourage job seekers (whether or not they are using my recruiting service) to apply to less jobs and spend more time on those fewer applications. I devoted at least a handful of pages in my book on this exact topic, to at least create the image of a passive job seeker even during active searches.

> Everyone job searches, but the bad candidates spend a lot more time doing it.

This sums up what my experience seems to be hiring. I've never really thought of it that way, but there's a clear selection bias. The good ones get snatched up quickly; the bad ones spam out to every damn listing they see.

Good candidates are rarely on the market for an extended period of time, and are often much easier for experienced recruiters and hiring managers to identify than mediocre or below average candidates. When I have a candidate that I know is in the top tier, I'll advise clients that they need to move quickly or lose their chance to even see them, because other companies will be relatively quick and aggressive to hire.

It's not much different than real estate, where if you see a house that has been on the market for a long time you may be less inclined to give it a look. Thankfully, job seekers don't have listing dates unless they choose to post a resume publicly.

I've dealt with Dave a couple of times. I trust his advice.

Reply on news.ycombinator.com