Something has always struck me as a little bit off, about that “statistic” (or its equally unlikely brothers, 199 out of 200, 19 out of 20 etc.). I remember reading Joel’s post alluding to this back in the day, then Jeff’s a couple of years ago, there were a few others, most recently this one. And as much as I want to just accept it (for reasons of self-aggrandisement), I can’t. I’ve been in this industry for a few years now, in that time, I’ve met some really good developers, a bunch of average ones, even the odd crappy one, but I am yet to meet the veritable army of totally useless non-programming programmers that must surely exist if those numbers are accurate (the “architects” don’t count :P).

Why Should Top Developers Seek You Out?

Whenever I see the latest post about how hard it is to hire good people, because x out of y developers are useless, one question immediately springs to mind. Is that x out of y applicants, or x out of y working developers? There is a massive distinction. Unless you’re a company trying to compile stats by doing an industry-wide study, you can’t really comment on the skill levels of all working programmers in any authoritative fashion. So, we must be talking about x out of y applicants. But once again, it’s not applicants in general it’s applicants to YOUR company. All of a sudden the headline is:

X out of Y Applicants for Positions Advertised By My Company Can’t Program

That’s a whole lot less impressive/sensational and whole lot closer to reality. But, let us dig a little deeper. It’s not just the one company, too many other people/companies have had the same pain. Which is perhaps why these posts receive so much attention. It’s cathartic to have a bit of a whinge along with a bunch of other people who feel your pain :). My question for everyone is this, what makes your company so special? How much time did you spend making sure your ad was sufficiently attractive to the star developers and a sufficient deterrent to the crappy ones? I can tell you right now the fact that you’re the “world’s leading enterprise wodget provider”, the latest “well-funded social startup” or pay “above industry rates”, is not going to bring the coding elite knocking on your door. I guess it comes down to this, if you try to attract talent in a generic fashion you will attract a generic response, meaning that there is a decent chance your 200 applicants were ALL a bunch of discards.

Blame Your Interview Process First

Go back to that article of Joel’s that I mentioned above where he talks about the 199 useless programmers who apply for every job thereby inflating the applicant numbers. I don’t think those 199 wannabe programmers exist, I think the pool is much larger. There is a whole bunch of, let’s call them “aspiring programmers” who are totally crap and either can’t get a job or can’t keep one, which doesn’t stop the from trying. A significant percentage of your applicants are those guys and yeah they can’t program, but then again I wouldn’t really call them “programmers” either. It wouldn’t take long to get discouraged and cynical about the whole industry when dealing with those guys for days on end. But let’s say you can screen all those out via resumes or whatever and only end up with seemingly legitimate applicants, how come so many of those can’t code their way out of a paper bag?

Firstly, you didn’t really screen all the discards out via the resumes, that’s not possible, I’ve seen some highly impressive resumes from some highly unimpressive people. All our stats are already suspect at this point, but let’s plow on anyway. Likely the next course of action is to screen further via phone or face-to-face or both. We ask simple coding questions like the fizzbuzz, but our applicants still fail – even ones that shouldn’t:

“Here is the question that the vast majority of candidates are unable to successfully solve, even in half an hour, even with a lot of nudging in the right direction:

_Write a C function that reverses a singly-linked list.

_

That’s it. We’ve turned away people with incredibly impressive resumes (including kernel developers, compiler designers, and many a Ph.D. candidate)…“

That’s from the RethinkDB post that I also mentioned above (I am not picking on the RethinkDB guys, it is just conveniently the latest post on the subject that I have read :)). Kernel developers, and Ph.Ds can’t reverse a list? That seems entirely unlikely. Perhaps it is not the people who are to blame but the process. We have learned, especially over the last few years that it is often the process that prevents a software team from being productive. These days most teams would cast a critical eye towards their process when looking for causes of dysfunction, before they start pointing fingers at each other. So, why not cast the same critical eye towards the interview process? Perhaps the objectives of the interview are unclear, or you’re not communicating well enough, or you’re using the wrong medium for what you’re trying to achieve (e.g. coding over the phone), or you didn’t prepare thoroughly enough as an interviewer added to the probable unpreparedness of the interviewee (this chronic unpreparedness is endemic in our industry and deserves a post of it’s own). Sounds like the same kind of issues that cause software projects to go off the rails :). My point is, it is not necessarily the fact that the candidate is crappy it could be that you’re just doing it wrong.

Just Because It Makes Us Feel Good Doesn’t Make It True

As I was thinking about all this stuff I found myself referring to the X out of Y “statistics” as “feel-good numbers” because they make us all feel good about ourselves. I mean, it’s pretty sad for the 99 out of 100 poor schlubs, but not you and me – we are coding ninjas. How does it feel to be special :)? Somehow though I don’t reckon there are 99 working programmers sitting there reading those posts thinking “…yeah I am a bit of a failure, I wish I was one of those 1 in a 100 dudes”. As a decent programmer, look around yourself. Can you really honestly say the vast majority of the developers you’re working with have trouble with loops or basic arithmetic? If you can, I fail to see how your company can produce any kind of working software and why are you hanging around that place anyway, it surely is not healthy for your career not to mention your sanity.

If you’ve read anything I’ve written before, you know that I am not one to shy away from a generalisation, but in this case I believe it gives a skewed picture that needlessly makes the whole industry look bad. There is no denying that lack of skill can be a problem in software, but then again this is one of the few professional disciplines where you can read a book and “wham bam thank you ma’am”, you’re a programmer, or at least think that you are (and might even be able to find work if someone is desperate/stupid enough and you’re smooth enough). Try doing the same thing in the medical profession or law, or accounting. This is one of the problems that is unique to IT (other industries have their own), we deal with it to the best of our ability. This issue will always make the hiring process difficult, which makes it doubly as important to think long and hard about how to attract decent people and tweak your interview process to make sure you’re getting what you need out of it. And yes it will be time consuming and difficult and will make you feel like you’re wasting time instead of doing “real work”, but then again you know what the other side of the coin is.

Image by nitot

As I was getting ready for work the other day, some children’s program was on TV. Normally it’s just background noise, but today something made me pay attention. Here is what I heard:

A wise old owl sat in an oak,

The more he heard, the less he spoke,

The less he spoke, the more he heard,

Why aren’t we all like that wise old bird.

I’ve recently been on a kick of extracting software development related lessons from everyday situations and events – that little poem immediately made me think of opinions. Software developers are an opinionated bunch, which is fair enough – comes with the territory. The trick with opinions though, is knowing when to shut up and listen to those of others. I could probably stand to follow that particular advice a lot more often :). If you can master that trick you’re guaranteed to learn something. Even if all you learn is how to keep your opinion to yourself, once in a while, that’s still a skill worth having.

Having said all of that, I do believe that you need to form an opinion about everything that happens, you don’t have to defend your opinion to the death, but you do need to have one. There are important decisions to be made in software projects every day, regarding technology, process, requirements etc. You’re not always going to be the most qualified person to make a decision, but if you let things slide without expressing your point of view – you deserve everything that happens. In that, software is like government. Having an opinion is the first step towards taking your destiny as a developer into your own hands (this applies equally to teams). And that’s all I have to say about that for now.

Image by NuageDeNuit

Many people hate ‘Mount Fuji’ style interview questions. Questions such as:

“How many barbers are there in your home town?“

or

“How would you move Mount Fuji?“

That last one being the most well known of these types of questions and the one from which the rest get their name. These questions were initially popularized by Microsoft, but many of the most well-known tech companies have used them since. They have recently fallen a bit out of favour, but you’re still likely to come across some if you do few tech interviews here and there.

There is a good reason why many people don’t like these types of questions. Most of the time, they don’t really have a good answer. The question is designed to put a person under pressure (when they can’t immediately see a way to tackle the problem) and see how they handle it, as well as see if they can come up with a creative solution on the spot. Some developers tend to enjoy that kind of challenge, others seem to loath it which is why opinions about these questions are highly polarised. While I personally don’t think these questions are the be-all-end-all, I do believe they have their value, but that is not what I want to talk about.

You see the people who hate these questions, hate them with a passion. Whenever an interview contains a ‘Mount Fuji’ or two and people do badly, they know exactly where to cast the blame. “It was all because of the stupid Mount Fuji questions. I was never good at those, plus I wouldn’t want to work for a company that would ask them anyway.” That’s the excuse you give to yourself. Makes you feel better about failing – which is actually not a bad rationalisation as far as rationalisations go. But, there is an issue with this thinking because sometimes, a question that sounds like a ‘Mount Fuji’ question isn’t really one at all and with all the hate we direct towards them we might end up missing it completely. So, what excuse do we give ourselves then, hmmm :)?

What I want to do is present a couple of these ‘Non-Mount Fuji’ questions here. While they might seem like one of ‘those’ at first, they are actually very reasonable questions, relevant, with concrete solutions. In my opinion, very decent interview fodder as well, but you’re likely to fail them just as badly as any ‘Mount Fuji’ problem if you haven’t practiced, so let’s have a look.

Here is the first:

There is a village full of people. One day the priest gathers all the villagers together and declares that their God has told him that some among the villagers are sinners. All sinners will be marked with a sign on their forehead so that all other people will be able to see if a person is a sinner or not, but noone will know if there is a mark on their own forehead. Furthermore, the mark will not be visible in the mirror and one person is forbidden from telling another if they are a sinner. The villagers must work out which among them are sinners at which point all sinners are to leave the village. The village has been given one week and if at the end of the week, there are still sinners present, the whole village will be destroyed.

The villagers go about their own business during the day, however the whole village gathers in the square at the end of every day so that everyone can see if there are still any sinners left among them. After the third such gathering all the sinners pack up their stuff and leave the village.

How many sinners were there? How did you arrive at that number?

This is a deductive reasoning question. We tend to use this kind of reasoning all the time when writing software, so the question is highly relevant to the software development profession. This question has many different forms and is pretty common, so you may have heard it before. If you have you should be able to answer it easily right :)?

Here is the second:

You are one of several recently arrested prisoners. The warden, a deranged computer scientist, makes the following announcement:

You may meet together today and plan a strategy, but after today you will be in isolated cells and have no communication with one another.

I have setup a “switch room” which contains a light switch, which is either on or off. The switch is not connected to anything.

Every now and then, I will select one prisoner at random to enter the “switch room”. This prisoner may throw the switch (from on to off, or vice-versa), or may leave the switch unchanged. Nobody else will ever enter this room.

Each prisoner will visit the “switch room” arbitrarily often. More precisely, for any N, eventually each of you will visit the “switch room” at least N times.

At any time, any of you may declare: “we have all visited the ‘switch room’ at least once”. If the claim is correct, I will set you free. If the claim is incorrect, I will feed all of you to the crocodiles. Choose wisely!

1. Devise a winning strategy when you know that the initial state of the switch is off.
2. Devise a winning strategy when you do not know whether the initial state of the switch is on or off.

This is a distributed coordination problem. The reasoning used to solve this one is relevant when it comes to both distributed computing and concurrency. Infact, I ‘stole’ this question from Chapter 1 of the “The Art of Multiprocessor Programming”, which is a great book I’ve been browsing recently (it really is a very interesting book and I will likely be going through it in a lot more detail, don’t worry though, you’ll read about it right here when that happens :)). In my opinion this is an even better question than the last, it feels more ‘computery’ for whatever reason. More than that, once you’ve worked it out, the solution can pretty easily be expressed in code to validate your reasoning (which is exactly what I did). Infact, with a little bit of creative thinking, even the first question can be validated through some code. If you can express something in code it’s a winner as far as I am concerned.

So What Do We Do With These?

What I want you to do is use this as an opportunity to practice. It doesn’t really even matter if you’re likely to ever get this kind of question in an interview; these are good questions to give the old programming brain a bit of a workout. Not only is this an opportunity to problem-solve, but it can also be an opportunity to write some quick, interesting code. After going through this exercise, if you ever do see these kinds of questions in an interview, you’ll hopefully be able to distinguish them from the ‘hated Mount Fuji’ ones :).

So, get your thinking caps on and try to solve these questions – then post your solutions in the comments below. The first person to get everything right gets a prize, actually I lie, there is no prize, but apparently incentives don’t work anyway, so it doesn’t matter. What you will get is a decent mental workout and the satisfaction of solving an interesting problem. Don’t worry if you can’t get it though, you’ll get better with practice as long as you give it a go. Anyway, I won’t leave you in the lurch, I’ll post my solutions to both of those questions in a few days, including the code I wrote to validate the second one (I might even write some code for the first one if I get time). If you’re really brave, then also post how long it took you to work out the answer (it doesn’t really matter, getting these right at all would be a very decent effort, but if you want to show everyone how much of a genius you really are, this is your chance :)). I am really looking forward to seeing what you come up with.

Images by Molas and “lapolab”