Tuesday, April 17, 2012

An experiment with resumes

I usually review developer resumes when we want to hire, so I went into a thought experiment and decided to create what would be my  "ideal"" candidate resume using my own experience.

Sifting for that golden candidate
We do our share of hiring every 4 to 6 months, as our team grows, and it always starts the same way. We cast the widest net (and publish on the high profile sites like Monster, CareerBuilder) and then get a pile of chaff with some wheat (sometimes!). So I was thinking, what is it that I look at a resume, and if I were to look, how would I present it better?

Bear in mind that the techniques described here are used when we  have to go out and cast our nets into the resume-world. Our first choice (a la Joel Polsky) would have been to get a referral, or indoctrinate someone, but if that doesn't work, then we do go out and try to find a good candidate out there. Because of the volume of resumes, we have to forego the individual as an individual and apply sifting techniques (we know we are all special and unique, and getting referrals or resumes from people we know is our real first choice, on which is more about the interview than the resume). Alas, take my technique with a grain of salt :)

So after some thinking, there are two people that need to evaluate your resume (at least where I am coming from). The first is the high-end noise filter. In our case is our super cool HR person has to at least select those that applied with the right skills! She is the one that looks that the super star applicant have at least a minimum of x years of Java experience, understands multi-threading and hopefully works in the Financial industry (the third one is a maybe).

If you made it past that HR/Headhunter filter, then you need to be evaluated by the real "Developers", and those are harder to impress (as we can usually smell if someone is fibbing, mind you, we can get false-positives and true-negatives, but in general if you really don't have experience on a particular area, another developer  could catch it on your resume; there are some telltale signs).

So what am I looking for in a resume? In order of importance

  • Verify that Language and Experience looks OK (this is agreeing with what H.R. saw)
  • Continuity of employment (while not necessarily a bad thing, large discontinuity of work shows at least some exploratory questions if the candidate comes in)
  • Understand what you did within those three/four jobs that you took
  • Figuring out where in the organization you were positioned
  • Trying to understand your skill level 
Verify that Language and Experience looks OK
The first step is easy enough, it is just looking that effectively you have xx years of Java experience, that you are willing to work in Chicago, that your experience is relevant (For example, we are not too interested in J2EE, mostly J2SE as that is what we work on) and that you meet our bare minimum requirement (human, possibly with BS).

Continuity of employment
We have found that sometimes there are significant gaps in employment in certain resumes that we get. Again, while in itself that is not "bad", it does raise questions;  at least it is an opportunity to make conversation. Sometimes we found that candidates don't put experience in because they wouldn't be able to get referrals, or their job turned very ugly (or at least uglier than usual). For us, even that is a good talking point, as we could explore why that job was so horrible, (and we can then make sure how would we fit in that picture). Most people we have found (especially once they hit a certain work-years) become  predictable in their continuity of employment. Again, not a deal-killer, just another question mark.

Understand what you did within those three/four jobs that you took
This is probably the hardest thing to figure out on resumes, and the reason is that job experience is usually not side-by-side. Plus it is the area that most people try to showcase how much they know about the subject-matter, and fit what tools they used, and try to describe what team they were working on. In all this is where the meat of the resume is at, and as such is hard to digest in one gulp.

I first start by trying to discern what you really did (This is where the fibbing shows its ugly head). Words like "Part of a team that developed a highly concurrent one million line of code system" are a big warning sign, ditto for "Lead a team in the ....". 

The reason is that for once, the achievement that is listed is for the "whole team", rather than your individual contribution (The 'leaders' might be OK, even though we ran into leaders that haven't typed a single line of code, and were just managing the project. That was a no-no for the position we were looking at the time). We did have interviewees that essentially created the html page for the large multi-threaded million lines of code and as such his experience as we were interested in were for naught. It is much much better just to list your part specifically first, like "Created the exchange component for the Options Trading Software, as part of a ten person team." That way we know what you did, and that you were working with a team. That is much better!

The next part that gets gummed up in the work section, is understanding what technology did you use to create such a beautiful piece of code :). Java Beans, ThreadPools? MySQL, Sql Server. You see, some people list everything they ever touched in the first part of the resume (I have seen resumes with Windows 95, and MS-DOS 5.2 as part of Skills), but most of it is irrelevant, and really, the only thing useful is what you did in your past job (maybe two). The rest can, and will be, outdated (Try using Turbo Basic now...).

In that sense we want to understand what were the tools and technology that you used in your last job. That is what you have fresh in your mind and what you can probably start using tomorrow. This is the hardest part to get out of the work section of the resume as sometimes is not explicitly set, and/or is gummed up within the description. "Used Profiling and Analysis tools to diagnose and fix Memory crashes". Hm, does that mean that you use JHat? VisualVM? good old-fasioned System.free()? Memory crashes? Out of Memory errors, or JVM Crashes? 

Figuring out where in the organization you were positioned
This is extremely hard. Some of it is the "Being part of a Team" syndrome (almost only in name). Other is huge lines like "Supervised the Task force for Continuous Improvement." If the task-force is made of only one person, then that means that you were supervising yourself (which doesn't sound to super-visory anymore). We have run into many Vice-Presidents of something-or-other just to find out they would have translated to "Senior programmer" in any sensible work-place. This is part of a Dilbertism (is that even a real word, if it isn't i'm christening it! :)) on which companies promote in title but not in pay. And while this practice is only good for that company (we don't do that), is bad and confusing for everyone else. Some people do try to mislead (or genuinely believe they are  Software Development's Senior VP of Bank of America) with the title. For us it just makes sifting that much more difficult. We understand that is part of the "Getting hired" game, but in all seriousness, would you like a company that hires you because you have  Senior VP in your title, or because you achieve a lot?

Knowing where you were within the org chart tell us immensely what you were doing (a Senior VP who is way down in the org chart, would not be creating  vision statements, but actually making sure something got programmed and delivered) and what expectations to exert on you. The more people that were directly reporting to you, the more of a leadership role you (and we) would be expecting for your new job.

Trying to understand your skill level 
The last part is understanding the real accomplishment. Did you use JMS? how? do you know Design Patterns? Have you really troubleshooted a JVM hprof? These are highly technical questions, and sometimes are very hard to discern from the resume. This is the part that "wows" developers. 

Let's say that you made some performance improvements. If you put it on the resume as "Made performance improvements in responding to data events", I would be mildly interested, just because that could really mean anything. I can turn-off logging today and made performance improvements on almost any application. If you tell me instead "Reduced latency within our application from 200ms  to 10 ms by implementing live-spinning locks and reducing hand-over queues" then there is something that makes our imagination go wild. You make me start thinking on the lines of "Hm, maybe he could do something about our market data latency". And that's a win. If you manage to get another developer wondering where you could use that particular skill, it's very likely that you will come to a face-to-face interview and continue talking like humans (and you can really show off your expertise).

So in that sense, once you're past the H.R. required keywords, write for the developer, he is the one that will ultimately say yes-or-no to bringing you in. 

Ok, so what would my resume look like?
Like this!

In all, a resume would have two pages (I don't mind if it's clearer). The first page is for H.R. and the second is mostly for Developers. So let's take a look at the new Resume Revolution

The first page contains at the top the "Best Feature" section. This is just a paragraph of why I'm worth considering (pretty standard fare). Your elevator pitch essentially.

The next part "Work Overview" lists all the relevant experience in a tabular format. At most the past 3 jobs would do (or pick the relevant ones). Notice that the first row is "Year", and immediately addresses my first concern/flag of employment continuity. The last job is highlighted, indicating that's the most important one for me.

Notice how things are broken down so that it's not all in one paragraph format. In the "Duties Performed"
 I write a line or two of mostly what I did, mentioning just a little of the technology I used. The Position before Leaving shows the highest job title I had before leaving (this avoids creating entries for when I was just a Junior Programmer). This just highlights the best things I did when I was employed by company X.

In the next rows I mention what languages, database, version control, IDE, Tools, Secondary tools I used on each of those jobs. This makes it clear what did I use for each job I held. I also highlight the "Years of Experience" using each main programming language by adding (6 Years) next to the language name. The "Skills" section contains a very toned-down version of what I consider helped me the most when doing my job (Concurrency, Swing -> Speed). 

In all, the first page of the resume is done for the purpose of snaring that H.R. person to first think that the resume has enough experience, and to gently introduce a developer to what I have done across my last three jobs.

The second part, is mostly geek-speak. Let's take a look

I have a section called Developer's skills (Java), on which I list what I know within Java, an example to clarify that knowledge, and a situation where I used that knowledge. You see, the issue is that saying "I know multi-threading" can mean either "I know that deadlocks are bad", or it could mean "Why live-spinning is best for Intel's multi-core cpus instead of AMDs", and everything in between. That's why there are two more columns that help "hone-in" the level of skill that you have. Honesty is still the best policy. If you really inflate your knowledge too much on paper, it will show immediately in an interview. If you inflate it somewhat only it will show in your performance (when you're asked to troubleshoot a deadlock, and don't know where to start...). So I help the interviewer to know exactly where I land on my expertise with concrete examples of what I have done. If you really showing off more than one language, you could have more Developer's Skills (Grails) etc in your resume. Just include them if it's necessary for the job that you're applying for.

The last two sections are to help answer the questions on "Where did you study" and "Where are you in the Org Chart." The Company Organizational Chart tells how many employees were on the particular unit I was working on (UIC has 100k employees, or something like that, but in the particular unit I was part of, we were only 50), and where did I fit in that (including how many people I supervised). It becomes clear who is reporting to me, and who do I report to. 

In Conclusion
I would love to see resumes like this (I'm being selfish :) ), because that just help my work of understanding what everyone did in their career path. But hey, I'll share mine, and hopefully, the idea of restructuring the resume so that is easy to read will catch on fire (or not, but hey, I'm hopeful). We have been stuck with a resume structure that is old, and I think a little re-thinking is not a bad idea! As a work in progress I definitively see more value than traditional resumes, and there is probably even more room for improvement! What's your take?

if you read this far and like this post recommend it to your friends (upvote it in HN as well!) Also, check out my podcast!, and subscribe!

Lastly if you want to listen to my geek rock band, check out my videos here!

Thanks for reading!

1 comment:

  1. Knowing when the chronological versus the standard resume format works best is crucial to creating a powerful resume. There are certain situations where one format works better than another in selling you and your abilities.