Monthly Archives: March 2012

What’s Your Geek Number? My Points System To Rate Software Engineers (without a full technical interview)

Posted on by
7

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 all engineers who hack the kernel are 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.)

POSITIVE POINTS

  • 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, Sourceforge, Heroku, 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.

NEGATIVE POINTS

  • 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

 

If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search very helpful.  You can also follow Job Tips For Geeks on Facebook, Twitter, and Google +.

About these ads

The Future: Polyglot Programmers

Posted on by
1

I wrote an article three years ago, “Become a Better Java Programmer – Learn Something Else“, that was subsequently picked up by JavaWorld and DZone and received moderate positive and a bit of negative feedback.  The negative was primarily aimed at my assessment that “perhaps 80%” of the best local Java talent were familiar with at least one of a set of other languages I listed.  Some readers felt the 80% was pulled from thin air (or pulled perhaps from somewhere else), and I concede the number was simply an estimate.  And of course the “best local Java talent” line was also subjective, but time has shown I am a good judge of that.

The gist of the article was that the best Java pros that I knew at the time were either fortunate, curious or ambitious enough to learn other languages and platforms.  Perhaps they wanted to improve their Java skills, to simply climb a mountain because it was there, to have a Plan B in case Java went downhill (article published June ’09, Oracle/Sun deal announced April ’09),  or maybe they knew something I admittedly didn’t know regarding where things were headed.

When I wrote the article, I was offering career advice targeted to Java developers who wanted to continue to be Java developers – learn another language and you should become more effective using Java.  I don’t think I had any real instincts that things were going to change dramatically over the next several years.  I think the dramatic change is now happening, and it’s time to pay attention if you haven’t been.

The concept of polyglot programmers and polyglot programming isn’t new by any means, and I realize that I’m certainly not the first person or the most qualified person (I may be the tallest) to think or write about the subject.  Neal Ford mentioned it over five years ago in a blog post that was quite prophetic.

Think of it this way:  Years ago if you were living in Germany, chances are you only spoke German.  As travel became easier and business spread to different countries, the world got smaller, and it was advantageous or even necessary to learn new languages because the chances of encountering a non-German speaker were greater.  Now many Europeans speak at least a couple languages fluently out of necessity.  If you are a bartender in Rome, chances are you know how to say ‘beer’ and ‘thank you’ a few ways.  The software development world and the options within it have grown vastly, but the need to be productive or conversant in more than one programming language has not historically been a requirement to get ahead.  I feel that has changed, and will continue to change in the years to come.

Since writing my last newsletter I had a couple interesting and vastly different conversations with two technologists that made quite an impression.  One was with a very experienced (>10 years) Java programmer who admittedly had no real programming experience beyond the more common Java tools and API’s (some MVC, JSP) and invested little time trying to keep up with industry trends.  She had many years with the same company and saw very little change in the tech environment.  The second conversation was with a grad student finalizing a Master’s in Comp Sci who had academic, internship, and professional experience (< 2 years) with Python, Java, C++, and Ruby.  He was involved in various tech communities and technology was a hobby in addition to being a chosen profession.

Right now, both of these candidates are quite employable, and as you would expect the experienced Java programmer will earn more at present.  If I had to buy stock based on future earnings and career advancement  in these two candidates today, I’d put all my money and mortgage my house on the grad student.  This Java pro is, at this point, not even aware that the world has passed her by.

Historically, most software shops were hung up with hiring requirements that listed minimum amounts of acceptable experience with a technology.  I can recall having to explain to a client a few years ago that the only person that might have had the amount of Spring experience they were seeking was Rod Johnson (true story).  When I speak to my clients now, it is clear that most are more interested in aptitude over experience with specific languages or tools, as well as an understanding of certain core engineering concepts and principles  (perhaps multi-threading or functional programming) in addition to a set of character traits that tend to result in productive engineers.

The metaphor I often use is to liken engineers to athletes.  A great athlete can throw a football or a baseball skillfully and is able to use both a hockey stick and golf club to make solid contact with a puck or ball, once the athlete makes some simple adjustments to the chosen object.  Likewise, a truly great engineer should be able to succeed using any of several languages, once they understand the syntax and basics.

With the wide variety of robust languages and platforms currently available and ready for prime time, it is hard to imagine that any one or two will become as dominant a force as Java and .Net have been over the past 10+ years.  I believe the days of hearing ‘We are a Java shop’ or ‘We are a Python shop’ are behind us.  The most innovative shops are mixing technologies based on using the language/platform that is the best fit for the task while also factoring in the experience level of the team members.  To remain valuable and relevant, it is becoming necessary to write software in more than one language.  Having the ability to produce in more than one language may be a luxury today, but it is becoming very clear that this will be a necessary skill for tomorrow’s engineer.

If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search very helpful.  You can also follow Job Tips For Geeks on Facebook, Twitter, and Google +.