After four and a half years of dedicated service, I have now retired my old MacBook Pro and bought a new one, of roughly the same kind. (The battery on the old one has warped with time and is now so bent out of shape that it puts pressure on the trackpad from underneath, so after about an hour of use the trackpad stops working properly.)

In addition to a working trackpad, unaffected by a misbehaving battery, the new one has one really cool thing: a Retina display.

The Retina display seemed like an unnecessary luxury. I was pretty happy with the old screen. But the model with Retina display had other things that I wanted (more memory compared to the non-retina one, and Flash storage instead of a hard drive) so I bought it anyway.

And now I am in love with the new display. Everything looks so crisp. It’s a pleasure to look at, and especially to read – or write.

PS: If anyone is interested in buying a cheap 5-year-old 15″ MacBook Pro with a badly warped battery, then let me know. The battery can be replaced, I’m sure.

Recruitment-related tasks have been filling most of my days at work since January. Now I am finally seeing a glimpse of light at the end of the tunnel. We are close to signing a contract with a good back end developer, and today for the first time we had a really promising candidate for the front end role.

By now I have a pretty solid and stable process worked out. First I read their CV and/or cover letter, and ask for clarification where I their background really seems to not fit our needs. Well over half of the candidates get discarded at this stage – surprisingly many candidates seem to apply for any job that seems even remotely related to their skills, and don’t hesitate to apply for jobs that they are clearly under-qualified for.

Next I ask them to do a coding task at home, at their own pace. After this we have a brief phone interview. I used to do it the other way round, because I didn’t want to do give them unnecessary work – the task takes a couple of hours to do at least, whereas a phone interview is no more than 30–40 minutes. But it turned out that a lot of people who sounded knowledgeable on the phone failed the coding task, so it ended up wasting a lot of my time instead. And since I get to decide, I’d rather have them waste their time, not mine. The coding task not only filters out the candidates who can talk but not do – it also gives us something concrete to discuss during the phone interview, and therefore makes the interview much more effective.

Now the funnel works quite well. Occasionally I say yes to someone who I am unsure about, and thus far these candidates have always disappointed in the next round. So if the candidate doesn’t seem to have enough relevant experience, they don’t do well on the coding task. And the ones whose coding task does not impress don’t make a better impression on the phone.

All the coding tasks until now have been sort of mediocre, “good enough” at best. We’ve been trying to weigh them against each other but never really come to any firm conclusions. Is one kind of mediocrity better than another? What’s worse, stupid variable naming or badly organized code? How bad is too bad?

The one we got today stood head and shoulders above all the previous ones, and the interesting thing was that this time there was no discussion, no hemming and hawing. The moment we saw the code it was obvious to all those involved that this one was in a completely different league from the others. Distinguishing a really good solution from a mediocre one is so much easier than comparing two mediocre ones. Even if we for some reason end up not hiring this guy, he has at least given us a yardstick for evaluating future candidates.

Another observation we made today was that the good front end developers we’ve met (including those in our team) are all ex back end developers. In other words, they are developers who have chosen to specialize in front end work. The ones who come from the other direction – the designers, the web developers – lack the necessary fundamental development skills. Their solution may work but just it’s like a house of straw: you can see at a glance that it is structurally weak. They don’t build, they hack.

PS: I just counted: I have received 43 applications for this job, reviewed 13 coding tasks, had 10 phone interviews and 2 face-to-face interviews (with 2 more already booked).

I took a look at the stats for this blog for 2012, and in particular at the search keywords that bring people here. It made for some interesting reading, and fair amount of googling on my part to double-check the results. Can people really have found their way here by googling for “brown slimy mushrooms”? Yes, indeed, my photo is the #6 result.

Some searches are seasonal. In November I got a number of visits from people interested in chestnut animals (my photo of Ingrid and Eric making chestnut critters is on page 1 in Google image search) and both November and December brought people looking for pictures of felt advent calendars.

My photos rank highly for several product searches, where I would have expected more commercial sites to dominate. But their images probably get names consisting of long random strings of numbers and letters, rather than descriptive, search engine friendly ones like mine. I am, apparently, an authoritative source for images of “ikea shopping trolley”, “bugaboo the chameleon” and “stokke xplory” and “aerial straps varekai”.

The people who come here after searching for “space between cherry tree saplings” will be sorely disappointed when they find out that I do not plant cherry tree seedlings, but pull them out by the hundreds.

Several of my photos rank highly in image searches for unexciting search terms such as “standing on toes building a tower”, “jumping on stones” and “sharpening pencil for children”. Most interestingly, I have made Adrian the poster child for “unsafe kitchen with a child in”, “unsafe kitchen pictures”, “unsafe pictures children”, “unsafe kitchen” and a number of other variations on that theme.

I imagine some teacher somewhere searching for a decent summer-y photo of kids doing a wholesome summer-y activity such as jumping on stones. Or maybe a social worker preparing teaching material (for new parents, perhaps) about how to baby-proof your kitchen, and then using my photo of Adrian as a scary example of how not to do it. I wonder how many newsletters or crappy PowerPoint presentations there are out there, featuring Ingrid jumping on stones or Adrian playing with wooden kitchen utensils.

I spent Monday and Tuesday at Agila Sverige (Agile Sweden). A great conference, again. Now I’m full of enthusiasm and a desire to change things. The challenge is to somehow hold on to that energy and not let it leak out. I try to visualize myself being a drip feeder rather than a sieve.

At work I continue to spend a lot of my time on trying to recruit a front-end developer. And I continue to be surprised by how low-quality many of the applications are. It is very easy to be above average in this process because the average is so atrocious. It makes me realize that in any reasonable job market, short of a total collapse in IT spending, I am always going to find a good job, just because I don’t produce crap.

One key part of our recruitment process is a coding task. I normally send it out before booking an interview, because it weeds out the candidates whose technical skills are clearly not sufficient for the job. It takes me less time to judge someone’s code than to do a full interview.

You’d think that in a situation like this, people would send me the absolute best that they can do (within reason). And instead I get crap. Lack of technical skill or experience is one thing, and just means that this is not the right job for them. But lack of care really has no excuse.

Sloppy JavaScript code with missing semicolons. Code that is indented at random and has random blocks of blank lines interspersed here and there. If/else blocks that, upon close reading, turn out to contain identical code, except for whitespace.

Also, not a single candidate has reflected upon the fact that I have many submissions to look through. I would immediately be incline to judge more positively a candidate who named the file with their submission in a way that would help me tell it apart from all the others. Instead they all name them task.zip, reqtest.rar, servicejson.zip, JsonTask.rar, WS.rar, WebServiceApplication.zip, etc.

Rant over.

PS: On the plus side, a few of the candidates have actually hosted their solution on their own server and just sent me a URL, which is a very nice way to avoid the file naming problem completely.

(See also: Interviewing for a developer job at ReQtest.)

Yesterday a reader commented on my old post about Excel VBA interview questions. As I am, again, spending a lot of my time trying to recruit another developer, I thought I’d tell you about what my current interview plan looks like.

What we’re looking for is a reasonably senior web developer. We’re a small software company with just a handful of developers, so we need someone who can pull their own weight, with no hand-holding or detailed management. Everyone is expected to not just code but also contribute meaningfully to discussions about design and architecture. They also need to share our values and mindset – to value code quality, maintainable code, good design.

The interview is complemented by a coding task, where I email the candidate a 1-page specification for an application and evaluate the code they send back. I therefore spend very little of the interview talking about detailed technical matters. The interview is for me to judge their aptitude and attitude at a higher level.

This is not an interview script. I wouldn’t ask these questions top to bottom. It’s more of a checklist for areas that I try to cover during an interview. This is also not a prioritized list.

For the rest of this post, “you” refers to the candidate.

1. Fit

What kind of a job are you looking for? What kind of company would you like to work for? What is important to you in your work? Why are you looking for a new job?

What I’m trying to establish here is whether the candidate would fit our firm. If they are looking for a fast-paced competitive environment, or a firm with international opportunities, they’re not for us.

What would you like to be doing in 5 years’ time? What do you enjoy most about programming? Have you been involved in requirements or testing in your previous projects?

This is to detect the wannabe project managers and business analysts, and people who are aiming for a managerial role. Nothing wrong with those, but we won’t be able to offer them a meaningful career path in our company. This is also to detect the pure programmers who have no interest in anything outside of code, who will consider testing and requirements work and usability studies to be “not their job”.

2. Passion, learning, interest

How do you keep up with current topics within the industry? Do you read any books? Blogs? Do you do any programming in your spare time? What’s your favourite tool?

Here I try to figure out whether programming is “just a job” for them, or whether they are truly interested in and passionate about writing software. It isn’t necessary for the candidate to do all of this, to read books and blogs and have hobby projects – but if they do none, it’s a great big warning sign.

3. Technical insight, critical thinking, big picture thinking

Explain the purpose of a recent project you worked on. Explain the design and the architecture. What choices and alternatives were considered? Why did you make the choices you made? What would you do differently if you had to do it again?

This separates the “drones”, the passive followers from the active minds. Even if the candidate wasn’t in charge of the project they describe, they should be aware of design choices and trade-offs.

Did you use an Agile process? What were the advantages and disadvantages? Did you use test-driven development, or unit tests or automated tests of any kind? How did that work?

If in this day and age the candidate has nothing to say about unit testing, they are not for us.

4. Some technical questions

This is a bit of a smorgasbord; I pick the areas that are relevant for the candidate’s area of strength. SQL and OOP for back-end developers and JavaScript and CSS for front-end candidates.

The home coding task tests general programming skills. Here I focus more on the specific technologies we work with. This whole area also ties in with #3, i.e. their ability to make trade-offs and informed choices.

OOP: Explain to me a design pattern that you have found useful. Why? Explain to me the purpose of the Single Responsibility Principle.

ASP.NET: Explain to me some different ways to save state between page requests. What are the pros and cons of each one? Which ones did you use in your last project? Why?

SQL: I give them an example table and ask them to write or dictate to me some simple queries against that table.

JavaScript: Explain callbacks, and why they are useful. Explain closures, and why they are useful.

CSS: Tell me about what you would use to build a page. Divs or tables? Why? How can you position a div – how can you center it, put it in a specific position on the page, etc.

5. Leadership and self-leadership

What was your role in the project? What were you responsible for? What are your weaknesses?

We need people with drive and initiative, who are able and willing to take on significant responsibility. The weaknesses question is mostly a basic indicator of self-insight.

Do you know any good developers in the Stockholm area? Send them to me!

ReQtest, the company I work for, is looking to add two more developers to our team, one for front-end work and one for the back-end. The foundation for our application is ASP.NET and C#. On top of that the front-end guy needs great JavaScript and CSS skills; the back-end developer needs experience of database development.

We’re a small and growing company so we offer lots of responsibility and variety in the daily work, and a say in just about all matters regarding both the product and the company. We use an Agile development methodology, and we value code quality and usability highly. It’s a great place to work.

Read more on monster.se: front-end developer, back-end developer.

Ingrid spends quite a lot of time with the iPad. The apps she uses most (apart from a movie player app) all come from one studio: Toca Boca. They make a variety of apps, some better than others. Originally the best ones followed a common structure but now they are branching out into more different kinds of play. We have every single one except the Helicopter Taxi which needs the iPhone camera to run.

I was going to list Ingrid’s favourites but then I realized that she loves almost all of them. Some days she plays one, then another day another app gets more time, and after a few days she comes back to the first one again.

There’s Birthday Party and Tea Party, where you start by setting a table, choosing plates and cakes, and then proceed to eat the cakes and drink the tea and lemonade. These have great multi-touch support and work very well for several players. I believe that kids are supposed to invite their stuffed animals to the tea party but Ingrid usually plays with me instead.

Then there’s Toca Store, which is sort of similar but more clearly meant to be played together. One person takes the role of shopkeeper, the other is the customer. The shopkeeper chooses which items to sell, sets their prices, rings up the items on the till. The customer picks items to buy, counts up the coins, puts the stuff in their bag.

Of course you could play those things without an app, with actual physical items – and we have. But the app is 5 seconds away whereas setting up a tea party with real toy plates and cups takes time, so Ingrid is infinitely more likely to use the app than the real thing.

A bit similar is Toca Robot, where you build a robot by picking body parts for it. The graphics are well made and fun to look at: the robots can have arms with propeller attachments and a body like a fridge. When the robot is done you can fly it through a simple maze to pick up gold stars. Updates to the app have brought new varieties of each body part, as well as new mazes, so Ingrid keeps returning to this app.

Toca Hair Salon and Toca Kitchen are two of a kind – you get some materials and can perform some actions on them. Cut, blow dry, comb, wash, colour hair; chop, fry, boil, mince food. I’ve found these somewhat disappointing – they sound like more fun than they actually are. In Toca Kitchen the choices are too limited, and they’ve skimped on the graphics: the results look dull. Frying things just makes them brownish, for example, so frying an egg doesn’t actually result in anything that resembles a fried egg. In Hair Salon the hair is difficult to control and the results are all too similar to each other, except for the colour and accessories, so what sounds creative boils down to a painting app.

Paint My Wings is actually a painting app where you paint the wings of a butterfly. The wings are mirrored, so whatever you paint on one wing also turns up on the other. There are other nice touches such as the butterflies talking to you (“that tickles!”) and using berry juice for the painting, making this a bit more interesting than just a plain drawing app.

Less open-ended is Toca Doctor which consists of a bunch of puzzles and mini-games. Ingrid liked these to begin with but they’re too simple for her now.

The building works here may be done but that doesn’t mean we’ve run out of work. We have painting to do, lighting fixtures to buy (there’s currently no lighting in the entry hall, or the stair hall, or the walk-in closet), books and bookshelves to move from the bedroom to the office/library…

This evening, after both kids were asleep and our productive time began, we got started on laying stone on the flat bit of ground between the garden stairs and the stairs to the porch. It was already paved before, but when the new porch got built, the upper flight of stairs became wider and moved slightly, so we ended up with an unpaved gap.

We chose paver blocks that come in a mixture of sizes, Fantasi Antik. We spent an hour and a half this evening designing a layout for the stones that we can live with.

Both Eric and I are “pattern people”: if there is a visual pattern, accidental or intentional, we cannot help noticing it. And if that pattern is in a place where there isn’t supposed to be one, it will keep catching our eye and irritating us. Like a visual itch. It often happens with cheapish printed products – cheap laminate flooring, fabric, wallpaper – where the pattern repeat is too short.

So we wanted to make very sure our paving is sufficiently random. In particular, no too-long unbroken lines, and no too-large rectangles of blocks. For example the long unbroken line down the middle of that marketing photo above would be a clear no-no.

It was almost like a computer game. Except with pixels of 70x70mm, weighing over half a kilogram each. And instead of trying to make order, we tried to make randomness. Sort of an anti-Tetris.

Yesterday’s comic at XKCD includes an interesting bit of Wikipedia trivia: “if you take any article, click on the first link in the article text not in parentheses or italics, and then repeat, you will eventually end up at "Philosophy"”.

I tried a few random Wikipedia articles (a random link from the Wikipedia front page, cucumber and Georgia) and it worked in all cases. The tendency became obvious after just a few hops: we skirted linguistics, science, then information, and via quantity on to philosophy.

From philosophy it’s six hops back around to science and you can go another round. The full loop is Science > Knowledge > Fact > Information > Sequence > Mathematics > Quantity > Property_(philosophy) > Modern_philosophy > Philosophy > Existence > Sense > Organism > Biology > Natural_science > Science. So you could equally well argue that all Wikipedia queries have their root in Existence, or in Knowledge, or in Information. Whatever you think is the most fundamental of all – take your pick.

Now some developer has actually made a tool for you to try this on your own: xkcd wikipedia steps to philosophy.