Tag Archives: people

Grenoble


It’s a Monday night and no one that lives here goes out for dinner. Most of the restaurants are shut for one thing.

It’s dark and starting to get a little cold so I don’t feel like wandering around for too long. I manage to find somewhere open on a square near a tram stop.

The restaurant is pleasantly busy. There’s a family and a few couples. There are also three men, other than me, dining alone.

One arrives after me and finishes his meal super-humanly quickly. Then he fastidiously counts out a large pile of coins on the table and pays the bill with them. I don’t think he enjoys eating out alone.

Another has a huge fist of rings. I wonder what he could possibly do for a living. I invent a backstory for him, which includes a leadership position in an organised crime syndicate. He’s unhurried, finding plenty of entertaining activities on his phone. As you might expect of a mobster.

Meanwhile, the family wish their daughter would find their phone entertaining. She enthusiastically moves around non-stop. They keep shushing her and finding new programmes for her to watch, largely unsuccessfully.

The couple next to me speak English to the waiter, French to a waitress and German to each other. They eat their burgers with a knife and fork. I suspect they’re Swiss.

Me, I read on my phone and people-watch. I laugh when the waiter notices my English accent and automatically brings me ketchup rather than the mayonnaise he’s brought for everyone else.

What do you know?

How do you interview people for developer and technical jobs? This is an enduring question, and one with many angry factions.

It’s too big a subject to tackle in its entirety and I have no intention of trying. Instead, I want to talk about one aspect: should you ask Computer Science questions or not?

In one corner are the people who argue that you never need to implement a linked list or write Quick Sort in real life, so asking you to do that in an interview is unreasonable and excludes good candidates. They argue that there are more important things to consider, such as the use of applications frameworks or design or working with other people.

In the other are those who say that algorithms are a fundamental part of writing software and, while you may not need to write a Quick Sort, you do need to understand it and to be able to explain it.

The first group calls the second elitist. The second calls the first naive. Who’s right?

Of course, I come at this with my own bias. I have a Computer Science degree but I did it some time ago and don’t have perfect recall on this stuff. Ask me the Big O notation for Quick Sort and I’ll understand the question and maybe make a stab at the answer, but I’m not going to pretend I’m 100% sure.

There are two main angles I want to consider: the intent of the interviewer; and the knowledge a developer actually needs to do the job.

Let’s start with the former.

So, your interviewer asks you to implement a linked list on a whiteboard. Why? What are they hoping to find out about you?

If the answer is… well, the answer, then I’m very firmly with the “you don’t need to know this stuff” crowd. People tend to want a specific answer when either they want a cookie cutter computer science graduate or they wouldn’t understand the answer.

Alternatively they might be trying to see how you think; how you’d start with a simple solution and build up; how you’d test it. In these cases, the answer is less important than how you got there.

Another thing to consider is that, as an interviewer, you want to get the most information in the least amount of time. Starting with a “real” business problem might require too much context to be explained before you could really start. But the candidate hopefully already know what a linked list does, even if they’ve never had to write one.

Of course, sat in a conference room with a stranger it’s very hard to tell which of the two camps your interviewer falls into (and practically impossible if they’re on the phone).

So that’s pretty inconclusive. There are good reasons to ask but you can’t tell whether that’s the case for your interviewer.

So how about job requirements?

This angle is easier. Most jobs don’t require standard algorithms that you’d come across in a computer science or software engineering degree. A knowledge of user interface frameworks probably is more useful for many projects.

But what about the rest? There are jobs where knowing algorithms is important. On projects where low-level or performance intensive code is required understanding the fundamentals can be important. Maybe you’ll be writing a game or something with very low latency requirements or an engine that processes vast amounts of data.

In my last project I deliberately avoided using the system provided Quick Sort and implemented my own Heap Sort. I may not have been able to tell you the Big O notation for heap sort and quick sort, but I do know that quick sorts’ Achilles heel is that it works poorly on already sorted data. (It’s only fair to note that they didn’t ask me about algorithms when I interviewed for that position. In fact, they didn’t ask me much of anything! That’s a long story for another time.)

I’m not saying that you need a Computer Science degree to know those things. I’m not saying that the project would have failed without that background (though the fact that someone knew saved tens of thousands of pounds in hardware costs). And, most importantly, I’m not saying that the kinds of projects that you do are anything like mine. I am saying that the people who say this stuff isn’t useful or important are wrong.

So what do we conclude?

Well, firstly, and most importantly, no one size fits all. Your interview process needs to be tuned for the kinds of position you’re trying to fill.

Secondly, if the only questions are about linked lists and sort algorithms, that’s a big red flag. These aren’t the only interesting subjects for any job. If you’re not at least asked about how you work in teams, you should be worried.

Finally, having said all that, you can’t escape from the fact that programming is about algorithms. According to Wikipedia:

Programming involves activities such as analysis, developing understanding, generating algorithms

You should be expected to understand and to be able to explain algorithms.

But you should also understand team work, several programming languages, relevant frameworks, user interface design, source control, your IDE, the Unix command line, security, Linux, web servers, leadership and management, the film that the line “pop quiz, hotshot” comes from and know the correct answers to “tabs or spaces?” Developing software is hard and has many facets.

Focusing on any one aspect to the exclusion of others is a mistake. And that’s true both for you as an individual and you as an employer.

Eight Best Computer Books

It’s been over five years since I last told you about my favourite computer and programming related books (don’t believe the date on that article. It’s been edited lightly a couple of times since I first posted it).

Having said that, some things have not changed. The vast majority of books on the shelves of your local retailer are very specific. Publishers seem to eschew broad, generally useful texts in preference for yet another beginners guide to Microsoft Word or C++ (or, more likely, Visual C++ 2005 Special Easter Edition SP2). I do not understand this. Sure, there’s a genuine need for “how to” books for specific technologies but is it not more useful to learn how to solve problems in general rather than how to solve a particular problem with a particular product?

Worse, most are not even particularly well written. Deadlines are so strict that authors have to write quickly rather than accurately or well. Ultimately the drive to be the first publisher with the definitive guide on Word 2007 (August Edition) trumps all. One that galls me is that most programming language books assume that you are learning to program from scratch. Is C++ really likely to be your first language? I think not.

The other continuing trend is the size of them. Is it necessary for every book to be a thousand pages long and be stuffed with screen-shots? None of my favourites are like this.

As with the last list, I have not just focused on your typical “computer science” text, if anything I have shied away from them. Hopefully if you go pick up a copy of all these books you’ll find them all to be both useful and entertaining to read.

Additionally, I find most of them to be books that are worth returning to, if not as a reference guide then as something that increased experience make each read make more sense.

So, let’s get to the point. What are my favourite computer books, and why?

  1. Code Complete. If you’re writing or designing software you need this book. As I said last time, it ‘is one of those books that does the job so well it has no obvious competition. It describes the complete coding process right from low level design through to unit testing and, while most people would have been very prescriptive, McConnell outlines the pros and cons of each approach.’ Now on its second edition, it is still, as far as I know, without peer.
  2. The Mythical Man Month. People never seem to learn. Managers still seem to add more staff to already late projects. Brookes said all this, and a lot more, in this book way back in the seventies.
  3. Accidental Empires. Robert X Cringely’s history of the early PC industry is a fascinating and entertainingly written anecdote-fest. He claims neither to be complete nor objective, yet seems to cover all the bases. Since most people these days deal predominantly with x86 architecture machines I think everyone should know the heritage and how we got from Bletchley Park to an iMac. (But without the iMac as it was written years before Apple returned to form.)
  4. Professional Software Development. When I first bought this I was a little annoyed. It’s actually the second edition of McConnell’s ‘After the Goldrush,’ just coming with a different name! I’m not sure that I would have bought it had I known, but I would have missed out. This is the only book of the eight here that talks about the industry as a whole, and how we should move away from the typical, and surprisingly common, “code and fix” development. He talks about certifications; architects; heavyweight methodologies; personality types; and a whole lot more. I can’t say that I agree with every last sentence, but it’s well worth reading just to get a perspective.
  5. Peopleware. It’s amazing to think that it took until the 1980’s before the human elements of writing software were seriously considered. Even now most Computer Science seems to concentrate on the more technical aspects. This book was probably the first to discuss the “human factors” of software development and is still the best that I’ve read.
  6. Programming Perl ((This link is to the third edition. I currently only have the second.)). I include this book at least partially because I wanted to show that it was possible to have a densely technical book that was also well thought out and entertaining. The structure is superb and I can’t think of any other programming tomes that have made me laugh out loud.
  7. In the beginning was the command line… ((You can also download it from Neal Stephenson’s website.)) I think that this is an interesting book for two reasons. Firstly it describes the reason why Unix is as it is better than any other. Secondly, it explains the various major operating systems (and some minor or — now — non-existent ones) in approachable analogies rather than dense jargon.
  8. Conceptual Blockbusting. There are few other professions where your output is almost entirely brainpower. A computer program is really little more than a slightly less ephemeral rendition of pure thought. So if you can’t think your way out of a particular problem you’re in trouble! This book makes you more aware of your own intellectual processes and outlines different ways of approaching problems. Invaluable.

As you may have noticed, many of these books are the same as last time! Does this indicate that I’ve been reading less? A little perhaps, but I’d like to think that it’s because by picking books not related to specific versions of particular technologies I’m increasing my odds of finding the classics.

What do you think? Any other good choices that I missed?

Lena

Lena

Like most people, most of my photography tends to happen when I travel. I do like to branch out from time to time though, this time into portrait photography. This picture is from my first (and currently only) experience in a studio and is of a model called Lena. She was professional, fun and very keen on motor racing.

This is a cropped version of the original. I usually use the full-size, black and white version which is not suitable for work.