So the last two posts I did about my Google Interview were well received – thank you so much for your kind comments.
Today I’m sharing some of the things I did as part of the preparation: it’s clear to me that even if these made only a slight difference to how prepared I was for the interview (and actually it made a lot of difference) it definitely made me a better coder. My standard of work has raised since. This is probably only useful for people who are going to be taking serious programming interviews, sorry.
In terms of direct code writing, I just started working through Project Euler. I’m familiar with Project Euler from its appearance on the xkcd blog, but this was the first time I’ve sat down and tried to go though the problems.
For those unfamiliar with the project, Project Euler is a set of (currently) nearly 500 maths/computer science problems that require a certain amount of both mathematics and also algorithmic knowledge to solve. They start relatively easy and start getting substantial at around number 50 or so. For context – the first problem has been solved by a little over 377,000 people and the 90th by just over 5,000 people.
Working on the Project Euler problems really did bring back the joy of coding: I wasn’t fighting an interface or googling an obscure error message, or trying to set up the right upgrades and dependencies just to get the program installed. Instead I was reasoning abstractly, on interesting problems and using a language I knew well to deploy algorithms I’d designed. It was really quite wonderful.
Roughly once a week Project Euler releases a new, deeply difficult, problem. Three times I found the time to block out the Sunday day or Saturday night and look into a problem. It was wonderful – I absolutely just lost myself into the code for hours and hours at a time.
I was in the first 100 people in the world to solve this problem: http://projecteuler.net/problem=463 and there are still only about 300 people who have. It was nice to know that I could operate at that level.
I was also reading. A lot.
Some of the reading was things that it was embarrassing that I hadn’t read before.
Design patterns : elements of reusable object-oriented software is one of those books that I’d seen sitting on people’s shelves for years and never bothered with because I didn’t design big systems or even work on big systems. I generally worked on single-author academic systems for years at a time and was happy that I didn’t have to go though that big historical book.
When I actually sat down and read it I realised how wrong I was. It’s not that I imagine I’ll be using any of the 23 classic patterns any time soon, or even that I expect to in any way change my code. It’s that this book pretty much defined the language we use to name things in various APIs and languages and repositories.
Imagine that you had spent years hearing jokes about elephants, without ever having seen one or even knowing that they were jokes. Then you read the Wikipedia page and watch a video and every 30 seconds you think ‘Ahhh…That’s what that guy was going on about’. I find that I’m much happier not only looking though APIs but also reading other people’s code. Github has gone from being completely incomprehensible to being largely confusing. It’s absolutely a book that you don’t realise you needed.
Uncle Bob’s Clean Code: A Handbook of Agile Software Craftsmanship is an easy read on a page-by-page basis. It’s all well reasoned advice (changing my own position on a couple of things). When it’s not changing your mind about things it comes over as the code equivalent of a diet and exercise book – full of things that you know you should be doing. I read this book quite slowly because every hour I had to stop and refactor something significant in my code.
Effective Java and Java Puzzlers.
The only two Java-specific books I’m recommending are both wonderful. Java Puzzlers: Traps, Pitfalls, and Corner Cases is the perfect book for reminding you how little you know about a language. Every section is a small snippet of code and the question ‘what does this do?’. Invariably you answer wrong and spend the next few pages being educated. I can only imagine it’s an excellent book for interviewers or people who just enjoy knowing one extra fact.
Effective Java (2nd Edition): A Programming Language Guide is a bit more straight laced and item based, but it manages the difficult task of being both for people who have been programming for years and still being accessible to academics like me. My major thing with Effective Java is that I think it’s a book you read once and leave on the shelf. Then when you are having a tricky problem you scan down the list of items and say ‘ah, I think that item is the one I want’ and then go and read it up – I think it’s a book of hooks rather than something more manifesto-based like Clean Code.
Algorithm Design Manual
The one that was probably the most *actual* help in the interview, certainly in terms of knowing direct facts, rather than simply writing better code, was the The Algorithm Design Manual. It’s a big thick book that one reads cover-to-cover and reminds you of algorithms you had forgotten and things that you never considered useful but now do. It was a great help for the Project Euler Problems I was working though (I finally got the hang of Dynamic Programming). Again I think it’s a nice book of ‘hooks’ to have on your shelf and say ‘I think I’ve seen this in the Algorithm Handbook’.
I read many many others – these were the ones that I got tangible value out of.