FizzBuzz is the (in)famous interview question designed to filter out totally unqualified candidates for a programming job at a very early stage in the process. The kind who can’t solve even the very simplest programming problems and who would be wasting your time and money if you called them in for an interview after the phone screen.

You can—and should—do something similar for web security. Take a look at this snippet of Python code:

def check_password(username, password):
    db = MySQLdb.connect(passwd=DB_PASSWORD, db=DB_DATABASE)
    c = db.cursor()
    c.execute("SELECT password from tblUsers " +
        "WHERE username = \"" + username + "\"")
    row = c.fetchone()
    if row:
        return row[0] == password
    else:
        return False

Did you spot the problem? If you have any significant experience at all as a web developer, it should stand out to you like a sore thumb. You should be able to spot it in seconds, even if you have never used Python before in your life. Even if you’re the kind of .NET-only developer who insists on being spoon-fed by Microsoft and believes that Python is a dangerous heresy, it should still be glaringly obvious to you.

A couple of years ago, I used a similar question to this one on a number of interview candidates—some of them with twenty or more years of experience at a variety of impressive sounding companies. Yet it shocked me just how many of them required very heavy prompting to see it.

If you’re interviewing a candidate for a software developer role, show them this snippet of code. If they can’t tell you in seconds that it contains a SQL injection vulnerability in line 5, don’t hire them. If they can’t tell you why it’s a SQL injection vulnerability, don’t hire them. No exceptions, no excuses.

SQL injection vulnerabilities are quite frankly inexcusable. Out of all the different kinds of security vulnerabilities that you can get, they are the easiest to understand, the easiest to spot, and the easiest to avoid. Anywhere that you see user input being smashed together with any kind of instructions—SQL, SPARQL, LDAP queries, whatever—it should raise a massive red flag. A candidate who can’t spot security vulnerabilities will write security vulnerabilities (or more likely, copy and paste them from the Internet)—and if they can’t spot the simplest vulnerability of the lot, they’re going to have trouble even understanding more complex ones. And that’s before you even get started on other aspects of programming such as data integrity or performance.

With the rise of ransomware and other increasingly nasty exploits, you simply can not afford to be careless or blasé about IT security these days. As software developers, we all have a responsibility to make sure our knowledge and skills are sharp and up to date in this area, and as a recruiter, you can’t afford to take on anyone who isn’t taking this responsibility seriously.

Finally: there is a second glaring security flaw in this snippet, and candidates should be expected to spot it as well. I shall leave that one as an exercise for the reader.

Posted at 08:00 on 19 January 2017.
Tagged: interviewing, recruiting, security, sql injection

The term “dark matter developer” was coined by Scott Hanselman a couple of years ago, when he wrote this:

My coworker Damian Edwards and I hypothesize that there is another kind of developer than the ones we meet all the time. We call them Dark Matter Developers. They don’t read a lot of blogs, they never write blogs, they don’t go to user groups, they don’t tweet or facebook, and you don’t often see them at large conferences. Where are these dark matter developers online?

The problem with Scott’s post is that he doesn’t give a very clear definition of dark matter developers. Certainly, I get the impression that a lot of people confuse dark matter developers with 501 developers, or low-end developers, or technological conservatives. Take a look at this Hacker News thread for instance—some people seemed to be categorising themselves as dark matter developers even though they were actively contributing to open source projects.

Here’s my suggestion for a more precise definition of a dark matter developer:

A dark matter developer is someone who has not made any evidence publicly available that they are able to do what their CV and LinkedIn profile claim that they can do.

This is pretty much the point that Troy Hunt makes in his blog post, “The ghost who codes: how anonymity is killing your programming career.” To be sure, he does throw in a curve ball where he confuses passion and competence, and I did take him to task on that one at the time, but that aside, the whole point he was making was actually a valid one. What evidence have you made publicly available that you really do have the skills listed on your CV or your LinkedIn profile?

Sadly, for well over 90% of developers out there in the market for a job, the answer is: none whatsoever.

I’ve heard plenty reasons why this might be the case, but I’m yet to hear a good reason for it. For example, some people claim that requiring a GitHub account discriminates against busy people and people with families. That seems like just making excuses to me. You don’t have to spend five hours a day at it, or even five hours a week — and a recruiter expecting something of that order probably would be discriminating unfairly. But if you can’t manage to rustle up five hours in a year to put together one or two small but well-written projects to showcase when you’re looking for a job, do you really have your priorities right?

Cueball: There’s a reason for everything.
Megan: Yeah, but it’s not always a good reason.
—”Time”, xkcd

This certainly wouldn’t be accepted in certain other lines of work. You wouldn’t hire a photographer or an architect who didn’t have a portfolio, for example, nor would you take an academic seriously without the all-important track record of peer-reviewed publications in scholarly journals. With that in mind, it seems a bit odd to me that we shouldn’t have something similar in the very industry that practically invented the online portfolio. Or that having something similar, we fail so spectacularly at actually making use of it.

The gold standard here is, of course, an active GitHub account. Some people have objected to the concept of GitHub as your CV in recent months for various reasons, but none of them have come up with any better suggestions, and the fact remains that even just one or two public GitHub or Bitbucket pull requests or similar shows that your code has been reviewed and endorsed by other developers. But even if you haven’t had any pull requests, any code up there is better than nothing. Even simple snippets will do—GitHub lets you post gists on https://gist.github.com/ just by copying and pasting from your IDE to your browser. In the absence of code itself, informed discussions about programming still carry some weight. A blog, or some answers on Stack Overflow, are both ways of supporting your credentials.

In the end of the day, being a dark matter developer probably won’t stop you getting a job, and similarly an online presence won’t guarantee you one. It simply isn’t feasible at this stage to systematically reject everyone who isn’t on GitHub, as some people advocate — especially in the .net ecosystem which is still frustratingly conservative and traditional. But having some code publicly available for hiring managers to review could certainly make the difference between your CV being noticed and it being lost in a pile along with thirty other CVs that all look exactly the same as each other. Besides, things are changing, and I sometimes wonder — five years or ten years from now, might dark matter developers end up finding themselves unemployable?

Posted at 10:00 on 10 July 2014.
Tagged: github, recruiting