from __future__ import Resume
Whenever I read a software engineer’s resume, I try to match it to a certain profile I have in mind. Did they work on something interesting? Server side? Frontend? Is it possible they had to scale? Did they likely need non-trivial algorithms? And so on. A lot of it is guesswork; a very crude pattern matching where by glancing at their project I have to take a guess that this could be someone interesting: a custom website development for ten years does not provide as much of an opportunity to see high traffic levels as a job at Amazon does, but it can certainly come with a good degree of familiarity with client side libraries of all kinds.
How nice would it be if the guesswork in a resume was unnecessary. No bets, no conjectures, no inevitable mistakes. A resume that is structured, rooted in facts, comparable, and is straightforward to fit to an available opportunity. Turns out, a Sourcerer profile, which is based on software engineer’s commits, offers many of a future resume desiderata, and I wanted to show how you can use someone’s Sourcerer profile to inform your mental image of their engineering talent and experience.
Let’s start from https://sourcerer.io/wanghuaili
The first thing I always look at is how much data the profile actually has, so I always look at the number of commits.
Here, it’s 47 commits, which is not a lot. As it turns out though, Wiley is a machine learning engineer, and those guys commit less frequently than, say, web engineers. At any rate, a few hundred commits is the point where I believe that a profile presents someone’s work well. I don’t find other basic statistics such as number of repos or lines of code as useful: repos are organized dramatically differently in different teams, and lines of code tend to be inflated by boilerplate.
Next step is a quick look at what we call the awesome chart.
The first thing to notice here is that the timeline covers a few years of work. We are looking at someone with substantial experience. Since the number of commits added to the profile is kind of low, the data is sparse and it shows in gaps such as Nov 2017. It could mean that not all repos were added, or that it was a research heavy work with infrequent commits, or that Wiley assumed some leadership responsibilities and does not code as much now as he used to.
From the awesome chart, we can also see that Wiley’s languages and technologies have been very consistent. He writes most of his code in python, and relies on various machine learning and computer vision tools such as numpy, opencv, and scikit.
Next up, is the languages section.
Here, we learn that python is not the only language that Wiley uses. For example, he experimented with CUDA, which is what computer vision engineers often do. The reason why only python shows up on the awesome chart is the awesome charts shows top 6 languages or technologies by the number of commits. So, python was the only language that made the awesome chart.
The ‘Technologies’ section follows ‘Languages’. It summarizes technologies such as ‘computer vision’ or ‘web’ by the number of commits that used them, and also lists relevant libraries and frameworks. Note that each technology has its own color that you can look for on the awesome chart.
After technologies, I usually try to get a sense of the team sizes that the engineer was involved with. Many repositories have just one contributor, but I get really excited when I see repos with multiple authors. It is always reassuring to know that the engineer had colleagues in a project, and thus likely had to abide by coding standards, work with other people’s code, be careful to not break things, and so on. Team sizes can be found by scrolling down a bit.
Finally, I take a quick look at commits by day of week. It helps me understand if the code was authored on weekends or weekdays. If most code is committed on weekends, it could mean the commits we are looking at came from hobby projects. Weekday commits suggest it’s the main work.
At this point, I have a pretty good idea of the engineer’s experience and interests, and I am much better equipped to read through the traditional employment history. Better yet, because all languages and technologies each have a unique visual representation, every Sourcerer profile looks unique, but engineers with similar experience have clearly visible similarities in their profiles. The best part is I don’t even need to read all profiles. I can simply ask Sourcerer to find someone similar to Wiley. Or someone who would be a good fit for my code base. Or someone would complement the team well. Or all of the above.
Let’s now look at https://sourcerer.io/arnis71, which paints a portrait of a very different engineer. The number of commits is 661, and as we can see from the awesome chart, the profile covers the year of 2017.
This engineer writes a lot of code. 600+ commits over a year work out into more than 2 commits every business day, which is pretty high, and there are hardly any gaps in the coverage: nearly every week has commits in it.
From the awesome chart, it appears that the two favorite languages of the engineer are Kotlin and Java. They have been working on Java in the early 2017, but then started to actively use Kotlin. However, if we look at the languages chart, we will see that most commits actually had Gradle in them. What is going on?
For those who lives in the JVM world, the answer is obvious: Gradle is a build system popular with both Java and Kotlin, so it’s no surprise that it is being used in almost every Java or Kotlin commit. Gradle is not visible on the awesome chart because it correlates so much with Java and Kotlin, and is completely painted over.
Both Java and Kotlin are pretty much universal languages. Kotlin can use Java libraries, and even though it recently became famous because Google adopted it for Android as an official language, it can be used to write any kind of software. So what kind of software does arnis71 write?
The answer to this is suggested by the Technologies section.
It’s probably Android. There are quite a few Android-specific or useful for Android libraries in the Technologies section, including those that support UI. We are clearly looking at an Android mobile developer.
In near future, we are planning to expand our profiles with more useful bits of information, including those that can help automate observations I just shared, and make the process of interpretation of an engineer’s work even easier. Until then, stay tuned, and don’t forget to make your own Sourcerer profile.