I am a Good Software Developer

May 13th, 2013

An anonymous article doing the rounds explains that the author is a bad software developer:

I am now in the buffer zone and have interviewed with close to ten companies to date. I have not been offered a single job and have not made it past the technical interview in most cases. I am a programmer. Until recently I had believed I was a good programmer. However in an industry where hiring practices have adjusted to filter out the plethora of bad, unqualified candidates I’ve found it rather difficult to consider myself a good programmer any longer.

If we are to take the proportion of job interviews that lead to an offer as an indicator of how good you are as a software developer, then I have to face the fact that I am a good software developer. Not just good in fact, pretty close to as good as it’s possible to be. My current hit rate is very close to 100%.

Of course, this is ridiculous. But I thought it might be instructive to put some thought into exactly why this is wrong.

Firstly, job interview success is localised: what constitutes a reasonable level of success will depend on where in the world you are, what industry you work in and when you are applying. From what I’ve seen, these facts dominate the effect of how good you are at your job.

But let’s suppose you’re comparing yourself to your friend who works in the same industry, at the same place and time. It’s still not useful to compare yourself with them because of the amount of random variance involved. If you’ve been rejected from ten companies then you might have been interviewed for less than 20 hours in total. That’s the equivalent of less than three days’ work. Most people wouldn’t conclude after three bad days at work, even a bad week, that there was something fundamentally wrong.

Thirdly, interviewing well is a skill in itself. Those of us who have conducted interviews like to convince ourselves that we did all we could to differentiate people based on how well they could do the job, ignoring things like interview nerves. We even rationalise the fact that the people who communicate the best have the best chances at interview, on the grounds that communication is an important part of working in a team. This is true of course, but communicating in familiar situations with people you know well is very different from communicating with someone you’ve met ten minutes ago.

As well as communicating and thinking on your feet, interviews disproportionately reward people who are immediately likeable. It’s not fair, and I’m sure people would deny they do it, but when you take a liking to someone you overlook their flaws, and exaggerate their qualities. Again, the superficial likeability that works well here is a completely different thing from the personal qualities that make someone a loyal friend or a supportive colleague.

Finally, there’s a strong tendency in interviews for success to breed further success. When you go into an interview with an offer already in the bag from your last interview, you’re more relaxed and confident. Conversely, the awful feeling that you have something to prove or that you won’t impress the interviewer unless you perform at your very best is self-defeating.

I’m sure the original poster won’t read this, but I’ll try and provide my two cents anyway: looking at the number of successful interviews is a really bad way to measure yourself. Technical interviews at different companies have a lot in common, so going to ten interviews is likely to tell you the same thing ten times. If what it tells you is that you meet their standards, this can be very reassuring, but it’s equally false either way. Instead, try to get qualitative data about what went right and wrong in each case rather than playing the numbers. If the company gives detailed feedback (and I believe they should, though not everybody agrees) then you should take as much information from each interview as you can. If you can’t get feedback from the interviewer, talk through what you remember of the interview with a friend. Try to be as objective as possible. Question your assumptions.

If you’re being rejected at the first round, and if you didn’t make any obvious technical blunders, then consider whether you may be trying to over-complicate things. First round interviews in particular tend to have closed solutions that aren’t very complicated, and the bar to clear isn’t always very high. Don’t stumble through implementing a complex data structure without first asking your interviewer whether a naive approach is acceptable (showing that you recognise the trade-off of program efficiency against development time). Even if you’re stuck, talk through your thinking and show a willingness to learn from any hints you are given. Showing that you can learn from the interviewer (and displaying a positive attitude as you do it) is a remarkably strong trait to show. Most importantly, do not ever give up on a problem until the interviewer asks you to move on.

I wish I had a better conclusion to draw. Interviews suck. Some companies do a better job than others, but nobody is perfect here. But I believe anyone can learn to make themselves a better interviewee, even if in an ideal world it wouldn’t be necessary.

Arista closes its London office

April 23rd, 2013

I have some news that I’ve been keeping quiet about to protect all the parties involved, but I think it’s sufficiently old news now that I can finally talk about it.

Arista Networks, who up until recently were my employer, have decided that they no longer want to have a dev group in London. This is a problem, because London is where I live and I can’t realistically move to any of the other Arista offices. Therefore I and all the other engineers in London have been terminated by way of redundancy.

I understand the harsh realities of operating a business, and I respect that Arista have to make difficult operational decisions. Never the less, I am disappointed in the way this has been handled. In my view, Arista followed the letter rather than the spirit of English redundancy law. More disappointingly to me, I believe they fell short of the high ethical standards they set for themselves, which had been one of the major reasons I was proud to work there.

I won’t be discussing this any further, as I think it’s best for all concerned if we move on from this. I started a new job yesterday, and right now all my former colleagues either have new jobs or have multiple job offers to choose from. I wish them all the best, and I’m very sorry to no longer be working with them.

I will, however, be publishing some articles talking about my personal experiences of being made redundant and searching for a new job. These articles have been written as I went through the process, but I held them back from publishing until I was able to talk candidly without harming anyone. I should emphasise that these are merely my personal experiences, and aren’t intended to criticise anyone or to further a particular cause.

The OSI network stack: An analogy

December 26th, 2012

Since I moved into writing networking software a couple of years ago, I’ve read quite a few books to try and get myself up to speed with it. Most of them seem compelled to start off with a description of the 7-layer OSI network stack, but in my experience the quality of the explanation is rarely very good. I think there are two things that you need to get across: how the OSI layers are defined, but first and more importantly why you would want to build a layered conceptual model in the first place. It’s the latter that I mostly feel needs improvement.

By no means do all books need to cover the motivation for a layered model. Certainly the books that are targeted at software engineers (rather than network engineers) can probably assume that the reader is familiar with the benefits of modularisation. However, if you’re going to attempt an explanation, it may as well be a cogent one.

Here’s my attempt at an analogy: suppose you want to send a package to your friend in another country. You write the address on it and call up UPS. Someone arrives and takes the package off you, and a few days later the package arrives with your friend.

Now suppose you are a UPS delivery driver. You arrive for work in the morning, and your computer tells you where to go and which packages to pick up and drop off. You don’t know where the packages are ultimately going to or from, you just need to shuttle them to or from the local hub. But there isĀ  bunch of stuff you do care about. You care if your van breaks down. You care whether traffic on the road is going to prevent you from getting round all your deliveries in time. You care about cases where the recipient isn’t available and the package will have to be delivered again the next day.

Suppose now you run a regional office of UPS. Every day you get thousands of requests to collect packages. You route the packets to your sorting office, and decide what to do with them. Some of them are targeted at people within your region, so you send them out on the next delivery. The rest of them are targeted at people in different regions. These you simply send in bulk to the regional hub for the appropriate region. Note that the truck you send out only has instructions to go to the next regional hub. They have no idea where the packages in their truck are actually addressed to, and they don’t need to care.

Suppose now you are operational manager for the whole of UPS. You have a bunch of regions, with packages flowing between them. Your daily reports tell you how many packages come out of each region, and how many go in. Maybe a particular region starts to get more and more packages, and you have to arrange for more trucks. Maybe some routes between regions are done by truck and some by aircraft. But what you don’t need to worry about is what goes on within each region. Other people take care of that.

Each of these layers could be replaced without the others needing to care too much. The global manager could introduce hovercrafts on some inter-region routes. The regional manager could outsource his delivery to a different company (or to several companies). The delivery driver could take on tasks from UPS and moonlight for another delivery company. The sender could choose to use FedEx or DHL and get much the same experience.

Another complication is what happens when one delivery company has to interface with another. Suppose UPS doesn’t have any operations in Elbonia, and has to deliver a package there. No problem, they just deal with the local package delivery company and agree on how and where the packages are to be handed over, and what information needs to be on them. Quite how the packages reach their destination (perhaps by pig cart) doesn’t concern them. They don’t even need to know how Elbonian street addresses work, provided they trust the sender to have written it correctly, and provided the package has enough readable information on it that they can route it to Elbonia.

Now, this analogy isn’t perfect (side note: it’s not the job of analogies to be perfect. It’s the job of analogies to convey critical ideas with the minimum of irrelevant detail). And I’m sure I’m not the first person to attempt this analogy. However, I do think this analogy covers the critical points, and that the cognitive friction of it is low.

What this analogy doesn’t do is try hard to map directly to the actual layers of the OSI model, but I don’t think that is necessary. The details of the OSI model are driven by the needs of networking equipment, and analogies only get you so far here. Anyone with some affinity for software and hardware design should grasp the details quickly.

I believe there are two points that need further explanation. The first is what role the OSI model actually plays: it’s not a strict specification, and routing protocols aren’t written to “comply” with it. The mapping of actual technologies into OSI layers is often imperfect (e.g. Ethernet crosses layers). The other point that deserves some more explanation is the difference between layer 3 addresses and layer 2 addresses. There is no direct real-world analogy to this in package delivery, but the distinction is important. The risk of the “UPS” analogy is that it implies that layer 3 is just layer 2 “scaled up” to larger distances, and such an idea would be completely wrong.