The ability to quickly and accurately rate the ability of software engineers after reading a résumé and conducting a relatively brief screening (as compared to full interviews) is very useful for those of us who recruit technologists. This skill is one of the elements that separates great recruiters from the rest, and it is admittedly not an exact science.
As an experienced recruiter, I often work with candidates that I have represented in the past, so I will have the benefit of historical data to assess how strong a candidate’s skills are and how well he/she will perform. This data typically will include feedback from past job interviews, referrals from other engineers, discretionary ‘word on the street’ reference checks, and knowledge of a candidate’s job history.
But how do I make a judgment on a new candidate that has no experience or history with me? I receive a résumé, we have a conversation, and I have to make the call as to whether this person is a top candidate. Without going into a deep technical interview, how do I surmise how strong this engineer’s technical skills are? This is one of the reasons clients hire me, as my screening should save them time to weed out those that are not qualified.
After fourteen years in the business, I have noticed some distinct patterns regarding behaviors, traits, and small details that are shared by many of the top software engineers. Conversely, there are some noticeable trends that are indicative of engineers that are probably not in the top tier. For the sake of clarity, my definition of ‘top’ engineers is based on successful job interviews with clients, on the job performance while working for clients, and substantial anecdotal evidence from an engineer’s peers (the peer piece often being the most substantial factor).
Below I have compiled a ‘points system’ for software engineers, with an assigned value for each characteristic. As you can see, some items are worth positive points, while other traits take points away. Again, this is by no means an exact science, and I imagine we will get some false positives (i.e. it is possible that some average engineers could score high), but I sincerely doubt many great engineers would score low. Although I have used some of these characteristics to help loosely evaluate engineering talent in the past, I have never assigned any specific points values until now.
What does my points score mean? A score in the high 20′s should be where we start seeing engineers that probably take their career pretty seriously and are willing and able to invest some time in bettering themselves. A score in the 30′s would certainly be indicative of a candidate I would expect to perform well more often than not, and above 40 I would expect all candidates to be in the top tier. I know a few engineers who score in the 50 range and higher, and I don’t think you will find any individuals that are not widely admired and respected at this point level.
To be clear, I’m certainly not saying that engineers with blogs are always technically superior, or that having a five page résumé somehow makes you a bad engineer. The assigned points value are not how much that characteristic should be ‘valued’ by an employer, but rather the strength of the indicator. (Note the highest point value is assigned to Linux kernel work, which I have found in my experience to be the strongest indicator of good engineers – not all good engineers hack the kernel, but almost all engineers who do kernel work have been good.) These are simply patterns that I have observed while talking to thousands of engineers, and I’m sure many of you will disagree. Critiques are welcome – even encouraged (just be polite). If you have found indicators of great (or poor) engineers, I’d love to hear them – even if they are odd. Let’s debate!
(As my business is focused on engineers working within a specific set of languages primarily geared towards the open source world, this list is focused on fit for my purposes. Those who work in Microsoft shops or develop embedded software, for example, might not score as well due to the open source leanings here.)
- Linux kernel hacking, just for fun +7
- Committer/contributor to open source project(s) +6
- Technical patent +6
- Speaker at conferences/group events +5
- Blog about tech (even if only occasionally) +4
- Attend user groups/meetups at least once a month +4
- Regular reader of tech books/blogs +4
- Speaker at in-house company trainings +4
- Master’s in Computer Science +3
- Tech hobby with mobile platforms, robotics, Arduino +3
- Run Linux or other Unix flavor at home +3
- Published author/editor of book or web material +3 articles +8 books
- Start-up/entrepreneurial experience +3
- Active projects on GitHub, BitBucket similar +2 each
- In addition to your main ‘paid’ language/platform, some level of fluency in any of the following: Java, C++, Scala, Clojure, Lisp, Ruby, Erlang, Python, Haskell, iPhone/Android platform +5 per language
QUICK ASIDE: Another element I tend to include in the ‘plus’ category is work experience for (+5) or a job offer (+2) from a certain subset of employers. Why? Because I know firsthand that these employers have very high standards in hiring and rarely make bad hires, so odds are if you have worked for or have been offered employment by one of these companies you are very likely good at what you do. I can’t make this list public, but I share this just to let you know another contributing factor.
- Worked over 12 years for current employer (few exceptions) -10
- Worked over 6 years for current employer (few exceptions) -5
- Only run Windows at home -5
- 40+ tech buzzwords or acronyms on your résumé -5
- AOL email address -4
- Résumé is over three pages -4
- Having three or more permanent jobs in a given two year period -4
- GPA/SAT score on résumé and 10+ years experience -2